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 01:31:14 GMT
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?

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