Source file for this diagram: Architecture and Components
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 |
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.
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.
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:
All configuration is pushed towards Filter from the Amin component.
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.
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.
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