LDAP: remove DN from OMERO DB.

[jamoore]

Before 4.3.2, LdapPasswordProvider? Was only using the dn for checking a users password. Starting with 4.3.2, the query with filters that is initially used to look the user should be used, but the DN is still being stored. We could stop storing the DN of the user, and only store a flag "in_ldap" (or perhaps the connection information for the case of multiple server support).

See #6248 (4.3.2) for the work to check on every login.. Removing the DN to prevent synchronization errors, etc. still remains undone.

It may also be the appropriate time to remove the "password" table altogether, in combination with any work for specifying the DN or at least the source ("native", "LDAP") of groups. See #6719.

[jmoore]

​http://lists.openmicroscopy.org.uk/pipermail/ome-users/2011-September/002838.html

[bpindelski]

Referencing ticket #8344 has changed sprint.

[jmoore]

Referencing ticket #8344 has changed sprint.

[jmoore]

Pushing. If we do anything along these lines in 4.4, it may have to be as a special release for production-grade sites.

[jmoore]

Solution taken is to set a boolean "ldap" on the experimenter table for ever row in "password" that has a non-empty DN and then delete the "dn" column.

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)

[jamoore]

Re-opening after a discussion with Blazej about using an existing DN as the is_ldap flag.

[bpindelski]

Josh's general impression is that this ticket can be tackled without a DB change, which is a bit counter-intuitive to the title and description of this ticket. What's really missing here is an exemplary failing use case which can be handled by adding logic that checks the contents of the password.dn column (if not empty, user is from LDAP). As this type of logic is already present in most of the LDAP-handling code, I still don't see what this ticket should fix (in the no-DB-changes scenario)? Where will the mentioned is_ldap flag be used?

[jamoore]

Briefly, though we can discuss more tomorrow, the failing case is:

• user is created with DN, e.g cn=jdoe,ou=LabFoo
• user's DN changes to cn=jdoe,ou=BarLab (or even ou=FooLab, or ou=LabFoo,o=Uni -- this happens more than we expected)
• user can no longer log in.

The workaround here is to just say, if a user has any DN, i.e. !StringUtils.isEmpty(dn), then we consider this to be equivalent to is_ldap==true regardless of what the DN value is.

[bpindelski]

After another round of scoping, it has been agreed that DB changes are fine to do during 5.1 and that the existing branch in Josh's repo has a workaround approach (at that time there was no possibility for breaking API changes). What needs to happen:

1. The use case mentioned in ​https://trac.openmicroscopy.org.uk/ome/ticket/2587#comment:12 still holds and needs to be fixed.
2. The dn column from password has to be dropped with a DB update script and an ldap column added to experimenter (set to true for each user who already had a DN set in the DB; false otherwise).
3. bin/omero ldap setdn has to switch from accepting strings to using true/false, as the DN will now be only stored in the LDAP server. There might be scope for changing the name of the CLI method so that it resembles the new functionality closer.
4. The interaction between the above changes and omero.ldap.sync_on_login can be ignored for now and handled fully in #6719.

[bpindelski]

Work started on ​https://github.com/bpindelski/openmicroscopy/tree/2587_remove_dn.

[bpindelski]

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

[Josh Moore <josh.moore@…>]

(In [02be324dc62a425842e556a884eacc97ea0fe7ab/ome.git] on branch develop) Merge pull request #3119 from bpindelski/2587_remove_dn

Remove the "dn" column from "password" (fix #2587).