LDAP: Add DN for groups

[jamoore]

While working on #6248 (#6702 et al) it was brought up that perhaps we shouldn't remove users from groups that are not present in LDAP. To safely do that, however, we will need to detect which groups were created via LDAP by setting a DN for them. These values may should be exposed via the Hibernate objects (experimenter, experimentergroup) rather than as a hidden column of the permission table. Administrators would need to set the DN for all of their LDAP groups after the upgrade.

See also #2587 which points perhaps to a "SOURCE" column rather than the actual DN. If each experimenter and or experimenter-group could be flagged as "from LDAP" or similar, then we wouldn't need to duplicate and synchronized the DN. Would we need to include the LDAP source URL, though? What happens if it changes? Do we then need an "LDAPSource" in the DB? Etc.

[bpindelski]

Referencing ticket #8344 has changed sprint.

[jmoore]

Referencing ticket #8344 has changed sprint.

[jmoore]

Pushing.

[jmoore]

Solution taken is the simplest of adding an "ldap" column to the experimentergroup table. The setDN method will be overloaded to allow enabling/disabling this flag on groups.

Work currently pushed to ​https://github.com/joshmoore/openmicroscopy/tree/8344-ldap-groups for review. That branch will need to be rebased so I haven't yet created a PR. Exposing the values via hibernate and other API changes will be done by #9481 (LDAP API breakages)

[jmoore <josh@…>]

(In [9156ab7e83fbd1c121af5d6cba2b168efcc714b7/ome.git] on branch develop) Add test for ldap-only group synchronization (See #6719)

The warning under sync_on_login applies since previously
OMERO couldn't tell if a group was created via LDAP or
not. This (currently failing test) shows that the manually
create group is removed on login.

[jamoore]

Re-opening for possible investigation along with #2587.

[bpindelski]

I've started working on this on ​https://github.com/bpindelski/openmicroscopy/tree/6719_group_dn. The main issue for the upgrade script is the filling in of the "ldap" column values during upgrade. The SQL script itself won't have access to the LDAP server and I don't think there is a way of using the event log to check which groups were created for an LDAP-sourced user (I might be missing some information; I'll check what is stored in the DB during and LDAP user creation). In such a case, we would need a server-startup script which would at most once update the column values by contacting the LDAP server and querying for groups for a user that has "ldap == true".

Josh: any suggestions?

[jamoore]

I would start off by making all groups non-LDAP. Depending on how the functionality is modified to make use of that, we can either tell sysadmins to manually modify, or perhaps provide a bin/omero ldap discover like mechanism for activating the groups.

[bpindelski]

The disabling of the LDAP property for groups initially was indeed something I planned. I do like the idea of a CLI command that would then update the property. Thanks, Josh.

[bpindelski]

Work started on ​https://github.com/bpindelski/openmicroscopy/tree/6719_group_dn.

[bpindelski]

Things left to do:

• bin/omero ldap discover for groups,
• setting/resetting of the "ldap" field on a group per CLI and API - the setDN method can certainly be removed, as the "ldap" field can be accessed through the user/group object,
• group LDAP status display in client (Web first, then Insight if applicable),
• review impact of sync_on_login on the current state of model/API changes.

[bpindelski]

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

[Josh Moore <josh.moore@…>]

(In [a374e5c492b1cb3ddb1e588549f02b5e60f44810/ome.git] on branch develop) Merge pull request #3193 from ximenesuk/6719_group_dn

Add DN for groups (fix #6719).