Make Groups Useful: Interoperability with other group providers

[danhorst]

Further details on implementation:

• Hydra::Groupy gem
• Design Discussion from Notre Dame

Issue #421 defined the requirements for managing groups throughout the Administrative UI. It did not address how the group implementation could be extended to work with other back-end sources for groups.

Many adopters of Hyku will already have systems that manage groups of users e.g. LDAP, Shibboleth, Grouper, etc. Hyku should be able to leverage this knowledge. There are two approaches to solving this problem:

1. Use an import process to cache group information from an external system into a different storage layer e.g. a generic ActiveRecord group model.
2. Make API calls to an external group management system while interacting with the repository.

The first approach pushes complexity onto the process that keeps the two systems in sync. There may be a long delay before changes propagate between systems e.g. “you’ll have to wait for a nightly job for your account to have access.” Each type of external system will need a mapper to coerce a record into the repository storage layer. There may need to be a mechanism to filter or restrict the number of groups imported by the synchronization process as not all groups are relevant to repository functions.

The second approach effectively eliminates the lag between updates to the group management system and interactions with the repository system. It does this at the expense of introducing latency and fault tolerance concerns whenever group information is needed. This could be as often as on every request a user makes—or at least every time current_ability is computed. An abstraction layer will be needed between Hyku and the external group providers. Each type of group provider would need to implement an adapter for the abstraction layer.

Which approach should we take?

[atz]

IMHO, the latter is too expensive without caching. Hitting LDAP/Shib/etc. each request (even after successfully logging in) is not an acceptable application behavior. I would accept a version that:

• retrieves and copies/caches group information at login/session start
• optionally, adds an explicit "refetch creds" button to the user profile page that does the same update (basically saves them having to fully logout/login).

[mjgiarlo]

@atz 💬

optionally, adds an explicit "refetch creds" button to the user profile page that does the same update (basically saves them having to fully logout/login).

We had this in ScholarSphere, FWIW, and could consider reconstituting that feature from ScholarSphere in Hyku or Hyrax.

[hannahfrost]

Thanks for typing this up, @danhorst . This is definitely on our road map, but I'm going to put in the backlog since it is out of scope for MVP.

[jeremyf]

A solution I had explored is that as part of the login, you get a set of "keys" to each of the groups you belong to. That is persisted/cached locally, and used for further querying.