Creating Digital Identities - ID Match
Brief Description
Most universities have multiple Systems of Record through which individuals are "registered" as part of the identity management system. Typical Systems of Record include a Student System, HR system for staff, Alumni system, Guest/Affiliate System, etc. The identity match or "join" process compares identity data across Systems of Record to ensure that a single identity is created, modified, and deleted for an individual, even if that individual exists in more than one System of Record simultaneously and/or moves back and forth between Systems of Record.
Generic Functional Requirements
- Multiple source data inputs including systems of record as well as identity registry
- Data normalization
- Match on multiple attributes
- Weighted attribute and source matching
- Use business rules
- Use business process management for work flow
- Pushes unmatched identities to external manual intervention
- Database, REST, ESB, LDAP for upstream / downstream connectors
Standards Support and Integration Considerations
Key Design Considerations
- Allows Push or Pull from Systems of Record
- Allows Realtime and Batch inputs
Technical Solutions
- Open Registry
- Mural
- BPMN2
Manage Digital Identities - Self-Service
Brief Description
These are all the functions that make it easier for a person to create, update, and/or expire their digital identity. Which self-service tools a person has access to may depend on the level of assurance the system has about a person's identity and to which applications a person has access.
Generic Functional Requirements
- Ability to create one's own digitial identity (for guests)
- Ability to reset one's own passphrase (based on some stored information such as the current passphrase or questions)
- Ability to view one's own data in the system
- Ability to update one's one data (such as email address or other directory information
- Ability to send in feedback/request help
- Ability to expire (but not delete) one's own digital identity
- Ability to provide or deny access to the above based on stored information about the individual
- Logging of activity for auditing and trouble shooting purposes
Standards Support and Integration Considerations
Where possible, avoid non-standard technologies which require specifically integrated vendor components to be deployed.
Key Design Considerations
Technical Solutions
Manage Digital Identities - Administration and Delegation
Brief Description
This covers the process by which a person receives an initial digital identity or updates an existing digital identity when verification of identity cannot be handled using self-service tools. This can be due to a need for higher level of verification of identity or an inability by an individual to use the self-service tools.
Generic Functional Requirements
- Automated creation of initial digital identity based upon on-boarding data from source systems
- Automated expiration of a digital identity based upon data from source systems
- Ability to recognize and consolidate identities for an individual if the individual exists in more than one source system
- Allows for the delegation of tasks based on customer identity (such as "the students in my department")
- Allows for the delegation of tasks based on user's level of access (ie super user, assist students only, work only from a specific set of machines)
- Ability to issue a single use token for resetting of passphrase
- Ability to view/search relevant data in the system
- Ability to update data which is not based on source system data
- Ability to expire or delete a digital identity
- Ability to track authorization levels based upon level of verification of identity
- Ability to allow a 3rd party to authorize creation of a digital identity
- Logging of activity for auditing and trouble shooting purposes
Standards Support and Integration Considerations
Where possible, avoid non-standard technologies which require specifically integrated vendor components to be deployed.
Key Design Considerations
Technical Solutions
Case Studies
Person Data - Person Registry
Brief Description
One flexible model is to keep the IdM database of person data separate from any IdM one or more directories. The IdM's internal directory in this case ideally contains primarily authentication-related data while all authorization and related data about users and systems resides in the relational data store or registry. This IdM-private data kept in this repository is in turn replicated as may be needed to one or more external-facing read-only directories, or otherwise exposed via APIs.
Generic Functional Requirements
- Effectively model many data relationships, including many-to-many relationships among identity data elements
- Storage of user role data in support of IdM functions
- Data model support for coarse-grained access control
- Storage for data about associated or groups of application roles (related roles often provisioned in tandem)
- Support for audit logging of activities, including support for the recording of historical changes made to sensitive data. This log would include the requester and authorizer identities, and transaction timestamps.
- Storage of user, organization, and external application details
- Storage for security questions and answers used for password recovery
- Storage for data about upstream systems of record, protected applications (those under access control), and associated systems (those which require provisioning of user data)
Standards Support and Integration Considerations
Where possible, avoid non-standard technologies which require specifically integrated vendor components to be deployed.
Key Design Considerations
- Look for designs which follow principles of master data management. For example, systems which allow to identify the authoritative source for each data item and which avoid creating unneeded replicas of such data.
- Favor systems which easily model application-specific roles over global or institutional roles in most cases to simplify the effort needed for doing extensive roles engineering.
Technical Solutions
Systems based on commodity database solutions such as MySQL or PostgreSQL
Case Studies
See the IdM database design tips in the LIMA design model and the OpenRegistry community project.
Person Data - Directory Services
Brief Description
One flexible model is to keep the IdM internal person directory separate from the IdM database of identity data. The latter is primarily used in support of authorization and related functions while the directory is ideally very data lightweight and used primarily for managing authentication functions internal to the IdM web SSO and access management components. In this case, one or more externally-facing directories may be provisioned from the IdM system and exposed for such business purposes as whitepage information about people, coarse application authorization needs, etc.
Generic Functional Requirements
- Directories can provide authentication services to primary Web SSO systems such as CAS
- Directories can be used to manage authentication policies around passwords
- When used for application-based authorization, the directory must store attributes about users that can provide coarse role information which applications can consume as part of their authorization logic.
Standards Support and Integration Considerations
Where possible, avoid non-standard technologies which require specifically integrated vendor components to be deployed.
Key Design Considerations
Technical Solutions
- Commodity LDAP technologies such as: