...
| ID | Requirement | Description | Configurable | ||||
|---|---|---|---|---|---|---|---|
| CH1 | Local Credential Source | The IdP MUST allow for credentials to be provided locally | Yes | ||||
| CH2 | LDAPs credential store | The IdP MUST allow for credentials to be provided remotely through LDAPs. This LDAP access MUST be read only, so no editing of remote LDAP data is possible. | Yes | CH3 | Passwords | The IdP MUST support use of passwords for authentication | No |
| CH4CH3 | 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 |
...
| 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.