Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

IDRequirementDescriptionConfigurable
MC1Consume entity XML metadataThe product MUST allow importing an entity XMLYes
MC2Consume entity metadata through URLThe product MUST allow importing URL based metadataYes
MC3Consume entities metadata through MDQThe IdP MUST be able to consume metadata via MDQYes

Logging [LO]

IDRequirementDescriptionConfigurable
LO1Transaction loggingThe product MUST support logging authN transaction in a separate logNo
LO2Error loggingThe product MUST support logging errors in a separate logYes
LO3Log persistenceLogs MUST be deleted automatically after a given time. Time must be configured on a per log basis. No
LO4Log retrievalLogs MUST be downloadable by an appropriate adminNo
LO5Platform admin does not have access to user data

Statistics [ST]

IDRequirementDescriptionConfigurable
ST1Per SP transactionsThe IdP MUST provide transactions per SP over a given period of time (day/month/week/year) No
ST2Transaction AggregatesThe IdP must provide aggregated transactions over a given period (day/month/week/year)No
ST3Fticks readyProduct SHOULD preconfigure IdP with Fticks supportYes

Branding and contact data [BC]

IDRequirementDescriptionConfigurable
BC1IdP displaynameIdP MUST have a multi language displaynameYes
BC2LogoIdP MUST have a logoYes
BC3Admin contactIdP MUST have an administrative contactYes
BC4Tech contactIdP MUST have an technical contactYes
BC5Support contactIdP MUST have an end user support contactYes
BC6Security contactIdP MAY have a security support contactYes

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

  1. Create/manage IdP
  2. 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.
    1. Create/manage users
      The platform offers an integrated user management to create and manage identities locally using the web interface.
    2. 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.
  3. Store users
    User identities are stored in the internal database, regardless whether they were added via the web interface or API.
  4. Store IdP config
    The configuration of an IdP created with the web application is stored within the platform.
  5. Access IdP config
    The IdP software uses the stored configuration to spawn an IdP service.
  6. Access IdP metadata
    The user receives the metadata for the IdP as an XML file.
  7. Register IdP metadata
    The metadata is provided manually to the targeted identity federation.
  8. 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.