Introduction
The InAcademia service provides a translation service between a user affiliation as provided by a (SAML) Identity Provider (IdP) within a research or learning institution in the eduGAIN federation, and translates that to an answer to a so called Relying Party (RP) using the OpenID Connect protocol. The RP initiates the request by asking the InAcademia service for a specific scope which could ask for Affiliation (Affiliated, Student, Staff, Employee), and optionally a persistent identifier that is persistent, but unique for the requesting RP
Source file for this diagram: Architecture and Components |
Functional Components
InAcademia Core
The proxy component is the heart of the InAcademia service. It communicates with both RPs using the OpenID Connect protocol as well as well as with SAML2 IdPs.
(I) OpenID Provider
The OpenID Provider (OP) acts as a provider of an ID-token containing 'claims' about a user. The RP will connect to the OP requesting distinct scopes, e.g. 'affiliation'. The OP will only provide an ID-token as a response. In effect this means that the RP can get an answer in 1 transaction, and that the request yields a 'boolean' result. The response is either a token containing claims, or a HTTP 401 (not authenticated) response. Claims will include affiliation, but other optional claims may become available as well (e.g. Domain, Country, Institution, Faculty, etc)
In addition the OP provides an identifier as part of the Subject_id. The identifier will not contain any personally identifiable information and the relation between the identifier and the user can only be (re)constructed by the InAcademia service. The Subject_id can be either transient, so unique for every transaction, or pair-wise persistent, which means a specific RP will receive the same identifier for a specific user every time. In addition the OP will deliver various claims that are required by the OpenID Connect protocol.
The configuration for the OP is delivered by the Administrative component of the InAcademia service (See later). The configuration is dynamic and may change every 5 minutes.
(II) Filter component
The OP and SP interfaces of InAcademia Core act as protocol translators from and to OpenID Connect protocol and SAML2 protocol. The Filter component contains the business logic for the InAcademia service. Features include:
- OIDC Identifier handling
- OIDC Claims creation based on SAML2 attribute statements
- Handling of the SAML RelayState encryption
- Error handling
- Logging
- Providing various multi-language enduser GUIs, including:
- Consent
- Errors
All configuration is pushed towards Filter from the Amin component.
(III) SAML2 Service Provider
The Service Provider component provides a SAML2, saml2int compliant interface for interacting with SAML IdPs. The SP is rather straightforward, except for the creation of the SAML relaystate, for reasons which will be explained later-on. The SP will make use of a Discovery service provided as a separate component.
Attribute release requirements
As described in the OP section, 2 profiles will be provided, one with a transient Id and one with a persistent ID. The profiles will required different attributes to be released by connecting Identity Providers.
For the transientID profile, IdPs will need to release a (transient) NameID and the persons affiliation, using eduPersonAffiliation.
The persistentID profiles requires the IdP to release the affiliation using eduPersonAffiliation, and one of the following attributes (in sequence of preference): persistent NameID, eduPersonTargetedID (EPTID), eduPersonPrincipleName (EPPN). Regardless the attribute the IdP chooses to release, none of the information provided in this attribute will be revealed to the RP.
To separate between the the to distinct profiles, the InAcademia service will provide 2 seperate SP interfaces so IdPs can choose to match attribute release policies accordingly.
In case additional claims will be made available in future versions of the InAcademia service this may influence the attribute release requirements of the service.
(IV) Discovery Service
The discovery service allows endusers to choose a Home Institution Identity provider. This disco service will show 'all' known IdPs, both in and outside eduGAIN. If a user selects an eduGAIN IdP the discovery service will follow the common pattern of providing the SP with entity information to set up a SAML authentication request towards the IdP. If an IdP is selected which is not a member of eduGAIN the discovery service will return a specially crafted location to the SP signalling the SP component to show a page informing the user the IdP is not yet part of eduGAIN.
Configuration for the discovery service is created by the Metadata Handling component of the admin component, and pushed by Cosmos
InAcademia Admin
(V) Administrative Gui
(VI) Configuration Database
(VII) Relying Party Selfservice Registration
(VIII) SAML Metadata handling
(IX) Cosmos Configuration distribution
(X) GeoDNS load balancer
(XI) Relying Parties (external)
(XII) Identity providers (external, via eduGAIN)
Protocol flows
(1) OpenID Connect Protocol
(2) SAML2 Authentication protocol
(3) SAML2 Discovery protocol
Configuration flows
(4) Selfregistration by RP
(5) Filter Configuration Data
(6) Discovery Configuration Data
(7) Administrative data to be stored by the ConfigDB
(8) COnfig data to be published by Cosmos
(9) Metadata to be published by Cosmos
(10) Self-service Registration data to be stored by the ConfigDB
(11) Metadata information to be stored by the ConfigDB