Open Microscopy Environment

After several threads on the mailing list about possible LDAP extensions, I thought it might be time to start gathering all of the wish lists in a single place.

The overarching LDAP improvement status can be tracked via ticket:1382.

Currently there are:

• Periodically pull from LDAP (not just on login)
  
• Take groups not just users from LDAP (ticket:1133)
  
• Take user name from attribute other than CN
  
• Allow multiple servers to be searched

The specific goal of this list is to know if it is possible to provide some over-arching implementation, or if/which site-specific extensions (plugins) will be needed.


See mailing list threads:

• http://lists.openmicroscopy.org.uk/pipe ... 01811.html
  
• http://lists.openmicroscopy.org.uk/pipe ... 01812.html
  
• http://lists.openmicroscopy.org.uk/pipe ... 01837.html

Last updated: Fri 11 Dec 2009 18:54:00 GMT

I tried using ldaps rather than but it didn't work - are there any plans to implement it? I'm a little nervous (or rather, my bosses are) about passing passwords in the clear between the omero server and the Active Directory server.


Thanks.

Mark.Henshall wrote:I tried using ldaps rather than but it didn't work - are there any plans to implement it? I'm a little nervous (or rather, my bosses are) about passing passwords in the clear between the omero server and the Active Directory server.

LDAPS is supported, though the setup is under-documented.. See this thread for a working example, or the instructions under install-ldap. We'll work on making the LDAPS steps more explicit. Then, if you're still having trouble, could you open a new forum thread specifically on LDAPS support? Thanks, ~Josh

jmoore wrote:

• Take user name from attribute other than CN

I think this is a must, as, at least in the UNIX world, CN is not used to store the username, UID is. So mapping the omero username to the LDAP uid field would be really good.


We use UNIX here, and are just implementing LDAP (so still wet behind the ears). We are also just evaluating OMERO.

I struggled with the OMERO LDAP implemntation for a while before I discovered that the group it was looking for was of objectClass 'groupOfNames' and the way to assign membership into that group is using the 'member' attribute which must contain the user's DN (fully qualified name).

Unfortunately the 'groupOfNames' objectClass is incompatible with the 'posixGroup' objectClass (which is used for UNIX / Samba groups - what we use). This means that UNIX cannot use the same 'omero' group & we would need to duplicate the group with the posixGroup objectClass.

I think being able to specify the objectClass of the LDAP omero group would be really good (perhaps there can just be a couple of options, so you don't have to code for all the different group types!).
As the posixGroup uses the 'memberUid' attribute (containing the user's uid AKA username), the LDAP search filter would have to be slightly different.

Are multiple LDAP servers supported at the moment? ie. can we configure both primary & secondary LDAP servers?

If not this would be a great addition, as (I think) most installations of LDAP run with a backup server.

If it can already be done, how would when enter the 'omero.ldap.urls' string?

Thanks.

Unfortunately you cannot configure multiple servers at present. We'll add this to the list of requirements for our LDAP update.

Thanks for the feedback.

We only currently use LDAP (via our institutional Active Directory) for authentication, not account management. Our requirements are:

• First do an LDAP search using uid. If the user is found then attempt a bind, and (dis)allow access based on result.
• If user not in LDAP then they are not a member of the University, so check against OMERO's local database.

When we widen access to OMERO we will need to use LDAP for account management but will still use it in a read-only way. This will consist of looking for an unknown user in LDAP the first time they try to connect and creating an OMERO account if found, populating it with firstname, lastname and email address. We may need to try to assign groups automatically too.

For non-University users we plan to use email addresses as usernames to avoid clashes with internal users. Strictly speaking this means we wouldn't need to search LDAP as we could instead search for an '@' in the username but in reality it's easier to implement the search/bind as a more generic mechanism.

As an aside, we need to ensure that University login passwords are sent securely end-to-end, so both ICE and LDAP traffic needs to be encrypted.