Overview

A common deployment pattern is to connect a COmanage Registry instance with Grouper for more advanced group and authorization management capabilities. The Grouper Provisioning Plugin provides the capability to export Registry data to a Grouper instance. However, there are use cases where it makes sense to provision the group data back to Registry, including:

  • To use composite groups to define membership in a group used by Registry for authorization or other purposes, such as enrollment flow approval or notification groups.
  • To provide a single interface to manage a person's data, including group memberships.

Considerations

  1. COmanage is multi-tenant, but Grouper is not. A single CO can also be connected to multiple Grouper instances.
  2. Grouper groups are hierarchical, while COmanage groups are generally flat.
  3. There may be numerous groups in Grouper, including intermediate composite groups, for which there is no reason to synchronize back to Registry.
  4. There must be a way to identify groups and people uniquely and consistently across both systems.

Approach

The proposed approach would use SCIM as the transport mechanism.

comanage-grouper-via-scim

  1. Deploy the Grouper Provisioning Plugin.
    1. What will the person subject identifier be between COmanage and Grouper? Perhaps configurable to any existing identifier type? Still need to identify the CO somehow... perhaps as metadata on the stem of groups to synchronize back from Grouper?
    2. What needs to be written to LDAP to use that as the subject source instead of the database view?
    3. Ordering of provisioning may be an issue if we switch to Grouper using LDAP as the subject source instead of a COmanage table. Grouper cannot add a membership to a group for which it cannot find the subject, so that subject has to exist in LDAP well before any invocations of the Grouper-WS to add the subject to a group. Since COmanage CO admin and members groups are provisioned as soon as a CoPerson object is created this may cause problems if the Grouper provisioner fires before the LDAP provisioner. See this Jira issue.
  2. Define a stem in Grouper which contains all groups to backsync to COmanage.
    1. Attach server URL, CO identifier, and credentials to stem?
    2. When changes to groups in this stem are made, the changelog consumer will update COmanage.
  3. Implement a SCIM endpoint in COmanage.
    1. The CO ID must be determinable from the request. The most compatible option is probably as part of the server prefix. eg: https://server.edu/registry/scim/2/v2/Users/abc123
    2. The SCIM person identifier can be mapped via the identifiers table.
    3. The Group name must be resolvable. It could simply be the same as the COmanage group name, or it could be the numeric identifier.

Gaps

  • Implement ordered provisioning so that the LDAP provisioner fires before the Grouper provisioner.
  • Implement SCIM server support in Registry.
    • Although COmanage is multi-tenant, the REST API is currently super-user only.
  • Implement SCIM client (changelog consumer) support in Grouper.

 

  • No labels