Improve LDAP support

[jamoore]

See forum threads:

• ​http://openmicroscopy.org/community/viewtopic.php?f=5&t=14
• http://www.openmicroscopy.org/community/viewtopic.php?f=5&t=382

Other configuration systems for comparison:

• ​http://www.liferay.com/community/wiki/-/wiki/Main/LDAP
• ​http://docs.jboss.org/jbportal/v2.7.1/referenceGuide/html/ldap.html
• ​http://drupal.org/node/62217
• ​http://www.sonatype.com/books/nexus-book/reference/ldap-sect-user-group-mapping.html
• ​http://typo3.org/documentation/document-library/extension-manuals/eu_ldap/2.7.10/view/1/2/
• ​http://wiki.alfresco.com/wiki/Enterprise_Security_and_Authentication_Configuration
• ​https://cwiki.apache.org/GMOxDOC11/ldap-realm.html
• ​http://www.opennms.org/index.php/Acegi_Security_and_LDAP
• ​http://www.redmine.org/projects/redmine/wiki/RedmineLDAP (Also ​this topic, and ​this ticket)

Tasks:

• interface for LDAP plugins
• configuration- and possibly ice-based implementations
• posix and active directory configurations (cf. sonatype above)
• multiple server support (chaining) (​thread)

Note: this ticket somewhat carries on from #4826.

[jmoore]

The liferay integration uses the following parameters:

    ldap.auth.enabled=true
    ldap.auth.required=true

    ldap.users.dn=ou=People,dc=localdomain
    ldap.groups.dn=ou=Groups,dc=localdomain

    ldap.user.mappings=screenName=cn\npassword=userPassword\nemailAddress=mail\nfirstName=givenName\nlastName=sn\njobTitle=title\ngroup=groupMembership
    ldap.user.impl=com.liferay.portal.security.ldap.LDAPUser

    ldap.group.mappings=groupName=cn\ndescription=description\nuser=uniqueMember

    ldap.import.user.search.filter=(objectClass=inetOrgPerson)
    ldap.import.group.search.filter=(objectClass=groupOfUniqueNames)

    ldap.auth.search.filter=(mail=@email_address@)

[jmoore]

(In [6550]) fix #2025 - Fixing ldap tests post-refactoring (see #1382)

With this commit, the basic reconfiguration of LDAP is finished.
Usability and performance improvements should be added to #1382

[jmoore]

As a follow up on #2025, the new properties which we are currently testing are:

omero.ldap.user_filter=(objectClass=person)
omero.ldap.user_mapping=omeName=cn,firstName=givenName,lastName=sn,email=mail
omero.ldap.group_filter=(objectClass=groupOfNames)
omero.ldap.group_mapping=name=cn
omero.ldap.new_user_group=default
#omero.ldap.new_user_group=:ou:
#omero.ldap.new_user_group=:attribute:memberOf
#omero.ldap.new_user_group=:query:(member=${dn})

The filters and mappings are as in the liferay documentation above. The "new_user_group" property is an experiment to allow for various styles of mapping:

• no prefix implies use the static group named "${omero.ldap.new_user_group}"
• the ":ou:" prefix means map the users last organizationl unit to a group name, "ou=IT,ou=division,o=college" would map to a group of "IT"
• the ":attribute:" prefix means take the possibly multi-valued attribute defined and add the user to all groups
• the ":query:" attribute is a query run under the group filter which has all the user mapping properties plus "${dn}" available to it, so that the above example looks for all groupOfNames with a member attribute with the dn as a value
• a possible (unimplemented) prefix ":bean:" could allow for implementing one's own NewUserGroupMapper

[jmoore]

(In [6916]) see #1382 - Ldap tests and NewUserGroupBean interface. See also #2029

This interface is only responsible for adding groups based on newly
created users. ome.security.auth.RoleProvider and PasswordProvider
are two other interfaces which are available. The three together may
be sufficient for #2029.

[cxallan]

A single user filter such as:

...
omero.ldap.user_filter=(cn=jburel)
...

Does not allow users that match to login.

[agilo]

Updated status, related task in progress