geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <jgenen...@apache.org>
Subject Re: Who understands the LDAP login module?
Date Mon, 21 Nov 2005 03:17:02 GMT


Catalino Pineda Jr. wrote:
> 
> 
> Jeff Genender wrote:
> 
>> This is my point.  Unlike a database...I can index the memberUID (used 
>> as an example in a group schema) which gives me the list of users that 
>> belong to that group. If I need to know which group my use belongs to 
>> , the indexed attribute (memberUID) will rapidly tell me.  I honestly 
>> think the userRoleName is not necessary.
> 
>    Yeah. I believe I got your point. Since memberUID is the standard way 
> of determining membership, userRoleName may not be necessary.But, I  
> believe that expanding the scope of  directory server configurations 
> that the login module would support would be of an added value, which in 
> this case for directory servers that use memberOf attribute rather than 
> enumerating all members of a group using memberUID.  This would mean 
> that ldap authentication is possible for non-conformant directory server 
> installations.

Ok, I understand this but in order to effectively make this work, the 
roleSearchMatching *or* userRoleName needs to be used.  This is an 
exclusive/or operation...and should not be used together.  There should 
be a flag attribute that forces you to pick one or the other.

>        Other possible configuration (for tracking memberships) is the 
> use of "dynamic groups" where members of a group is determined by ldap 
> url rather than by distinguished names and the use of memberUID.
> 
> Regards,
>   Cata
> 
>>
>> Jeff
>>
>> Catalino Pineda Jr. wrote:
>>
>>>
>>>   Let me correct myself on a previous message :)
>>>
>>> |    "   the value of the attribute will added to the roles obtained 
>>> using userRoleName property. "
>>>
>>>        should  have been
>>>
>>>      "  the value of the attribute will added to the roles obtained 
>>> using  roleSearchMatching  property. "
>>>
>>> Thanks,
>>> Cata
>>>
>>>
>>> Catalino Pineda Jr. wrote:
>>>
>>>>
>>>>
>>>> Jeff Genender wrote:
>>>>
>>>>> Isn't this then a duplicate of what the group contains?  The group 
>>>>> will have multiple (example) memberUID.  If indexed, I should be 
>>>>> able to determine which groups a user belongs to.  Does this not 
>>>>> possibly create a dis-joint issue?
>>>>
>>>>
>>>>
>>>>    The purpose of such is to support directory server configurations 
>>>> where group assignments are determined using an attribute rather 
>>>> than putting user contexts within the group context (or they can be 
>>>> a combination of both).  The option  would allow the login module to 
>>>> connect to directory servers configured as such. Duplication on this 
>>>> sense would be at the directory server level.
>>>>
>>>> Regards,
>>>> Cata
>>>>
>>>>
>>>>
>>>>>
>>>>> Catalino Pineda Jr. wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> Aaron Mulder wrote:
>>>>>>
>>>>>>> For what it's worth, I think the search starts in the context
>>>>>>> identified by the userBase or roleBase.  Then I assume the 
>>>>>>> appropriate
>>>>>>> subtrees flag controls whether you search only there, or there

>>>>>>> and all
>>>>>>> sub-contexts recursively.
>>>>>>>
>>>>>>> So other than confirmation of that and of your answers, the main
one
>>>>>>> we're not sure of is userRoleName.  It's definitely used -- 
>>>>>>> something
>>>>>>> to do with mucking with attributes -- but I the code isn't real

>>>>>>> clear
>>>>>>> to me.
>>>>>>>  
>>>>>>>
>>>>>>    userRoleName is an attribute in the user entry which refers to

>>>>>> a "role/group entry"  where the user is a member of. If a value is

>>>>>> set for the userRoleName property in the LDAPLoginModule 
>>>>>> configuration,  the value of the attrubue will added to the roles

