Role Management

Added by Rod Gustavson, last edited by Rod Gustavson on Nov 24, 2009  (view change)

This Document is a Work In Progress 

Functional

Roles may be declared or intrinsic or a combination of both:

  • Declared roles mean that somebody has said that a person has a role.
  • Instrinsic roles are derived from some attributes or information about a person.  For example, Faculty roles can be driven from a person's HR position information.
  • Both may be allowed.  Configuration information controls how the system handles conflicts when the declared and intrinsic data overlap.  A role can be configured to allow opt-in or opt-out or not.
    • A person may opt-out of a role, in which case they should not be re-added by the intrinsic rules.
    • A person may opt-in a role, in which case they should not be removed by intrinsic rules.

Roles can be hierarchical, meaning that a role may be made up of one or more sub-roles.  When a role is hierarchical, you can only add memberships at the leaf level.  All other roles up to the root are automatically processed by the Role Management system.

Roles are grouped into categories.  These categories allow for the assignment of different contacts, approvers and rules.

Roles have an effective date range.  Both the start and end dates can be future dated.  The end date may be open-ended (null). 

Roles can be associated with an Org.  The org can be at any level of the org's hierarchy.  The org can be from any pre-defined hierarchy. The Role Management system does not define or manage the org hierarchy. 

A person may have more than one of the same role, as long as the org type and org are unique (aka, category, role, org type and org id make up the primary key).  

The Web Service and Identity Store provide functionality for role questions with hierarchies.  For example, find the Business Manager for a person using that person's primary org id.

Roles may manifest themselves in one or more of the following places.  Roles always manifest themselves in the ID Store, and therefore the IDM Web Service.  Where and how a role manifests is part of the role's configuration, and may change over time. 

  • Identity Store
  • IDM Web Service
  • AD Groups
  • YAS
  • OIM Groups
  • Oracle Roles
  • Unix Groups
  • START People Lists (or START may be recoded to use the Role Manager instead).

Only roles without org attributes may manifest themselves in the AD and OIM as those systems do not support attributes.

Roles can be delegated to another person.  This delegation has an effective date range, which may be in the future and open-ended.  The delegation itself may be for a specific org, but the primary person must have responsibility for that org.

Access to the role membership information may itself be restricted using roles, meaning that only certain applications or people can see the membership. 

The ID Store and the IDM Web Service can be asked the following.  In all cases, the question can be adjusted to include where the effective start date is sometime in the future (will have a role), or the effected end date is in the past (had a role).  By default, the question is only for current roles.

  • List all the members of a role.
  • List all the sub-roles for a role.
  • List all the parents for a role.
  • Does a person have a role?
  • Does a person have a role for an org (the org can be at any level in the org's hierarchy).
  • List all the roles for a person.
  • Walk a hierarchy independent of a role (??)

The following set operations can be performed by the ID Store and IDM Web Service.  Set operations can include an org ID as well (e.g., list all faculty members and staff members of an org).

  • List the union of members of two or more roles.
  • List the intersection of members of two or more roles.
  • List the relative complement of members of two roles.

Data Model

  1. ID Store Role Table (Potential).  Optimized for reads.  Can have multiple rows with the same role name.  FQN is PK.  There is an exploded copy of the hierarchy for fast queries by org.
    1. Category (e.g., IDM Roles, HR Roles, TAA Roles,
    2. Role Name (e.g., Net ID Provisioner)
    3. Date Assigned (Date/Time the role was last assigned -- Improv has complete history)
    4. Date Removed (Date/Time the role ended -- Improv has complete history -- allows systems to detect role changes)
    5. Associated Org (optional Org ID)
    6. Parent Role (null if at the root for the category).
    7. FQN (Fully Qualified Name including all parent roles;  UPI; Org ID; Role Name; Parent Role; All Additional Parents)
    8. Assigned To (UPI of the owner)
    9. Delegated Flag (Y if the role is currently delegated to another user)
  2. Delegated Roles Table
    1. FQN of role being delegated.
    2. Delegated To (UPI)
    3. Delegated Start Date
    4. Delegated End Date
    5. Delegated For Org

Documents

  Name Size Creator (Last Modifier) Creation Date Last Mod Date Comment  
JPEG File Role Management Overview Alt.jpg 519 kb Rod Gustavson Jun 16, 2009 Jun 16, 2009  
JPEG File AD Group Hierarchies.jpg 447 kb Rod Gustavson Jun 16, 2009 Jun 16, 2009  
JPEG File Role Management Overview.jpg 537 kb Rod Gustavson Jun 16, 2009 Jun 16, 2009  

Labels

 
(None)