You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Introduction

This glossary describes the functional components of the TIER Reference Architecture.

Identity Sources

While not a part of the TIER Architecture, identity sources provide person-related data into the TIER architecture. This data likely includes the following types of information:

  • Name information
  • Sufficient demographic information to disambiguate a person from others
  • Address or location information
  • Contact information (email address, phone, etc)
  • Data related to institutional affiliations (student data, employee data, etc)

Identity source information flows into the TIER architecture and allows TIER to create the appropriate accounts, groupings and other data structures to enable rule-based provisioning and access control.

Campus System

Student Information Systems, Human Resources Systems and other institutional data systems are frequent repositories of person-related information. These systems provide the TIER architecture with information about the people contained within. In addition to basic demographic information, these systems contribute affiliation information that help to form a complete picture about an individual’s relationship with the institution.

Guest / Self Registration

In addition to Campus Information Systems, many institutions provide a mechanism for people to self-register in order to access certain campus services. Visitors may self-register for wireless access, or prospects may self-register for a campus tour. This user-initiated process provides another registration path into the TIER architecture.

Invitation Service

An invitation service provides a mechanism for an existing member of the campus community to invite someone to establish a relationship with the institution. A researcher can invite a collaborator from another institution to establish a relationship and thus be provisioned access to an appropriate set of institutional resources.

 

Entity Registry Components

The TIER Entity Registry is principally responsible for supplying person-related information to the other TIER architectural components. The Entity Registry has several key responsibilities:

  • Aggregate person information from multiple data sources,
  • De-duplicate information from multiple sources in order to present a single representation of a person and their various relationships to the institution, and
  • Standardize person information for consumption by downstream components in the TIER architecture.

 

Within the Entity Registry, there are several components that work together to establish a structured repository of identity data. These components include:

Person Registration and Update Service

This component provides the interface between identity sources and the rest of the TIER architecture. The Person Registration and Update Service provides API and messaging interfaces for identity sources to register and update identity data within the Entity Registry.

Search / Match

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.

Identifier Assignment

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.

Person Info Store

The Person Info Store is the persistent storage repository for Entity Registry data. The 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 Person Info Store is used to drive grouping, provisioning and attribute release to service providers.

 

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 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.

 

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.

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.

 

Provisioning Service

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 (e.g. employee termination).

Rule-Based Provisioning

The Rule-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.

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

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.

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 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.

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.

 

Authentication and Federation Services

Authentication and Federation Services provide a means to interface service providers with the TIER architecture to perform single-signon, federated authentication and authorization and to deliver attribute information for consumption by applications.

Single Signon Authentication (SSO AuthN)

This component provides a mechanism for users to authenticate once into a single institutional authentication process, and to have that authentication respected by a number of applications. Single Signon Authentication may also incorporate additional forms of authentication such as multi-factor authentication (MFA) to achieve a stronger authentication session for applications that require it.

SAML and Oauth Identity Providers (IdPs)

These components work with SSO AuthN and Attribute Resolver services to provide standards-based mechanisms for interfacing applications with institutional SSO. Vended applications and cloud providers that support either the SAML or Oauth protocols can be interfaced with institutional SSO and can receive user attributes through the SAML and Oauth IDP components.

Consent Service

The Consent Service component engages the user in the attribute release process by providing a mechanism to prompt the user for a decision about whether or not it is appropriate to release a particular data element to a requesting application. For example, a user authenticating to a cloud service that requires an email address can be prompted whether or not they choose to release their email address to the application. As privacy regulations mature and application integration becomes increasingly distributed, user consent is expected to become an increasingly important component.

Relying Party Data (aka Metadata)

The Relying Party Data component keeps track of the relationship between authentication services and service providers. This component tracks metadata about each service provider including the security components to validate the service provider and the attribute release policies that determine which attributes should be provided to each service provider.

Attribute Resolver

The Attribute Resolver component translates between the internal data structures in the TIER architecture and the attributes that are delivered to service providers. The attribute resolver maps specific internal data constructs to normalized attributes so that service providers do not need to be aware of the inner workings of the TIER architecture to consume attribute information about users that are accessing their services.

  • No labels