You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by remast <ja...@cellent-fs.de> on 2011/04/01 08:37:17 UTC

Re: Call for suggestions: how can Shiro's LDAP support be improved?

Hi All,

I would be very interested in the extension of LDAP support! If that would
be supported out of the box I could use shiro in some of our products! So
let me know when that's implemented!

Thanks,
remast

--
View this message in context: http://shiro-user.582556.n2.nabble.com/Call-for-suggestions-how-can-Shiro-s-LDAP-support-be-improved-tp6228100p6229849.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Call for suggestions: how can Shiro's LDAP support be improved?

Posted by Brian Demers <br...@gmail.com>.
I think there are basically two camps when it comes to LDAP connector
configuration.
1.) The user configures a query (&(objectClass=posixAccount) (uid=jcoder))
2.) The user configures the fields, which are then use to generate the
query, UserObjectClass = posixAccount UserIdAttribute = uid

With the first you have the ability to tune a query,  the second gets
you closer to user management (if your looking to add users, you need
a little more then a query )
I'm in camp 2, but i'll admit the first option might fit better for a
stock ldap realm that just needs authc and authz.

Either of which could be mostly templated to common schemas
(posixAccount/Group, AD, etc)

Passwords are fun too,  some servers, only allow you to authenticate
via a bind (logging in the server) (e.g. Active directory) other do
not support this.  In order to do a bind, you need to look up the
user's DN in one query, then _login_.
Then there are passwords stored as an attribute, usually prefixed with
the type of hash "{SHA}HA5EDP455W0RD" (and a dozen variations on that)

Then lastly there are groups, which may be considered dynamic or
static.  Static groups are where the user mapping is stored as
attributes in a group object.  Dynamic groups are stored by as
attributes in the user object.

So some authc/authz logins may take 3 different queries, 1.) find
user's DN 2.) authenticate 3.) look up the roles.  And on the flip
side, a single query 1.) query for user object. [read password
attribute, read memeberOf attributes)

And almost everybody does something different, some variations on the
above, with nested organizations [subtree], locked down permissions,
etc

Sorry for the delay,
-Brian



On Fri, Apr 1, 2011 at 2:37 AM, remast <ja...@cellent-fs.de> wrote:
> Hi All,
>
> I would be very interested in the extension of LDAP support! If that would
> be supported out of the box I could use shiro in some of our products! So
> let me know when that's implemented!
>
> Thanks,
> remast
>
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/Call-for-suggestions-how-can-Shiro-s-LDAP-support-be-improved-tp6228100p6229849.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>

Re: Call for suggestions: how can Shiro's LDAP support be improved?

Posted by Grant Genereux <gr...@shaw.ca>.
Hi Les,

Just a few other things on LDAP support.

In the past I've needed to make use of  FastBind for authentication on 
MS AD.

But, the more important feature I've needed is support for getting a 
user's group membership list recursively.

It would be supper nice if these could be generic enough to work with MS 
AD, as well as other LDAP servers.  Maybe using some form of templated 
query strings?

Lastly, I can offer to pitch in and help with this if interested.

Grant