Date: Fri, 29 Mar 2024 06:12:30 +0000 (UTC) Message-ID: <13262810.7531.1711692750212@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_7530_1921114897.1711692750211" ------=_Part_7530_1921114897.1711692750211 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This glossary describes the functional components of the TAP Reference Architecture.
While not a part of the TAP Architecture, identity sources provide perso= n-related data into the TAP architecture. This data likely includes the fol= lowing types of information:
Identity source information flows into the TAP architecture and allows T= AP to create the appropriate accounts, groupings and other data structures = to enable rule-based provisioning and access control.
Student Information Systems, Human Resour= ces Systems and other institutional data systems are frequent repositories = of person-related information. These systems provide the TAP architecture w= ith information about the people contained within. In addition to basic dem= ographic information, these systems contribute affiliation information that= help to form a complete picture about an individual=E2=80=99s relationship= with the institution.
In addition to Campus Information Systems= , many institutions provide a mechanism for people to self-register in orde= r to access certain campus services. Visitors may self-register for wireles= s access, or prospects may self-register for a campus tour. This user-initi= ated process provides another registration path into the TAP architecture.<= /p>
An invitation service provides a mechanis= m for an existing member of the campus community to invite someone to estab= lish a relationship with the institution. A researcher can invite a collabo= rator from another institution to establish a relationship and thus be prov= isioned access to an appropriate set of institutional resources.
The TAP Entity Registry is principally responsible for supplying person-= related information to the other TAP architectural components. The Entity R= egistry has several key responsibilities:
Within the Entity Registry, there are several components that work toget= her to establish a structured repository of identity data. These components= include:
This component provides the interface bet= ween identity sources and the rest of the TAP architecture. The Person Regi= stration and Update Service provides API and messaging interfaces for ident= ity sources to register and update identity data within the Entity Registry= .
This component is used by the Person Regi= stration and Update Service to determine the likelihood that an incoming id= entity record matches an already existing record. This component will retur= n to the Person Registration and Update Service an evaluation of =E2=80=98E= xact Match=E2=80=99, =E2=80=98Possible Match=E2=80=99, or =E2=80=98No Match= =E2=80=99. The Person Registration and Update Service can then use this inf= ormation to register a new person, link new affiliation information to an e= xisting person, or trigger an institutional workflow to resolve an inconclu= sive match.
This component handles any necessary assi= gnment or update of identifiers required to register identity information t= o the Entity Registry. Examples might include internally unique identifiers= used by the Entity Registry as well as institutionally significant identif= iers such as ID card numbers, badge numbers, login identifiers, etc.
The Master Person Store is the persistent= storage repository for Entity Registry data. The Master Person Store conta= ins demographic, affiliation, contact and account data relating to Entity R= egistry subjects. This data is accessible to other TAP components through b= oth messaging and API interfaces. Data within the Master Person Store is us= ed to drive grouping, provisioning and attribute release to service provide= rs.
The Master Person Store may be implemente= d as a standalone data repository that serves the TAP architecture, but may= also be implemented as an interface to an existing institutional Person St= ore (e.g. LDAP, AD or other institutional repository) that serves a similar= purpose.
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 ad= dition to automatically maintained groups, the Groups Service provides a me= chanism for managing manually-maintained (ad-hoc) groups.
This component uses affiliations (collect= ions of attributes representing a person's relationship with the institutio= n) in the Entity Registry to form dynamic, data-driven groups based on a pe= rson=E2=80=99s affiliation data. For example, a person receiving an =E2=80= =98employee=E2=80=99 affiliation in the Entity Registry can be dynamically = added to an =E2=80=98all employees=E2=80=99 group, a group based on their e= mploying department, a group based on their title or job type, and other sp= ecific groups based on affiliation data. These groups memberships can be us= ed to populate mailing lists, authorize users to applications or trigger dy= namic provisioning workflows.
Similarly, changes to affiliation informa= tion can trigger removal from data-driven groups. A person losing an employ= ee affiliation can be removed from employee-related groups, automatically r= emoving 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 ex= amples of groups that can be created and maintained dynamically based on at= tribute data.
Manually maintained groups provide a mech= anism for the community to express ad-hoc grouping relationships that are n= ot represented in any institutional data repository. Members of a working g= roup or committee may not have a specific affiliation that designates them = as such, but a manually maintained group can be created and populated in or= der to provision resources or grant access based on group membership.
A manually maintained group membership ca= n then be used as an attribute about a person, so can be combined with auto= mated grouping to provide a rich authorization and grouping structure. For = example, an application can use an authorization group that is driven prima= rily by an automatically maintained group containing affiliations that are = authorized (e.g. students, faculty, etc), but can also contain a manually m= aintained group of users that may not meet the dynamic criteria but have be= en granted access manually. Additionally, grouping math can subtract a manu= ally maintained list of 'suspended' users even if they're included in an au= tomatically maintained group that would grant them access.
The Groups Data Store is the persistent s= tore of information provided by the Groups Service. This component provides= both API and messaging-based interfaces for other TAP components to receiv= e information about an identity subject=E2=80=99s group memberships.
The Provisioning Service component provides the TAP architecture with a = mechanism to take action to provision accounts and access either dynamicall= y based on affiliation data changes, or manually based on a request and app= roval workflow. Likewise, the Provisioning Service works to dynamically dep= rovision services and remove access when data events occur that impact inst= itutionally defined provisioning rules (e.g. employee termination).
The Group-Based Provisioning component pe= rforms provisioning and deprovisioning actions based on group data defined = within the Groups Service. For example, a person that has been dynamically = added to the =E2=80=98all employees=E2=80=99 group can be dynamically provi= sioned any resources that should be provided to all employees. When that pe= rson is dynamically removed from the =E2=80=98all employees=E2=80=99 group,= resources can be dynamically deprovisioned.
The Resource Catalog defines the set of s= ervices, applications and other resources that a user might request using R= equest-Based Provisioning. The Resources Catalog presents a menu of possibl= e options based on a user=E2=80=99s group memberships, and routes approval = based on workflow defined for each catalog item. For example, an institutio= n 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 req= uested, an approval workflow can be triggered (if required) and access can = be granted using Request-Based Provisioning.
The Request-Based Provisioning component = provides a mechanism for users to request access to a service or resource t= hat 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. For= example, a Business Intelligence application might have a set of data view= s that are not granted to all users, but can be granted to specific users o= n 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 su= pervisor and then to a data custodian for approval.
Request-based provisioning can be combine= d 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 compli= ance form on file and another group that have completed sensitive data trai= ning within the last year.
The Approval Workflow component manages t= he process by which a requested catalog item is approved or denied. For exa= mple, an employee seeking to access a the Business Intelligence Dashboard d= escribed above may request it in the Resource Catalog, which triggers an ap= proval workflow that routes first to the employee=E2=80=99s supervisor and = then to the data custodian. The Approval Workflow component provides an aud= it trail that records the path by which a user was granted access to a reso= urce.
Approval workflows may also be triggered = outside of the context of a user's request. For example, an institution's I= nternal 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 triggere= d annually to record a supervisor's approval that this access is still need= ed. The attestation process and resulting approvals can be logged and audit= ed, serving as a business record to meet the Internal Audit department's re= quirement.
Provisioning Connectors provide the inter= face between the provisioning system and institutional resources such as ap= plications or infrastructure. For example, a provisioning rule may establis= h that all employees are to be provisioned accounts in the campus Active Di= rectory Service. The Active Directory Provisioning Connector will interface= with Active Directory to dynamically create the account.
Authentication and Federation Services provide a means to interface serv= ice providers with the TAP architecture to perform single-signon, federated= authentication and authorization and to deliver attribute information for = consumption by applications.
This component provides a mechanism for u= sers to authenticate once into a single institutional authentication proces= s, and to have that authentication respected by a number of applications. S= ingle Signon Authentication may also incorporate additional forms of authen= tication such as multi-factor authentication (MFA) to achieve a stronger au= thentication session for applications that require it.
These components work with SSO AuthN and = Attribute Resolver services to provide standards-based mechanisms for inter= facing applications with institutional SSO. Vended applications and cloud p= roviders 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.
The Relying Party Data component keeps tr= ack of the relationship between authentication services and service provide= rs. This component tracks metadata about each service provider including th= e security components to validate the service provider and the attribute re= lease policies that determine which attributes should be provided to each s= ervice provider. Relying Party Data represents an agreement between the ins= titution and a service provider (or federation of service providers) about = the strength at which users should be authenticated and the data about user= s that should be released from the institution to the service provider.
The Consent Service component engages the= user in the attribute release process by providing a mechanism to prompt t= he user for a decision about whether or not it is appropriate to release a = particular data element to a requesting application. Where the Relying Part= y Data above represents an agreement between the institution and a service = provider, the Consent Service engages the user in the transaction.
For example, a user authenticating to a c= loud service requiring release of 'email address' from the institution can = be prompted whether or not they choose to release their email address to th= e application, or can be made aware that this data is being released. The C= onsent Service can provide an audit trail to meet record keeping requiremen= ts around management of 'opt-in' and 'opt-out' data release policies.
As privacy regulations mature and applica= tion integration becomes increasingly distributed, user consent is expected= to become an increasingly important component of the identity management e= cosystem.
The Attribute Resolver component translat= es between the internal data structures in the TAP architecture and the att= ributes that are delivered to service providers. The attribute resolver map= s specific internal data constructs to normalized attributes so that servic= e providers do not need to be aware of the inner workings of the TAP archit= ecture to consume attribute information about users that are accessing thei= r services.