RFE: Don't require ldap/ad users to log in before being allocatable to groups

[khgillen]

At the moment, ldap/AD users must first log into OMERO before (at least in OMERO.web) an Admin can allocate them to an OMERO group.

This is a nightmare when collaborating with remote users for the first time as it (typically) requires an extra round-trip communication, and leaves their first experience of OMERO one where they can't do anything, losing precious momentum and perhaps leaving a negative perception of OMERO.

Ideally: it would be nice to be able to search for name, or username, email address or all of them, (minimally ldap username), and be able to add them to an OMERO group before they have logged into the OMERO server.

[jamoore]

See: ​https://github.com/openmicroscopy/openmicroscopy/pull/1827 for a partial workaround for this issue from Douglas.

[drussell-x]

I think this would tie in nicely with some other LDAP ideas that I talked over briefly with khgillen.


On-demand, per-user, ldap re-sync - Basically the function of complete ldap sync, but on-demand for particular people.
so if they move groups in LDAP I can simply resync them. This would also tie in well with the below.


LDAP Aware Group membership I think it would also be good for group membership to be LDAP aware if it is not already. Then you could turn on a semi-sync mode where changes in LDAP group membership are reflected immediately in OMERO for a user, but any manual assignments are untouched. As the 'LDAPness' would be on group membership, not on the group itself, this would work well in environments where there be.

[jamoore]

drussell-x: all agreed. If you follow this task up to its story (#1382) you will find many suggestions like that. If you want to expand any, feel free.

[pwalczysko]

Upping the urgency, because this problem was met twice in between:

1. in Toronto, during our US trip, see ​https://docs.google.com/document/d/1nGt1btRoyQxm0CCEcoNLdtteCnSYHxe6tI5YU4RxADA/edit
2. on our own "dogfish" server - difficult to start to use for screenshots from testing, just because of this problem

[jamoore]

Some type of fix/workaround is certainly possible for 5.0.2/5.0.3. Just need to decide if we try to address any more of the LDAP issues at the same time.

[bpindelski]

khgillen's particular issue could be first looked at from the CLI perspective - add an bin/omero ldap command that creates an Experimenter entry (i.e. mimics a login by the user) for an LDAP username supplied on the CLI (the username has to exist on the LDAP server, to which OMERO is configured to "speak"). This command would have to respect all omero.ldap.* settings.

Basically, ​https://github.com/openmicroscopy/openmicroscopy/blob/develop/components/server/src/ome/logic/LdapImpl.java#L386 but without the password checking line and limited to be called only by the Role.ADMIN OMERO users (or even only root).

[jamoore]

Blazej: sounds exactly right. See also bin/omero ldap discover which finds LDAP accounts even without a specific username. As Ola has pointed out, probably these should be turned into remote methods rather than being implemented in Python.

[bpindelski]

After speaking with jamoore, two direct steps that can be taken to assist fixing this RFE are:

• add new Python methods in the ldap.py plugin - "create <ldap_username>" and "create-all". The latter will be a combination of "discover" and "create",
• (lower priority) move the logic of "bin/omero ldap discover" server-side (the Python method should make use of sf.getLdapService().

[bpindelski]

Initial work (test cleanup) started on ​https://github.com/bpindelski/openmicroscopy/tree/11660_ldap_enhance.

[bpindelski]

PR now open ​https://github.com/openmicroscopy/openmicroscopy/pull/2283.

[bpindelski]

Closing. ​PR 2283 merged. The "create-all" method can be handled in 5.0.3.