Yet another LDAP post

[NunoM <nu...@hotmail.com>]

Hi everyone,

A very new shiro user here :)

I've been searching the forums, but I haven't exactly gotten all the steps.

What I need to do is:
1. Authenticate with an active directory server.

2. Manage authorization based on roles stored in a database or with groups
residing in the AD.

So, what I've gotten so far:

1. I know I need to configure the ini file for the ldap realm and database
realm, no problem there.

2. What do I need to here? How can I get the user names and passwords in the
code to login the user with shiro? How do I set up group roles?

Thanks in advance,
Nuno.

--
View this message in context: http://shiro-user.582556.n2.nabble.com/Yet-another-LDAP-post-tp7550546.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Yet another LDAP post

[Les Hazlewood <lh...@apache.org>]

Oops - typo:


> [main]
> ...
> securityManager.realms = adRealm, myDbRealm
>

should be

securityManager.realms = $adRealm, $myDbRealm

Re: Yet another LDAP post

[Les Hazlewood <lh...@apache.org>]

On Fri, May 11, 2012 at 6:57 AM, NunoM <nu...@hotmail.com> wrote:

> Hi everyone,
>
> A very new shiro user here :)
>

Hello!  Welcome to the Shiro community!


> 1. I know I need to configure the ini file for the ldap realm and database
> realm, no problem there.
>
> 2. What do I need to here? How can I get the user names and passwords in
> the
> code to login the user with shiro? How do I set up group roles?
>

You will need to configure two realms - one ActiveDirectoryRealm and
another realm that talks to your database that only does authorization.
 Configure the ad realm first before the db-based realm, e.g. in shiro.ini:

[main]
...
securityManager.realms = adRealm, myDbRealm

This will ensure the AD realm is consulted first for authentication.  Your
'myDbRealm' instance, because it never performs authentication, can return
'false' from the supports(AuthenticationToken token) method to ensure it is
never invoked during authentication.

Anyway, the ActiveDirectoryRealm works as follows:

1.  The default Authentication behavior is to attempt to open an
authenticated connection to the LDAP/AD server using a supplied username +
password pair.  The LdapContextFactory used by the realm uses standard JVM
JNDI API to open an authenticated connection.  If the connection opens -
the end user is authenticated.  If it does not, the end user's
authentication failed.

In ActiveDirectory, the username is often a simple username (e.g. jsmith).
 A 'principalSuffix' can be configured if more information is required).
For LDAP realms, the username is likely to be a full User DN (e.g.
uid=jsmith,ou=users,dc=mycompany,dc=com).

Unlike most other Shiro realms, the AD realm does not query for the AD user
record with its password and then perform credentials matching.  It
leverages the fact that the AD connection must be authenticated.  If a
connection can't be made for that end-user, clearly they havent supplied
the correct credentials (or they've expired, etc).

2. Authorization does not use this connection-attempt-per-end-user model.

Instead, 'system user' username/password is configured on the realm to
query for any given end-user account's roles.  The configured 'system user'
must have the ability to query for any of the users for which you might
need to lookup information.

During an authorization check, the system user account is used to query for
the end-user's groups (based on their username), and a collection of group
names will be returned.  These group names will be used to satisfy Shiro
role checks (hasRole, etc).

You might want to check the source code here to better understand how the
configuration properties work (and how they in turn lazily create an
LdapContextFactory:

http://svn.apache.org/repos/asf/shiro/trunk/core/src/main/java/org/apache/shiro/realm/activedirectory/ActiveDirectoryRealm.java

You can see then how the authentication (queryForAuthenticationInfo) and
authorization (queryForAuthorizationInfo) methods work.

Additionally, note that the AD realm was created by one particular end-user
for their own application needs.  It could stand to be made much more
robust for other applications.  If you have _any_ feedback on how you think
this should work or would like to see it work, we'd love to hear it!

Other suggestions welcome!

Best regards,

--
Les Hazlewood
CTO, Stormpath | http://stormpath.com <http://www.stormpath.com/> |
888.391.5282
twitter: @lhazlewood | http://twitter.com/lhazlewood
blog: http://leshazlewood.com
stormpath blog:
http://www.stormpath.com/blog<http://www.stormpath.com/blog/index>