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 03:16:35 GMT


Aaron Mulder wrote:

>Hah!  I thought this LDAP module was pretty complicated.
>
>I just looked at the WebLogic OpenLDAP login module.  It has *40*
>different settings.  :)
>
>But anyway, with what little I know, I agree with Jeff -- will there
>ever be a case where you can look up groups for the user using
>something like "memberOf" and you wouldn't get the same information if
>you search the other way, for groups where that user was listed as a
>member in the group record? 
>
    I believe that current implementation would never give a duplicate 
value if you search using say, "memberOf" and searching the other way 
using "memberUID", unless the directory server contains that duplicate 
group assignments.  I would assume that LDAP administators would opt to 
choose to implement a single grouping mechanism rather than combining 
the uses of all the possible configurations for assigning members to a 
group. With that, the ldap login module will only have to choose between 
"userRoleName"  or "roleSearchMatching" , and on extreme cases, both.

> WebLogic talked about something called
>"dynamic groups" which I gether means there's not actually a group
>entry for the group in LDAP, so maybe the userRoleName could be used
>to detect those?
>
    This is not supported in the current implementation. For dynamic 
grouping, the returned attribute value should be an LDAP URL rather than 
a distinguished name and will be handled differently than the userRoleName.


Cata

>
>Aaron
>
>On 11/20/05, Jeff Genender <jgenender@apache.org> 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.
>>
>>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