Task #8537 (closed)
LDAP: filter attribute results for new groups
| Reported by: | jamoore | Owned by: | jamoore |
|---|---|---|---|
| Priority: | minor | Milestone: | OMERO-4.4.4 |
| Component: | Security | Version: | n.a. |
| Keywords: | n.a. | Cc: | bpindelski |
| Resources: | n.a. | Referenced By: | n.a. |
| References: | n.a. | Remaining Time: | 0.0d |
| Sprint: | 2012-08-14 (2) |
Description
See: https://www.openmicroscopy.org/community/viewtopic.php?f=5&t=1095
Any groups found as an :attribute: on the user's directory entry should first be filtered through the group_filter. We will need to check how this effects users already using :attribute:
Related code:
Change History (10)
comment:1 Changed 12 years ago by bpindelski
comment:2 Changed 12 years ago by jmoore
Referencing ticket #8344 has changed sprint.
comment:3 Changed 12 years ago by jmoore
- Milestone changed from OMERO-Beta4.4 to OMERO-Beta4.4.1
Pushing with other LDAP tickets to 4.4.1
comment:4 Changed 12 years ago by jmoore
- Milestone changed from OMERO-4.4.x to OMERO-4.4.2
- Sprint set to 2012-08-14 (2)
- Status changed from new to accepted
Starting work on LDAP. Need to keep in mind that there may be others who expect the previous (though incorrect) logic so we'll need to preserve that version as LdapAttributeVersion441 (or whatever).
comment:5 Changed 12 years ago by jmoore
- Resolution set to fixed
- Status changed from accepted to closed
Fix pushed to https://github.com/openmicroscopy/openmicroscopy/pull/283
Rather than Attribute441Etc. it's now ":attribute:" and ":filtered_attribute:".
Blazej, are you up for taking over the testing of PR 283?
comment:6 Changed 12 years ago by bpindelski
- Cc bpindelski added; b.pindelski@… removed
comment:7 Changed 12 years ago by jmoore <josh@…>
(In [6c40fad603a2619b1f6600ad9236690de03219e6/ome.git] on branch develop) Failing LDAP attribute filter test (See #8537)
attributeFilter has a user who should fail to be created
since there's no group named "ThisGroupDoesNotExist?". At
the moment, the user is being created and so the test
fails.
comment:8 Changed 12 years ago by jmoore <josh@…>
- Remaining Time set to 0
(In [5cc01018d40cda46b15e1ebe48e1784edc6077f1/ome.git] on branch develop) Create :filtered_attribute: handler (Fix #8537)
In order to provide filtered attribute support,
a new handler ":filtered_attribute:" was added.
This checks that any attributes are also found
by the omero.ldap.group_filter.
Used the opportunity to refactor LdapImpl? since
the various handlers were all slightly different.
comment:9 Changed 12 years ago by jmoore <josh@…>
(In [8f814565ba7cab83c1e2c623b562ef2bd1180f9e/ome.git] on branch develop) Add DN-based attribute support (See #8537)
Since memberOf is DN-based rather than name based,
it was necessary to add several more new_user_group
prefixes. These take the found value and parse it as
a DistinguishedName?.
comment:10 Changed 12 years ago by jmoore <josh@…>
(In [22bacf140460fb4e8dfc9e2cec844584a892f036/ome.git] on branch develop) Explicitly load attributes where applicable (See #8537)
In the case of overlays (for OpenLDAP), Spring (and possibly
the Java LDAP implementation in general) does not load all
attributes unless they are explicitly requested. For the
AttributeNewUserGroupBean?, the requested attribute is now
passed to SearchControls?.setReturningAttributes with the
other values needed by omero.ldap.user_mapping.
Referencing ticket #8344 has changed sprint.