The TIER Reference Architecture assists executive stakeholders, campus IT architects and TIER community members in understanding the functional components for identity and access management in a higher education institution, and how those components relate to one another.
TIER’s Business Context
The TIER Architecture simplifies campus processes and advances inter-institutional collaboration and research through an open-source toolset and a set of campus architectural practices that answer the challenges posed by identity and access control at higher education institutions. The TIER Architecture provides tools, software and architectural patterns that enable institutions to effectively and securely manage access to institutional resources and to foster inter-institutional collaboration.
The TIER Reference Architecture
Internet2’s Trust and Identity in Education and Research (TIER) program aims to simplify campus processes and advance inter-institutional collaboration and research.
The diagram shows a “reference architecture” -- a way to consider the functional components for identity and access management in a higher educational institution. These consist of:
- Person (or "Entity") Registry -- records of student, staff, faculty, guests, etc
- Authentication and Federation-related services -- components that enable verified, privacy-preserving user access to services both locally and at remote partners
- Groups Service -- named collections of users for use in mailing lists and authorization rules
- Provisioning -- a single point of management for user accounts at multiple local services and systems (e.g. legacy OSs, databases, etc)
- Messaging Queuing Service -- “publish and subscribe” and reliable delivery functionality
TIER helps institutions fulfill their functional identity and access management needs by delivering flexibly packaged and deployable components, along with a set of APIs to provide consistency and to ease integration.
Here’s a list of the current and planned TIER components, related to the reference architecture:
- Person Registry -- COmanage, midPoint
- Authentication & Federation Services
- WebSSO/SAML Identity Provider -- Shibboleth Identity Provider
- Relying Party Information -- InCommon Metadata
- Consent Service -- Scalable Consent
- Groups Service -- Grouper
- Provisioning Service -- COmanage, midPoint
- Messaging & Queuing Service -- RabbitMQ
For more information about TIER, please see TIER Vision.
For more information about each TIER component, click on the component name above.
- New person from institutional source
- New person from institutional source, midPoint variant
- New person from Guest / Self Registration
- New person from Invitation Service
- Demographic / contact data update
- Existing person with new affiliation
- Existing person with changed affiliation (e.g. job change)
- Existing person losing affiliation (e.g. job ending)
- New user activating a credential
- Adding an additional external credential
- Request-based Provisioning
- Attestation and Compliance
Initial sketch for DSAWG - 6/15/16 (PDF)
Revised Version of Reference Architecture
From the Entity Registries Working Group:
IAM Functional Model: https://spaces.at.internet2.edu/display/TIERENTREG/IAM+Functional+Model+and+IAM+Glossary
Backbone Usage Scenarios: https://spaces.at.internet2.edu/x/HwjcBQ
From TIER Executive Documents:
Case for TIER / State of TIER (see Figure 1 - Composite Block Diagram in the State of TIER): https://drive.google.com/folderview?id=0BzRHp0xie6WFUVRqQXBwd3VSa1U&usp=sharing#list
TIER Educause Presentation (Nov, 2015): https://www.internet2.edu/media/medialibrary/2015/11/06/TIER-Educause-Nov2015.pdf
CIFER Reference Architecture:
CIFER Solutions Reference Architecture: https://spaces.at.internet2.edu/display/cifer/CIFER+Solutions+Reference+Architecture
Component and Capability Reference Architecture: https://spaces.at.internet2.edu/display/cifer/Component+and+Capability+Reference+Architecture
IAM Functions from I2 Middleware Initiative (2006): https://spaces.at.internet2.edu/download/attachments/91226442/mw-infosheet19.jpg?version=1&modificationDate=1463673400039&api=v2
As discussed on the 7/8 call, we probably want to think about having messaging coming on the inbound side as well.