Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <43813C2E.607@apache.org>
Date: Sun, 20 Nov 2005 20:17:02 -0700
From: Jeff Genender <jgenender@apache.org>
Reply-To: jgenender@apache.org
Organization: Apache Geronimo
User-Agent: Thunderbird 1.5 (Macintosh/20051025)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: Who understands the LDAP login module?
References: <74e15baa0511200017u28314785x8f517c392dc4f7b3@mail.gmail.com>
	 <4380C2DD.2070806@apache.org>
	 <74e15baa0511201136k28fbfd71tf5e11b76224d1db6@mail.gmail.com>
	 <4380D738.6010005@apache.org>
 <74e15baa0511201216k31db3d3egd3ba57e3083f6ef6@mail.gmail.com>
 <43812056.5030800@exist.com> <43812362.8040905@apache.org>
 <438129C2.6080108@exist.com> <43812CA0.6040803@exist.com>
 <43812DF2.8060905@apache.org> <438134C9.9000404@exist.com>
In-Reply-To: <438134C9.9000404@exist.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


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