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:10:40 GMT

   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