...
This component is used by the Person Registration and Update Service to determine the likelihood that an incoming identity record matches an already existing record. This component will return to the Person Registration and Update Service an evaluation of ‘Exact Match’, ‘Possible Match’, or ‘No Match’. The Person Registration and Update Service can then use this information to register a new person, link new affiliation information to an existing person, or trigger an institutional workflow to resolve an inconclusive match.
Unique Identifier
...
Creation Service
This component handles any necessary assignment or update of identifiers required to register identity information to the Entity Registry. Examples might include internally unique identifiers used by the Entity Registry as well as institutionally significant identifiers such as ID card numbers, badge numbers, login identifiers, etc.
Master Person
...
Store
The Master Person Info Store is the persistent storage repository for Entity Registry data. The Master Person Info Store contains demographic, affiliation, contact and account data relating to Entity Registry subjects. This data is accessible to other TIER components through both messaging and API interfaces. Data within the Master Person Info Store is used to drive grouping, provisioning and attribute release to service providers.
The Master Person Store may be implemented as a standalone data repository that serves the TIER architecture, but may also be implemented as an interface to an existing institutional Person Store (e.g. LDAP, AD or other institutional repository) that serves a similar purpose.
Groups Service
The Groups Service uses affiliation information from the Entity Registry to drive creation and maintenance of automatically maintained (data-driven) groups. These groups can be used to drive mailing lists, authorize users to applications, or trigger provisioning or deprovisioning workflows. In addition to automatically maintained groups, the Groups Service provides a mechanism for managing manually-maintained (ad-hoc) groups.
Automatically Maintained Groups
This component uses affiliation information affiliations (collections of attributes representing a person's relationship with the institution) in the Entity Registry to form dynamic, data-driven groups based on a person’s affiliation data. For example, a person receiving an ‘employee’ affiliation in the Entity Registry can be dynamically added to an ‘all employees’ group, a group based on their employing department, a group based on their title or job type, and other specific groups based on affiliation data. These groups memberships can be used to populate mailing lists, authorize users to applications or trigger dynamic provisioning workflows.
Similarly, changes to affiliation information can trigger removal from data-driven groups. A person losing an employee affiliation can be removed from employee-related groups, automatically removing authorization and triggering deprovisioning workflows.
Automated grouping can use any attribute data that's associated with a person to form dynamic groups. Class rosters, lists of students by major and employees by title or department are all examples of groups that can be created and maintained dynamically based on attribute data.
Manually Maintained Groups
Manually maintained groups provide a mechanism for the community to express ad-hoc grouping relationships that are not represented in any institutional data repository. Members of a working group or committee may not have a specific affiliation that designates them as such, but a manually maintained group can be created and populated in order to provision resources or grant access based on group membership.
A manually maintained group membership can then be used as an attribute about a person, so can be combined with automated grouping to provide a rich authorization and grouping structure. For example, an application can use an authorization group that is driven primarily by an automatically maintained group containing affiliations that are authorized (e.g. students, faculty, etc), but can also contain a manually maintained group of users that may not meet the dynamic criteria but have been granted access manually. Additionally, grouping math can subtract a manually maintained list of 'suspended' users even if they're included in an automatically maintained group that would grant them access.
Groups Data Store
The Groups Data Store is the persistent store of information provided by the Groups Service. This component provides both API and messaging-based interfaces for other TIER components to receive information about an identity subject’s group memberships.
...
The Provisioning Service component provides the TIER architecture with a mechanism to take action to provision accounts and access either dynamically based on affiliation data changes, or manually based on a request and approval workflow. Likewise, the Provisioning Service works to dynamically deprovision services and remove access when affiliations are removed data events occur that impact institutionally defined provisioning rules (e.g. employee termination).
...
Group-Based Provisioning
The RuleGroup-Based Provisioning component performs provisioning and deprovisioning actions based on group data defined within the Groups Service. For example, a person that has been dynamically added to the ‘all employees’ group can be dynamically provisioned any resources that should be provided to all employees. When that person is dynamically removed from the ‘all employees’ group, resources can be dynamically deprovisioned.
Resource Catalog
The Resource Catalog defines the set of services, applications and other resources that a user might request using Request-Based Provisioning. The Resources Catalog presents a menu of possible options based on a user’s group memberships, and routes approval based on workflow defined for each catalog item. For example, an institution may limit access to a particular software application to only those users that express a need, in order to limit licensing cost. Once a user has requested, an approval workflow can be triggered (if required) and access can be granted using Request-Based Provisioning.
Request-Based Provisioning
The Request-Based Provisioning component provides a mechanism for users to request access to a service or resource that is not provisioned dynamically. Request-Based provisioning could invoke an approval workflow that triggers an approval request to a supervisor or resource owner. Request-based provisioning can also provide an audit trail detailing the path by which a person was approved access to a resource.
Resource Catalog
For example, a Business Intelligence application might have a set of data views that are not granted to all users, but can be granted to specific users on request and after an appropriate set of approvals. A user could request a particular Business Intelligence Dashboard from the Resource Catalog which should trigger an approval workflow that routes first to the employee's supervisor and then to a data custodian for approval.
Request-based provisioning can be combined with group-based provisioning to ensure that the requesting user has any additional group memberships required for access. In the above example, the Business Intelligence Dashboard can require not only an approval flow, but also membership in a group of users that that have a sensitive data compliance form on file and another group that have completed sensitive data training within the last yearThe Resource Catalog defines the set of services, applications and other resources that a user might request using Request-Based Provisioning. The Resources Catalog presents a menu of possible options based on a user’s group memberships, and routes approval based on workflow defined for each catalog item.
Approval Workflow
The Approval Workflow component manages the process by which a requested catalog item is approved or denied. For example, an employee seeking to access a specific data set the Business Intelligence Dashboard described above may request it in the Resource Catalog, which triggers an approval workflow that routes first to the employee’s supervisor and then to the data custodian. The Approval Workflow component provides an audit trail that records the path by which a user was granted access to a resource.
Approval workflows may also be triggered outside of the context of a user's request. For example, an institution's Internal Audit department may have an auditing requirement that states that access to a particular financial application must be reviewed on an annual basis. To meet this need, an automated attestation workflow can be triggered annually to record a supervisor's approval that this access is still needed. The attestation process and resulting approvals can be logged and audited, serving as a business record to meet the Internal Audit department's requirement.
Provisioning Connectors
Provisioning Connectors provide the interface between the provisioning system and institutional resources such as applications or infrastructure. For example, a provisioning rule may establish that all employees are to be provisioned accounts in the campus Active Directory Service. The Active Directory Provisioning Connector will interface with Active Directory to dynamically create the account.
...