This page defines a reference design for a platform that can be used to provide an IdP as a Service offering that covers the needs of Research & Education (R&E) institutions.
Content:
Specification
This section defines the minimum requirements to be implemented by an IdP as a Service (IdPaaS) offering.
Platform requirements
The following requirement apply to the software used to create and manage an IdP.
This document uses the keywords MUST, MUST NOT, SHOULD, SHOULD NOT and MAY according to RFC 2119.
IdP Creation [IC]
The platform must provide a function to create a new IdP, which results in an deployed IdP configured based on user input.
| ID | Requirement | Description |
|---|---|---|
| IC1 | Accept user input | The platform MUST accept user input for IdP configuration for all values defined as configurable in section IdP requirements |
| IC2 | Unique entity ID | A new entity ID MUST NOT already exist in eduGAIN, nor in any national federation |
| IC3 | Non-reusable entity ID | A new entity ID MUST NOT be equal to one issued previously by this platform |
IdP Deletion [ID]
The platform must provide a function to delete an existing IdP to delete a formerly created IdP entirely.
| ID | Requirement | Description |
|---|---|---|
| ID1 | Complete deletion | It MUST be possible to delete an IdP and non-technical data upon request. This includes at least:
|
| ID2 | Delayed deletion | Once deletion is triggered the IdP MUST be deactivated, but MUST NOT be deleted for a retention period of three months. |
| ID3 | Delete notification | The administrator and technical contacts of an IdP MUST be notified immediately once deletion is requested. |
| ID4 | IdP recovery | The administrator MUST be able to recover and reactivate an IdP within the retention period. |
IdP Management [IM]
The platform must provide a function to alter the configuration of an existing IdP without loss of user data.
| ID | Requirement | Description |
|---|---|---|
| IM1 | Edit configuration | Administrators MUST be able to change the IdP configuration for all values defined as configurable in section IdP requirements |
SP Management [SM]
| ID | Requirement | Description |
|---|---|---|
| SP1 | Add and configure SPs | It MUST be possible to configure entities to be read from metadata |
| SP2 | Attribute release policy | There MUST be an option to configure attributes released for
|
User Management [UM]
| ID | Requirement | Description |
|---|---|---|
| UM1 | Local user management | The solution MUST include a local user management to create, update and delete identities. |
| UM2 | Remote user management | The solution MUST be capable to use identities from an existing user database at a remote location. |
Authentication & Authorization [AA]
| ID | Requirement | Description |
|---|---|---|
| AA1 | 2FA authentication | The access to the management interface MUST require at least a second factor. |
| AA2 | Account recovery | The software SHOULD NOT offer a self service to recover administrative accounts. |
Software Deployment [SD]
| ID | Requirement | Description |
|---|---|---|
| SD1 | Operational documentation | The deployment MUST be sufficiently documented so that it can be performed easily and independently. |
| SD2 | Automatic deployment | Deploying the software itself SHOULD be automated. |
IdP requirements
The following requirements apply to the hosted IdP itself.
Authentication [AU]
This category defines requirements for the authentication performed by the IdP.
| ID | Requirement | Description | Configurable |
|---|---|---|---|
| AU1 | Handle SAML authentication | The IdP MUST be able to handle SAML2 authentication | No |
| AU2 | Common standards | IdP MUST adhere to saml2int, and relevant eduGAIN profiles | No |
| AU3 | No SAML1 | IdP MUST NOT be able to handle SAML1 authentication | No |
| AU4 | Identifier support | The IdP MUST support the following identifier types:
| No |
| AU5 | eduPerson support | The IdP MUST support the following eduPerson attributes:
| No |
| AU6 | SCHAC support | The IdP MUST support the following SCHAC attributes:
| No |
| AU7 | eduMember support | The IdP MUST support the following eduMember attributes:
| No |
| AU8 | Force Authn | The IdP MUST support SAML Force authentication | No |
| AU9 | SSO session time | The IdP MUST support SSO, session time must be configurable | Yes |
| AU10 | Authentication Context | The IdP MUST support providing LoA information through Authentication Class Context ref | No |
Credential Handling [CH]
| ID | Requirement | Description | Configurable |
|---|---|---|---|
| CH1 | Local Credential Source | The IdP MUST allow for credentials to be provided locally | Yes |
| CH2 | Passwords | The IdP MUST support use of passwords for authentication | No |
| CH3 | Encryption | All locally stored and or cached personal data of end users MUST be stored encrypted where the encryption key is the SHA256 over the password or tokenid | No |
Attribute release [AR]
| ID | Requirement | Description | Configurable |
|---|---|---|---|
| AR1 | R&E Entity categories | The IdP MUST be able to use commonly used categories like R&S and SIRTFI to be used as filter for attribute release policy | Yes |
| AR2 | SP metadata attributes | The product MUST support release of attributes based on SP metadata requirements | Yes |
AR3 | Per SP attributes | The product MUST support release of attributes based on per SP basis (configured manually) | Yes |
| AR4 | Attribute value filtering | The product MAY support filtering of attribute values (e.g. for affiliation) on a per SP basis | No |
User management [UM]
| ID | Requirement | Description | Configurable |
|---|---|---|---|
| UM1 | Local GUI | A local per customer GUI MUST be provided to manage users in the local user store if so configured | Yes |
| UM2 | Local GUI AuthN | Authentication for the a local GUI MUST NOT use any of the IdPs on the platform | No |
| UM3 | Local Password reset | A password reset function MUST be provided for users based on the email stored in the local store | Yes |
Metadata publishing [MP]
| ID | Requirement | Description | Configurable |
|---|---|---|---|
| MP1 | Publish SAML metadata | The product MUST publish SAML metadata for the entity | No |
| MP2 | R&E Entity categories | The product MUST allow publishing of specific entity categories:
| Yes |
Metadata consumption [MC]
| ID | Requirement | Description | Configurable |
|---|---|---|---|
| MC1 | Consume entity XML metadata | The product MUST allow importing an entity XML | Yes |
| MC2 | Consume entity metadata through URL | The product MUST allow importing URL based metadata | Yes |
| MC3 | Consume entities metadata through MDQ | The IdP MUST be able to consume metadata via MDQ | Yes |
Logging [LO]
| ID | Requirement | Description | Configurable |
|---|---|---|---|
| LO1 | Transaction logging | The product MUST support logging authN transaction in a separate log | No |
| LO2 | Error logging | The product MUST support logging errors in a separate log | Yes |
| LO3 | Log persistence | Logs MUST be deleted automatically after a given time. Time must be configured on a per log basis. | No |
| LO4 | Log retrieval | Logs MUST be downloadable by an appropriate admin | No |
| LO5 | Platform admin does not have access to user data |
Statistics [ST]
| ID | Requirement | Description | Configurable |
|---|---|---|---|
| ST1 | Per SP transactions | The IdP MUST provide transactions per SP over a given period of time (day/month/week/year) | No |
| ST2 | Transaction Aggregates | The IdP must provide aggregated transactions over a given period (day/month/week/year) | No |
| ST3 | Fticks ready | Product SHOULD preconfigure IdP with Fticks support | Yes |
Branding and contact data [BC]
| ID | Requirement | Description | Configurable |
|---|---|---|---|
| BC1 | IdP displayname | IdP MUST have a multi language displayname | Yes |
| BC2 | Logo | IdP MUST have a logo | Yes |
| BC3 | Admin contact | IdP MUST have an administrative contact | Yes |
| BC4 | Tech contact | IdP MUST have an technical contact | Yes |
| BC5 | Support contact | IdP MUST have an end user support contact | Yes |
| BC6 | Security contact | IdP MAY have a security support contact | Yes |
Architecture
This section describes one possible architecture of an IdPaaS platform to support the R&E specification.
Components
The IdPaaS platform consists of the components listed below. The service design is chosen so that the platform can be implemented by integrating individual components, each of which acts independently. Thus the platform does not have to be provided as monolithic software, but can be assembled in the sense of a micro service approach. Individual components can be easily replaced by existing software from (commercial) third parties.
- Web Application
A simple website that provides login capabilities and easy to use forms to create and manage IdPs and users.
To ensure platform independence, the GUI should be implemented as a web application. All functions of the IdPaaS platform should be accessible and configurable via the GUI. - User Management
A local component for managing identities within the platform.
To enable an out-of-the-box usage without dependencies an independent user administration is necessary. It needs to be integrated into the platform so that it can be easily used via the web application. There should be at least basic functionalities to create, edit and delete users. - User DB
A simple database for storing identity information.
The user database contains all identities managed by the platform. These are created either via the integrated user management or the remote API. The user database provides the identity data for the IdPs. An implementation can be done with a single database or multiple ones. - Remote API
An interface to integrate external identities into the IdPaaS user management.
In order to enable institutes to use an existing user management system, the platform must offer a suitable interface. This API should be able to access an external user database (hosted by the institution or a commercial provider) and import users directly into the local user database. - IdP Config
A component to store IdP configurations.
Settings made by the user in the web application must be processed by the IdPaaS platform and provided as a configuration for the IdP. If only a real IdP is created (see IdP), the different configuration files should be stored in a database. - Identity Provider
An IdP managed and provided by the IdPaaS platform.
The platform must provide users with an IdP based on the configuration provided. Either a separate IdP is created for each customer or a single IdP delivers virtual profiles for all customers.
Flow
- Create/manage IdP
Campus create a new IdP or manage an existing one using a simple web interface provided by the IdPaaS web application. - User Management
There are two ways provided to manage user identities, either using the platform internal user management or using an existing user database. Both options must be supported by the platform, but use may be limited to one option at a time.- Create/manage users
The platform offers an integrated user management to create and manage identities locally using the web interface. - Import/sync users
An alternative to the integrated user management is using an already existing user database. The platform offers an API that allows the import or synchronization of user identities from a remote user database into the internal database.
- Create/manage users
- Store users
User identities are stored in the internal database, regardless whether they were added via the web interface or API. - Store IdP config
The configuration of an IdP created with the web application is stored within the platform. - Access IdP config
The IdP software uses the stored configuration to spawn an IdP service. - Access IdP metadata
The user receives the metadata for the IdP as an XML file. - Register IdP metadata
The metadata is provided manually to the targeted identity federation. - Access metadata
The IdP receives the metadata of the configured federation.
Implementation
Based on the above requirements and the described architecture, an exemplary implementation of an IdPaaS software for the R&E area was created.
IdPaaS Reference Implementation: https://github.com/sitya/samlidp
This reference implementation is freely accessible as an open source project and is maintained by the community on a best effort basis. This software is not provided or maintained by GÉANT. Any use for the provision of an IdPaaS offer takes place without any official support. A fork of the software to develop new (commercial) services is permitted.