Task #11660 (closed)
Opened 10 years ago
Closed 10 years ago
RFE: Don't require ldap/ad users to log in before being allocatable to groups
Reported by: | khgillen | Owned by: | bpindelski |
---|---|---|---|
Priority: | critical | Milestone: | 5.0.2 |
Component: | Deployment | Version: | n.a. |
Keywords: | n.a. | Cc: | ux@…, atarkowska, drussell-x |
Resources: | n.a. | Referenced By: | n.a. |
References: | n.a. | Remaining Time: | n.a. |
Sprint: | n.a. |
Description (last modified by bpindelski)
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.
Change History (15)
comment:1 Changed 10 years ago by jamoore
- Cc drussell-x added
- Priority changed from minor to major
- Summary changed from RFE: Don't require ldap/ad users to log in before being allocatable to gorups to RFE: Don't require ldap/ad users to log in before being allocatable to goroups
comment:2 Changed 10 years ago by 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.
comment:3 Changed 10 years ago by 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.
comment:4 Changed 10 years ago by pwalczysko
Upping the urgency, because this problem was met twice in between:
- in Toronto, during our US trip, see https://docs.google.com/document/d/1nGt1btRoyQxm0CCEcoNLdtteCnSYHxe6tI5YU4RxADA/edit
- on our own "dogfish" server - difficult to start to use for screenshots from testing, just because of this problem
comment:5 Changed 10 years ago by pwalczysko
- Priority changed from major to critical
comment:6 Changed 10 years ago by jamoore
- Component changed from General to Security
- Milestone changed from Unscheduled to 5.0.2
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.
comment:7 Changed 10 years ago by bpindelski
- Description modified (diff)
- Summary changed from RFE: Don't require ldap/ad users to log in before being allocatable to goroups to RFE: Don't require ldap/ad users to log in before being allocatable to groups
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).
comment:8 Changed 10 years ago by 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.
comment:9 Changed 10 years ago by 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().
comment:10 Changed 10 years ago by bpindelski
- Owner set to bpindelski
comment:11 Changed 10 years ago by bpindelski
- Component changed from Security to Deployment
comment:12 Changed 10 years ago by bpindelski
Initial work (test cleanup) started on https://github.com/bpindelski/openmicroscopy/tree/11660_ldap_enhance.
comment:13 Changed 10 years ago by bpindelski
comment:14 Changed 10 years ago by bpindelski
- Status changed from new to accepted
comment:15 Changed 10 years ago by bpindelski
- Resolution set to fixed
- Status changed from accepted to closed
Closing. PR 2283 merged. The "create-all" method can be handled in 5.0.3.
See: https://github.com/openmicroscopy/openmicroscopy/pull/1827 for a partial workaround for this issue from Douglas.