[
https://issues.apache.org/jira/browse/OPENMEETINGS-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14029693#comment-14029693
]
Brad A LeBlanc commented on OPENMEETINGS-964:
---------------------------------------------
Would having a "disable autocreate" flag have value? For example, I have
several applications that I use to the LDAP to authenticate, but I use the
internal DB to authorize. If the system
didn't automatically publish new users into the database, that could be one
more layer preventing unauthorized access. This allows the application
administrator to populate the internal database to grant access to the system,
but still use the LDAP for the authentication process.
If an entity chose to make their system fully accessible to all authenticated
users, they would just leave the flag commented out.
I was looking at the commented field that you sent:
public static final String CONFIGKEY_LDAP_USER_EXTRAFILTER =
"ldap_user_extrafilter";
Depending on the flexibility of the options in the filter, aka group
membership, attribute, it would open the authorization model to be stored in
the LDAP directory. Application Administrators would use the LDAP database to
secure the application. But I don't see applications moving into that
direction. The heterogeneous environments have most of us using the LDAP
system for authentication and distributing the application management
responsibilities to non-sysadmin users. One notable exception at my site would
be the apps that deeply integrate into the directory structure, for example,
Microsoft server solutions and Active Directory. Even then, we have
implemented their identity portal suite to pass off user group management to
the respective owners.
> 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)
