[jira] [Comment Edited] (OPENMEETINGS-964) LDAP login should be refactored

["Thibault Le Meur (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OPENMEETINGS-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14032207#comment-14032207 ] 

Thibault Le Meur edited comment on OPENMEETINGS-964 at 6/16/14 7:53 AM:
------------------------------------------------------------------------

Hi Maxim,

Things to know:
* in order to search in an LDAP directory, you need to be bound to it. Depending on the directory setup, this bind can be anonymous or not.
* when the bind is not anonymous it will take a "user login" and "some kind of credentials":
    - when "simple authentication" is performed, the bind uses the entry's DN and entry's password
    - when "SASL authentication" is performed, you can have other authentication mechanisms such as Kerberos, Certificates, ... (http://www.openldap.org/doc/admin24/sasl.html) [ this answers [2]). In my experience I found that "SIMPLE authentication" is enough to cover most cases but I might be wrong.
* in SIMPLE authentication, you need to know the userDN:
    - if all users are defined in entries within a fixed path in the DIT (Directory Information Tree), then you can deduce the userDN from the login-field with a mask like "uid=<LOGINFIELD>,ou=people,dc=myorg,dc=org" (This is what I is called "SIMPLE BIND")
        - In this case, depending on the right of the userDN in his own entry, once bound with his own userDN to the directory you MAY be able to read the required attributes. Though I wrote "MAY", It is a common practice to give the userDN the right to read his own attributes (at least the most important ones) (answers partly [1])
    - if users' entries are spread over the DIT, you need to first perform a first "LDAPSearch" to find the user DN from the LoginField by using an LDAP filter such as: "(&(uid=<LOGINFIELD>)(accountStatus=Enabled))". We can see that this makes it easy to restrict users that are seen in the directory by adding extra filters expressions
    - this requires a first bind to the LDAP directory (but it could be an anonymous bind if the directory accepts this) to perform the userDN search.

Your sequence is ok if you are given an "admin" account on the directory (I prefer to say an 'application account' because it might just have right to search for users' entries). But sometimes you don't have such an account:
 - you may have to do a first anonymous bond to find the userDN
- OR if anonymous bind is not available, you may have to user SIMPLEBIND to get a connection to the directory, then directly read the attributes from the userDN entry (don't need to search for it since you already know the DN to read)




was (Author: lemeur):
Hi Maxim,

Things to know:
* in order to search in an LDAP directory, you need to be bound to it. Depending on the directory setup, this bind can be anonymous or not.
* when the bind is not anonymous it will take a "user login" and "some kind of credentials":
    - when "simple authentication" is performed, the bind uses the entry's DN and entry's password
    - when "SASL authentication" is performed, you can have other authentication mechanisms such as Kerberos, Certificates, ... (http://www.openldap.org/doc/admin24/sasl.html) [ this answers [2]). In my experience I found that "SIMPLE authentication" is enough to cover most cases but I might be wrong.
* in SIMPLE authentication, you need to know the userDN:
    - if all users are defined in entries within a fixed path in the DIT (Directory Information Tree), then you can deduce the userDN from the login-field with a mask like "uid=<LOGINFIELD>,ou=people,dc=myorg,dc=org" (This is what I is called "SIMPLE BIND")
        - In this case, depending on the right of the userDN in his own entry, once bound with his own userDN to the directory you MAY be able to read the required attributes. Though I wrote "MAY", It is a common practice to give the userDN the right to read his own attributes (at least the most important ones) (answers partly [1])
    - if users' entries are spread over the DIT, you need to first perform a first "LDAPSearch" to find the user DN from the LoginField by using an LDAP filter such as: "(&(uid=<LOGINFIELD>)(accountStatus=Enabled))". We can see that this makes it easy to restrict users that are seen in the directory by adding extra filters expressions
    - this requires a first bind to the LDAP directory (but it could be an anonymous bind if the directory accepts this) to perform the userDN search.

Your sequence is ok if you are given an "admin" account on the directory (I prefer to say an 'application account' because it might just have right to search for users' entries). But sometimes you don't have such account:
 - you may have to do a first anonymous bond to find the userDN
- OR if anonymous bind is not available, you may have to user SIMPLEBIND to get a connection to the directory, then directly read the attributes from the userDN entry (don't need to search for it since you already know the DN to read)



> LDAP login should be refactored
> -------------------------------
>
>                 Key: OPENMEETINGS-964
>                 URL: https://issues.apache.org/jira/browse/OPENMEETINGS-964
>             Project: Openmeetings
>          Issue Type: Task
>          Components: LDAP
>    Affects Versions: 3.0.0
>            Reporter: Maxim Solodovnik
>            Assignee: Maxim Solodovnik
>             Fix For: 3.1.0
>
>
> Detailed description is here OPENMEETINGS-943
> The correct way to handle this:
> First:
> if bind_dn and bind_pwd are set, first conect to the LDAP directory with these credentials
> if empty, then just use an nonymous bind to the directory
> Then
> if OM is set to AuthLDAP=NONE, just use the connection to retrieve informations from the directory
> -if OM is set to AuthLDAP=OPENLDAP (should be SEARCHANDBIND actually), search for the userDN and then perform a bind to the directory with userDN/provided PWD
> if OM is set to AuthLDAP=SIMPLEBIND, construct the userDN from the username, the user attribute (for instance cn or uid), and the userBase, and then perform a bind with userDN and provided PWD
> if OM is set to AuthLDAP=SIMPLE (to be backward compliant), let's try a bind with the provided user/password



--
This message was sent by Atlassian JIRA
(v6.2#6252)