Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 39743 invoked from network); 21 Nov 2005 03:17:22 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 21 Nov 2005 03:17:22 -0000 Received: (qmail 42051 invoked by uid 500); 21 Nov 2005 03:17:19 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 41744 invoked by uid 500); 21 Nov 2005 03:17:18 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 41733 invoked by uid 99); 21 Nov 2005 03:17:18 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 20 Nov 2005 19:17:18 -0800 Received-SPF: pass (asf.osuosl.org: local policy) Received: from [64.14.253.182] (HELO mail.exist.com) (64.14.253.182) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 20 Nov 2005 19:18:50 -0800 Received: from exist.com (adsl-131.68.165.info.com.ph [203.131.68.165] (may be forged)) (authenticated bits=0) by mail.exist.com (8.12.11/8.12.11) with ESMTP id jAL2UMq0024136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 20 Nov 2005 18:30:29 -0800 Message-ID: <43813C13.1090001@exist.com> Date: Mon, 21 Nov 2005 11:16:35 +0800 From: "Catalino Pineda Jr." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en 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> <74e15baa0511201827t2b119c51lcff244e7dd484668@mail.gmail.com> In-Reply-To: <74e15baa0511201827t2b119c51lcff244e7dd484668@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------010009070402040701090708" X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N This is a multi-part message in MIME format. --------------010009070402040701090708 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 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 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 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>>>> >>>>>>> > > > --------------010009070402040701090708 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

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