Further requirements SAML 2.0

The integration of a SAML 2.0-capable application into the eIAM service requires a sound knowledge of the SAML 2.0 protocol and the application to be integrated. The application must be adapted to the eIAM service. eIAM will be configured according to the dossier. Custom adaptions of eIAM for the single use of an application are out of scope.

Supported SAML Profiles, Bindings, Subject Confirmation Type

Anything not explicitly defined as supported below is NOT supported by Service eIAM.

SAML 2.0 profiles supported by eIAM-Web PEP
The table below shows the SAML 2.0 profiles to be used by actors in the service eIAM.


Actor Web Browser SSO Profile Single Logout Profile
Application using RP-PEP MUST MUST
Application using regular integration (STS-PEP) MUST MAY

 From an application perspective, eIAM supports the following SAML 2.0 bindings:

  • HTTP POST Binding for SAML AuthnRequests and SAML Responses
    • urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST

Subject Confirmation Type supported by eIAM PEP
From an application perspective, eIAM supports the following Subject Confirmation Types:
  • Bearer
    • urn:oasis:names:tc:SAML:2.0:cm:bearer

Signatures and Encryptions

The following table provides an overview of the requirements for digital signatures and encryption at the message level. Irrespective of this, messages may generally only be transmitted with encryption on the transport layer (HTTPS).

Communication SAML Profile Digital Signature                                   Message Level Encryption                        
Application → eIAM SAML Endpoint Web-SSO Profile (Login)AuthnRequest: MUST NOT (1) AuthnRequest: NOT ALLOWED
eIAM SAML Endpoint → Application Web-SSO Profile (Login)Response: MUST
Assertion: MUST NOT (2) 		Response: NOT ALLOWED
Assertion: NOT ALLOWED
Single Logout
Profile		LogoutRequest: MUST
LogoutResponse: MUST NOT 		LogoutRequest: NOT ALLOWED
LogoutResponse: NOT ALLOWED
Single Logout
Profile		LogoutRequest: MUST
LogoutResponse: MUST NOT (3) 		LogoutRequest: NOT ALLOWED
LogoutResponse: NOT ALLOWED
(1) Signing the AuthnRequest is optional, but recommended. This prevents CSRF (cross site request forgery). This is because the signature ensures that eIAM only accepts AuthnRequests that were really issued by the application.
(2) This is not mandatory, but eIAM will sign assertions as well.
(3) eIAM signs LogoutResponses in any case.

x509 Keymaterial for the signature of SAML messages

To sign SAML messages the project needs to provide a certificate.
The following requirements apply:
  • Each environment (REF, ABN, PROD) MUST have a dedicated certificate
  • Keylength: MUST be at least 2048 bits
  • Validity period of the certificate MUST be between 1 and 3 years
  • Certificates issued MUST have a "Key Usage" for signing
  • For applications within Federal Administration certificates MUST be issued by Swiss Government PKI (SG-PKI) and be of type "Class-C" or "Class-E"
  • For all other applications certificates SHOULD use SG-PKI certificates, but others are also allowed
It is recommended that the project order those at an early stage of the project.

Required key material and its usage
Required key material and its usage

KeyInfo requirements

According to the SAML 2.0 specification, there are various possibilities for identifying the public key to be used for verifying the signature of the SAML structures.

eIAM uses the KeyInfo element, which MUST be present in every signed SAML message. KeyInfo MUST contain the X.509 certificate of the key pair used to sign the SAML message.

Exchange of x509 Key Material

The exchange of the public keys (certificates) takes place for the first time during the integration of the application. Usually, application and eIAM provide their metadata file to the counterpart system. For details, please see

SAML 2.0 configuration (metadata)
.
Mutual exchange of signer certificates for signature verification
Mutual exchange of signer certificates for signature verification


  • eIAM provides the public key (certificate) of the eIAM-Web PEP Signer in its role as Identity Provider to the application so that it can verify the signature of the SAML messages it issues.
  • The application provides the public key (certificate) of the application signer in its role as service provider to the eIAM-Web PEP so that it can verify the signature of the SAML messages it issues.

Renewal of Key Material

The Key Material SHOULD be renewed by both the application and the PEP according to the validity period of the certificates. eIAM is designed to work in parallel with multiple public keys (the old and the new) to verify the signature of the application. Likewise, the application MUST be technically capable of holding multiple certificates for signature verification of eIAM. This allows the renewal of certificates for signature verification without a failure of the applications and without the certificates and private keys of the remote parties having to be renewed at exactly the same time.

The operator of the application and the operator of eIAM MUST inform each other in good time about the renewal of the key material. The operational processes for informing the remote peer and exchanging the keys MAY be regulated by the project (client) before the application goes live.