>>>>>> obtained using userRoleName property. E.g.
>>>>>>
>>>>>>
>>>>>> dn: cn=user1,ou=users,dc=domain,dc=com
>>>>>> ...
>>>>>> ...
>>>>>> memberOf: cn=administrator,ou=groups,dc=domain,dc=com
>>>>>>
>>>>>>
>>>>>> In the case above, user1 is  a member of groups. The userRoleName

>>>>>> property can be set to "memberOf".
>>>>>>
>>>>>> Hope this helps.
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Catalino Pineda Jr.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Thanks,
>>>>>>>    Aaron
>>>>>>>
>>>>>>> On 11/20/05, Jeff Genender <jgenender@apache.org> wrote:
>>>>>>>  
>>>>>>>
>>>>>>>> I can answer some of these questions...hopefully correctly.
>>>>>>>>
>>>>>>>> Aaron Mulder wrote:
>>>>>>>>  
>>>>>>>>
>>>>>>>>> Well, that's a start, but it doesn't actually explain
what any 
>>>>>>>>> of the
>>>>>>>>> LDAP login module options are -- it only tells you what
to set 
>>>>>>>>> them to
>>>>>>>>> if you want to connect to the sample.  I'd like to come
up with a
>>>>>>>>> meaningful text description of each option:
>>>>>>>>>
>>>>>>>>> initialContextFactory
>>>>>>>>>     
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The InitialContext factory to use.  Usually is
>>>>>>>> com.sun.jndi.ldap.LdapCtxFactory.
>>>>>>>>
>>>>>>>>  
>>>>>>>>
>>>>>>>>> connectionURL
>>>>>>>>>     
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> URL of the LDAP server to connect to.  For a production LDAP

>>>>>>>> this will be:
>>>>>>>>
>>>>>>>> ldap://[your server's LDAP host address]:389
>>>>>>>>
>>>>>>>> if you use it with Geronimo in its developer configuration,
it 
>>>>>>>> would be
>>>>>>>>
>>>>>>>> ldap://localhost:1389
>>>>>>>>
>>>>>>>> Because we had the Apache Directory Server listening on 1389
due to
>>>>>>>> security issues with running on ports less than 1024.
>>>>>>>>
>>>>>>>>  
>>>>>>>>
>>>>>>>>> connectionUsername
>>>>>>>>>     
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> User name to bind.  Should be administrator or Directory
manager 
>>>>>>>> that
>>>>>>>> has access to examine passwords.
>>>>>>>>
>>>>>>>>  
>>>>>>>>
>>>>>>>>> connectionPassword
>>>>>>>>>     
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Password of user to bind
>>>>>>>>
>>>>>>>>  
>>>>>>>>
>>>>>>>>> connectionProtocol
>>>>>>>>>     
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I think it can contain "ssl" for secure communication with

>>>>>>>> certificates.
>>>>>>>>
>>>>>>>>  
>>>>>>>>
>>>>>>>>> authentication
>>>>>>>>>     
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Usually one of several protocols.  I think it follows the

>>>>>>>> COntext, so I
>>>>>>>> *believe* the possibilities are "none", "simple", and "strong".
 
>>>>>>>> I could
>>>>>>>> be wrong depending on the implementation.
>>>>>>>>
>>>>>>>>  
>>>>>>>>
>>>>>>>>> userBase
>>>>>>>>>     
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Base of the LDAP search string to the users.
>>>>>>>>
>>>>>>>>  
>>>>>>>>
>>>>>>>>> userSearchMatching
>>>>>>>>>     
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The LDAP attribute search string to find the user.  Usually
will 
>>>>>>>> be uid={0}.
>>>>>>>>
>>>>>>>>  
>>>>>>>>
>>>>>>>>> userSearchSubtree
>>>>>>>>>     
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I don't know about this one.
>>>>>>>>
>>>>>>>>  
>>>>>>>>
>>>>>>>>> roleBase
>>>>>>>>>     
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> LDAP string specifying the base objects from which to search
for 
>>>>>>>> group/role
>>>>>>>>
>>>>>>>>  
>>>>>>>>
>>>>>>>>> roleName
>>>>>>>>>     
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Attribute that acts as the role's name.  This typically is
the 
>>>>>>>> "cn".
>>>>>>>>
>>>>>>>>  
>>>>>>>>
>>>>>>>>> roleSearchMatching
>>>>>>>>>     
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The LDAP search string to find the user.  The value here
depends 
>>>>>>>> on how
>>>>>>>> your group schema is configured.  Generally the role will
have many
>>>>>>>> attributes that are the same, but with different values.
 An 
