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

Compare with Current View Page History

« Previous Version 3 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.

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

Upon request an IdP and non-technical data is deleted including:

  • 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









Authentication & Authorization [AA]

IDRequirementDescription









User Management [UM]

IDRequirementDescription









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

Support is needed for at least 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
LDAP access is READ ONLY, so no editing of remote LDAP data		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 transactionsMust show per SP transactions over a given period of time (day/month/week/year) No
ST2Transaction AggregatesMust show 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