Background

COmanage Registry started with a relatively simple permissions model, which has remained relatively unchanged since the earliest versions. However, as deployment patterns have evolved, use cases have been identified for evolving this model forward.

Issues For Discussion

  1. A more flexible/sophisticated model for COU Administrator permissions. This had originally been proposed in CO-505, and is the subject of a Community Working Group Proposal (and uncommitted Implementation Proposal).
  2. A new authorization level for HelpDesk personnel (CO-1156).
  3. Record and Attribute Release Policies (CO-1524).
  4. Private CO Groups (CO-1606).
  5. Whether or not unprivileged CO People can even login to Registry (for a given CO, if the person is a member of more than one).
    1. Note this can mostly be accomplished already by not setting the Login flag on the appropriate Identifier.
  6. Rationalization of COU Administrator capabilities, especially inherited permissions (ie: when a person is a COU Admin for a parent COU).
    1. See also Notifications that go to a COU Administrator - should they also go to administrators of the parent COU? Should this be configurable?

Application Privileges

Generally speaking, a Platform Administrator has full access to the entire COmanage instance, and a CO Administrator has full access to their CO. Below that, the following actions may be of interest for assigning permissions:

  • Viewing a CO Person Record
  • Adding or Editing a CO Person Record (excluding Enrollment Flows, which have their own permissions configuration)
  • Viewing CO Person History
  • Adding a History comment
  • Viewing CO Person Provisioning Status
  • Re-provisioning a Target
  • Viewing a CO Person Role Record (for their own COU, or for other COUs)
  • Adding or Editing a CO Person Record (for their own COU)
  • View associated CO Person data, such as CO Petitions, Authenticators, Clusters, etc.
  • Creating a CO Group (see also CO-1637)
  • Setting the Owner (or Manager) of a CO Group
  • Setting the Membership of the CO Group
  • Viewing the configuration of a CO Group
  • Viewing the Membership of a CO Group
  • Viewing results in the People Finder
  • Viewing results via Global Search
  • Plugin specific actions
  • this list is probably not exhaustive

Application Privileges could be assigned to CO Groups, in order to allow for multiple levels of permissions (beyond COU Administrator and HelpDesk). For transitional purposes, permissions mapping to the current behavior could be auto-assigned to existing COU Admin groups (and perhaps to new COU Admin groups when they are created).

Alternately, the CO Role concept (CO-1521) could be introduced, with Application Privileges attached to the Role.

Attribute Release

Attribute Release policies could be attached to each CO Person, CO Person Role, or (complex/MVP) Attribute. Registry would not directly be affected by these policies, rather the expectation is that provisioners that were capable of processing Attribute Release policies would handle them appropriately. For example, the LdapProvisioner would most likely add attributes or attribute options to a record to indicate appropriate policies.

The complexity level that needs to be supported could range from a simple "blanket policy" model to a per-SP model. However, the latter might be more suitable for a component like CAR.

Backlog Planning


  • No labels