>>>>>>>> example
>>>>>>>> would be "memberUID" for LDAP authentication for UNIX systems.
 
>>>>>>>> In this
>>>>>>>> scenario the value of the roleSearchMatching would be 
>>>>>>>> (memberUID={0})
>>>>>>>>
>>>>>>>>  
>>>>>>>>
>>>>>>>>> roleSearchSubtree
>>>>>>>>>     
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I don't know about this one.
>>>>>>>>
>>>>>>>>  
>>>>>>>>
>>>>>>>>> userRoleName
>>>>>>>>>     
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I don't know about this one.
>>>>>>>>
>>>>>>>>  
>>>>>>>>
>>>>>>>>> I have a vague idea of some of them from hacking around
with 
>>>>>>>>> this kind
>>>>>>>>> of stuff before -- but for the most part, I probably
coun't 
>>>>>>>>> explain it
>>>>>>>>> well.  But even for nominally straightforward ones like
connect
>>>>>>>>> username and password -- does the provided account need
to be 
>>>>>>>>> an LDAP
>>>>>>>>> administrator?
>>>>>>>>>     
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Yes.
>>>>>>>>
>>>>>>>>  
>>>>>>>>
>>>>>>>>> Do I understand right that the realm will attempt to
>>>>>>>>> bind to LDAP as the user to verify their password?
>>>>>>>>>     
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> No.  It typically binds as an administrator user who has
access to
>>>>>>>> verify the password.
>>>>>>>>
>>>>>>>>  
>>>>>>>>
>>>>>>>>> If so, why do you
>>>>>>>>> need the admin account and search params, why not just
connect 
>>>>>>>>> as the
>>>>>>>>> user and if it works look up their groups?
>>>>>>>>>     
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Same reason as JDBC...you have a user that has access to

>>>>>>>> user/groups to
>>>>>>>> lookup and respond with the appropriate subject/principals

>>>>>>>> (user/roles).
>>>>>>>>
>>>>>>>>  
>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>   Aaron
>>>>>>>>>
>>>>>>>>> On 11/20/05, Jeff Genender <jgenender@apache.org>
wrote:
>>>>>>>>>  
>>>>>>>>>
>>>>>>>>>> Looks like Hernan put together a really nice tutorial
on 
>>>>>>>>>> Geronimo with
>>>>>>>>>> the LDAp login module and Apache Directory.
>>>>>>>>>>
>>>>>>>>>> http://opensource2.atlassian.com/confluence/oss/display/GERONIMO/Configuring+LDAP

>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Aaron Mulder wrote:
>>>>>>>>>>  
>>>>>>>>>>> It has like 14 parameters -- if I could get some
help 
>>>>>>>>>>> figuring out
>>>>>>>>>>> what all of those mean, and maybe some samples
for hooking it 
>>>>>>>>>>> up to
>>>>>>>>>>> OpenLDAP, Sun LDAP, and Active Directory LDAP,
that would be
>>>>>>>>>>> outstanding.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>    Aaron
>>>>>>>>>>>
>>>>>>>>>>> http://svn.apache.org/viewcvs.cgi/geronimo/trunk/modules/security/src/java/org/apache/geronimo/security/realm/providers/LDAPLoginModule.java?rev=345629&view=markup

>>>>>>>>>>>
>>>>>>>>>>>         
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>>>  
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> 

Mime
View raw message