LDAP plugin design¶
Once configured, LDAP authentication allows sysadmins to control OMERO’s user and group creation via an external, locally-maintained LDAP server. Due to the flexibility of LDAP, each instance may have a number of requirements that cannot be supported out of the box. Below, we discuss the design of the LDAP plugin as well as how it can be extended for local use.
The LDAP plugin follows these steps:
Sysadmin configures properties mapping users and groups from LDAP to OMERO.
Once LDAP is enabled, any OMERO user who has a value of
ldapcolumn of the
experimentertable will have their password checked against LDAP and not against OMERO (changing the password via OMERO is not supported). This functionality is provided by the Password Provider. The DN is not stored in the OMERO DB and is retrieved from the LDAP server on each user login.
user_mappingproperty is of the form:
For looking up new users, the plugin will only use the
omeNameattribute. For example, if a user tries to login with “emma” and the
omeName=cn;then the LDAP search will be for
(cn=emma)LDAP filter is then added to the value of
omero.ldap.user_filter. For example, if the user filter is
(objectClass=inetOrgPerson), the full query for the new user will be:
If the search returns a single LDAP user, then an OMERO user will be created with all properties mapped according to
ldapproperty set to
Then the user will be placed in groups according to the value of
omero.ldap.new_user_group, which are created if necessary. Details of the various options can be found under LDAP authentication. Each option is handled by a different
The interface described for the “:bean:”
new_user_group prefix, is
ome.security.auth.NewUserGroupBean. It defines a
groups(…, AttributeSet set) which returns a list of
ExperimenterGroup ids (
List<Long>) which the user should be added to.
Other prefix handlers also implement the interface as examples. In the same package are: