geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Catalino Pineda Jr." <cpin...@exist.com>
Subject Re: Who understands the LDAP login module?
Date Mon, 21 Nov 2005 02:45:29 GMT


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.
        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