SAML signing and encryption

POST binding certificates

The following sections describe how certificates are used in the RealMe context for both login and assertion service, assuming that POST binding is being used.

Service Provider (SP) authentication request
  • The SAML V2.0 AuthnRequest must be signed using the private key of the Service Provider's certificate.
    • The signing algorithm should be SHA-256 (SHA-1 is supported for historical integrations).
    • Unlike some other IdPs, RealMe does not require encryption of the AuthnRequest.

Note that the SAML V2.0 AuthnRequest sent via the browser needs to be Safe Base64 encoded.

 RealMe IdP response
  • The AuthnResponse returned by RealMe includes a SAML Assertion that contains the FLT or verified attribute content.
  • The SAML assertion content is encrypted by RealMe using the SP's certificate public key, and this needs to be unencrypted using the SP's private key.
    • The encryption algorithm used by RealMe is currently SHA-1, but this will be deprecated in May 2019 and replaced with SHA-256.
  • The SAML assertion content is signed by RealMe using its private key. The SP must validate the signature using the RealMe public key.
    • The signing algorithm used by RealMe is currently SHA-1, but this will be deprecated in May 2019 and replaced with SHA-256.
Certificate key exchange
  • The Service Provider's public key is passed to RealMe in the X509 section of the SP metadata during integration with ITE or Production environments.
  • The RealMe public key is passed to the organisation in the X509 section of the IdP metadata supplied during integration (see step 2).

RealMe RCMS and Artifact binding

An additional mutual SSL certificate is required when agencies are using the RESTful Context Mapping Service or the legacy Artifact binding protocol. The mutual SSL protocol must be one of TLS 1.0/1.1/1.2 - e.g. not SSL 3.0.

Subscribe