You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

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.

IDRequirementDescription
IC1Accept user inputThe platform MUST accept user input for IdP configuration for all values defined as configurable in section IdP requirements
IC2Unique entity IDA new entity ID MUST NOT already exist in eduGAIN, nor in any national federation
IC3Non-reusable entity IDA 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.

IDRequirementDescription
ID1Complete deletion

It MUST be possible to delete an IdP and non-technical data upon request. This includes at least:

  • Any related user data
  • Personal log data
ID2Delayed deletionOnce deletion is triggered the IdP MUST be deactivated, but MUST NOT be deleted for a retention period of three months.
ID3Delete notificationThe administrator and technical contacts of an IdP MUST be notified immediately once deletion is requested.
ID4IdP recoveryThe 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.

IDRequirementDescription
IM1Edit configurationAdministrators MUST be able to change the IdP configuration for all values defined as configurable in section IdP requirements

SP Management [SM]

IDRequirementDescription
SP1Add and configure SPsIt MUST be possible to configure entities to be read from metadata
SP2Attribute release policy

There MUST be an option to configure attributes released for

  • all service providers
  • an specific service provider

User Management [UM]

IDRequirementDescription
UM1Local user managementThe solution MUST include a local user management to create, update and delete identities.
UM2Remote user managementThe solution MUST be capable to use identities from an existing user database at a remote location.

Authentication & Authorization [AA]

IDRequirementDescription
AA12FA authenticationThe access to the management interface MUST require at least a second factor.
AA2Account recoveryThe software SHOULD NOT offer a self service to recover administrative accounts.

Software Deployment [SD]

IDRequirementDescription
SD1Operational documentationThe deployment MUST be sufficiently documented so that it can be performed easily and independently.
SD2Automatic deploymentDeploying 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.

IDRequirementDescriptionConfigurable
AU1Handle SAML authenticationThe IdP MUST be able to handle SAML2 authenticationNo
AU2Common standardsIdP MUST adhere to saml2int, and relevant eduGAIN profilesNo
AU3No SAML1IdP MUST NOT be able to handle SAML1 authenticationNo
AU4Identifier support

The IdP MUST support the following identifier types:

  • persistent nameid
  • transient nameid
  • ePPN
  • ePTID
  • subject ID
No
AU5eduPerson support

The IdP MUST support the following eduPerson attributes:

  • DisplayName
  • Email
  • CN
  • SN
  • Name
  • edupersonScopedAffiliation
  • edupersonEntitlement
No
AU6SCHAC support

The IdP MUST support the following SCHAC attributes:

  • schacHomeOrganisation
No
AU7eduMember support

The IdP MUST support the following eduMember attributes:

  • IsMemberOf
No
AU8Force AuthnThe IdP MUST support SAML Force authenticationNo
AU9SSO session timeThe IdP MUST support SSO, session time must be configurableYes
AU10Authentication ContextThe IdP MUST support providing LoA information through Authentication Class Context refNo

Credential Handling [CH]

IDRequirementDescriptionConfigurable
CH1Local Credential SourceThe IdP MUST allow for credentials to be provided locallyYes
CH2LDAPs credential storeThe 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
CH3PasswordsThe IdP MUST support use of passwords for authenticationNo
CH4EncryptionAll 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 tokenidNo

Attribute release [AR]

IDRequirementDescriptionConfigurable
AR1R&E Entity categoriesThe IdP MUST be able to use commonly used categories like R&S and SIRTFI  to be used as filter for attribute release policyYes
AR2SP metadata attributesThe product MUST support release of attributes based on SP metadata requirementsYes

AR3

Per SP attributesThe product MUST support release of attributes based on per SP basis (configured manually)Yes
AR4Attribute value filteringThe product MAY support filtering of attribute values (e.g. for affiliation) on a per SP basisNo

User management [UM]

IDRequirementDescriptionConfigurable
UM1Local GUIA local per customer GUI MUST be provided to manage users in the local user store if so configuredYes
UM2Local GUI AuthNAuthentication for the a local GUI MUST NOT use any of the IdPs on the platformNo
UM3Local Password resetA password reset function MUST be provided for users based on the email stored in the local storeYes

Metadata publishing [MP]

IDRequirementDescriptionConfigurable
MP1Publish SAML metadataThe product MUST publish SAML metadata for the entityNo
MP2R&E Entity categories

The product MUST allow publishing of specific entity categories:

  • R&S
  • SIRTFI
Yes

Metadata consumption [MC]

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

  • Web Application
  • User Management
  • User DB
  • Remote API
  • IdP Config
  • Identity Provider

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

https://github.com/sitya/samlidp


  • No labels