[
https://issues.apache.org/jira/browse/OPENMEETINGS-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14032229#comment-14032229
]
Thibault Le Meur edited comment on OPENMEETINGS-964 at 6/16/14 10:09 AM:
-------------------------------------------------------------------------
I would design the LDAP connector this way:
1- Have the params for the LDAP directory
* URL of the directory (host and ports)
* LDAP version* optionnal LDAP encryption (SSL [for ldaps:// url], or TLS for
ldap:// + TLS)
* base DN for searching users
* let the OM admin give a mapping between LDAP attributes and openmeetings
attributes (mail => email, ou => organization)
I would implement "SIMPLE authentication" ONLY (not SASL) for now as it should
cover most cases (if not all, because there might be failback to simple auth
in SASL directories).
2- have a parameter that defines how you'd like to use the LDAP directory for
Authentication and Data provisionning:
* Authentication could be:
** SIMPLEBIND: simple bind authentication
** SEARCHANDBIND: search and bind authentication
** NONE: in this case authentiction is performed on the local database (LDAP
not used to perform authentication)
* Data provisionning (LDAP_Provisionning):
** NONE: the LDAP directory is only used for authentication. Once
authenticated, the user is not auto-created on OM, nor the account updated. The
login process will go on only if the required account is already provisionned
in OM database
** AUTOUPDATE: Once authenticated, the user's information is read from LDAP and
IF the account already exists in OM database, THEN it is updated with the
information from LDAP
** AUTOCREATE: Once authenticated, the user's information is read from LDAP and
the account is UPDATED or CREATED as needed inside the OM database.
*** We might need a "default Organization" for this (but we already have I
think).
*** We might like to add a mapping between Organizations and LDAP user
attributes IN THE FUTURE. I which case we should be able to give an LDAP
attribute (for instance "memberOf"), and a list of {value or regexp, name of an
OM organization}
3- SIMPLEBIND case:
* let the OM admin give a userDN format string such as
"uid=<LOGINFIELD>,ou=people,dc=myorg,dc=org"
** (optionnally give an LDAP filter such as
"(&(accountStatus=Enabled)(objectclass=XXX))" that could be used to refine
access to the application)
Login is successful if:
* ldap_bind is Successful AND LDAP_Provisionning=AUTOCREATE
OR
* ldap_bind is Successful AND an account with same login already exists in OM
database
4- SEARCHANDBIND case:
* a user DN filter format string than can contain any extra filter expressions
such as "(&(uid=<LOGINFIELD>)(accountStatus=Enabled))"
** "application account DN" and password params. If they are empty, then use
anonymous bind for the userDN search
Login is successful if:
* ldap_bind is Successful AND LDAP_Provisionning=AUTOCREATE
OR
* ldap_bind is Successful AND an account with same login already exists in OM
database
5- Data provisionning
Once authenticated, if LDAP_Provisionning=AUTOCREATE or
LDAP_Provisionning=AUTOUPDATE, then read the users' data and update the
corresponding OM database entry. If the entry doesn't exist yet and
LDAP_Provisionning=AUTOCREATE then populate the OM database accordingly.
was (Author: lemeur):
I would design the LDAP connector this way:
1- Have the params for the LDAP directory
* URL of the directory (host and ports)
* LDAP version* optionnal LDAP encryption (SSL [for ldaps:// url], or TLS for
ldap:// + TLS)
* base DN for searching users
* let the OM admin give a mapping between LDAP attributes and openmeetings
attributes (mail => email, ou => organization)
I would implement "SIMPLE authentication" ONLY (not SASL) for now as it should
cover most cases (if not all, because there might be failback to simple auth
in SASL directories).
2- have a parameter that defines how you'd like to use the LDAP directory for
Authentication and Data provisionning:
* Authentication could be:
** SIMPLEBIND: simple bind authentication
** SEARCHANDBIND: search and bind authentication
** NONE: in this case authentiction is performed on the local database (LDAP
not used to perform authentication)
* Data provisionning (LDAP_Provisionning):
** NONE: the LDAP directory is only used for authentication. Once
authenticated, the user is not auto-created on OM, nor the account updated. The
login process will go on only if the required account is already provisionned
in OM database
** AUTOUPDATE: Once authenticated, the user's information is read from LDAP and
IF the account already exists in OM database, THEN it is updated with the
information from LDAP
** AUTOCREATE: Once authenticated, the user's information is read from LDAP and
the account is UPDATED or CREATED as needed inside the OM database.
3- SIMPLEBIND case:
* let the OM admin give a userDN format string such as
"uid=<LOGINFIELD>,ou=people,dc=myorg,dc=org"
** (optionnally give an LDAP filter such as
"(&(accountStatus=Enabled)(objectclass=XXX))" that could be used to refine
access to the application)
Login is successful if:
* ldap_bind is Successful AND LDAP_Provisionning=AUTOCREATE
OR
* ldap_bind is Successful AND an account with same login already exists in OM
database
4- SEARCHANDBIND case:
* a user DN filter format string than can contain any extra filter expressions
such as "(&(uid=<LOGINFIELD>)(accountStatus=Enabled))"
** "application account DN" and password params. If they are empty, then use
anonymous bind for the userDN search
Login is successful if:
* ldap_bind is Successful AND LDAP_Provisionning=AUTOCREATE
OR
* ldap_bind is Successful AND an account with same login already exists in OM
database
5- Data provisionning
Once authenticated, if LDAP_Provisionning=AUTOCREATE or
LDAP_Provisionning=AUTOUPDATE, then read the users' data and update the
corresponding OM database entry. If the entry doesn't exist yet and
LDAP_Provisionning=AUTOCREATE then populate the OM database accordingly.
> 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)
