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 Tue, 22 Nov 2005 01:57:29 GMT


Aaron Mulder wrote:

>Cata,
>
>If yuo specify the userRoleName, would it be just "memberOf" or would
>it be "(memberOf={0})" more like the other settings?
>  
>
    It would just be "memberOf".


    Regards,
    Cata  


>Thanks,
>    Aaron
>
>On 11/20/05, Catalino Pineda Jr. <cpineda@exist.com> wrote:
>  
>
>> 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