SAML 2.0

Configuration

This section outlines the requirements for configuring SAML 2.0 with ID.me.

Prerequisites

You must have the following to proceed with configuration:

  • An established relationship with ID.me
  • An understanding of the SAML protocol
  • Access to the appropriate development environment and resources on the partner’s side
  • An application that is able to support federated authentication via SAML 2.0 to consume the ID.me SAML service

Required information

ID.me will provide:

IdP metadata for both the Sandbox and Production environments:

Your organization will provide:

SP metadata – An XML document which contains information necessary for interaction with SAML-enabled identity or service providers. The document contains URLs of endpoints, information about supported bindings, identifiers and public keys.

Environments

ID.me offers two separate environments, Sandbox idmelabs.com and Production id.me. Sandbox does not contain any PII or user data. Production does not contain any test identities. Your ID.me team is available to further discuss the differences as well as approaches to working with both.

SAML metadata

Once an account is created, SAML metadata (along with keys) must be exchanged to ensure proper configuration of the endpoints.

Be sure to preserve formatting and whitespace when importing XML metadata—it prevents errors

The metadata document describes the IdP to a SP, including the following elements:

  • The endpoint addresses for communication
  • The X.509 certificates being used to sign and encrypt SAML assertions
  • The SAML bindings supported by the service provider

EntityID

The unique name that distinguishes it from any other entity. Specified in metadata.

SAML bindings

The ID.me IdP SAML service supports HTTP POST and HTTP Redirect bindings.

1urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST

Name identifier (NameIDFormat)

The ID.me IdP SAML service supports the following NameID formats:

1urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
2urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName
3urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName
4urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
5urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos
6urn:oasis:names:tc:SAML:2.0:nameid-format:entity
7urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
8urn:oasis:names:tc:SAML:2.0:nameid-format:transient
9urn:oasis:names:tc:SAML:2.0:nameid-format:encrypted
Best practice

ID.me recommends nameid-format:persistent based on UUID as the UUID within ID.me is a unique identifier which will not change and the other NameID values can vary.

Authentication context (AuthnContext)

The ID.me IdP SAML service supports invoking different authentication and verification policies on a per-application or per-request basis. The policy name is required to be passed along within the AuthnContext. The ID.me team will provide the specific value to be used.

Sandbox example

The following is an IdP initiated SSO example. ID.me strongly recommends an SP initiated SSO where the SP generates the AuthnRequest.

In the example below, <policy-handle> would be replaced with the appropriate policy name which is provided by ID.me.

1https://api.idmelabs.com/saml/SingleSignOnService?EntityID=<EntityID>&Binding=<binding>&AuthnContext=<policy-handle></policy-handle>

SAML is a secure protocol, which supports encryption and message signing. In addition, the HTTP communication security between the SP and the IdP is ensured by using SSL (TLS v1.1 or higher).

For more information about available policies and support for setting these up, please contact your ID.me team for additional information.

RelayState

A parameter used to identify the specific resource the user will access after they are signed in and directed to the relying party (RP).

XML signature

All ID.me SAML messages are digitally signed. This includes all requests, assertions and metadata. The XML signature is contained within the element. The signature serves as proof that only the IdP could have signed the element, and also to guarantee the integrity of the assertion. ID.me signs messages using SHA256, SHA384 and SHA512 algorithms.

XML Encryption

ID.me requires all SAML assertions to be encrypted. This helps protect any confidential data in the response. The encrypted assertion is contained within the element.

ID.me supports using AES-128, AES-192 and AES-256 as message encryption algorithms.

Resources

Web Access management software configurations

Broadcom Siteminder Federation Manager

Broadcom Siteminder’s Federation Manager can be configured to allow the ID.me network to operate as an Identity Provider (IdP). The following links below are to Broadcom documentation related to this process. These product pages may be updated from time to time by the vendor, please access the most current documentation directly through your vendor’s support portal.

For more information, see the Federation Manager Guide

Oracle Access Manager

Oracle 11g can be configured to allow the ID.me network to operate as an Identity Provider (IdP). The following links below are to Oracle documentation related to this process. These product pages may be updated from time to time by the vendor, please access the most current documentation directly through your vendor’s support portal.

For more information, see the Federation Manager SAML 2.0 Configuration Oracle Product Support Page

Tivoli Access Manager

IBM Tivoli can be configured to allow the ID.me network to operate as an Identity Provider (IdP). The following links below are to IBM documentation related to this process. These product pages may be updated from time to time by the vendor, please access the most current documentation directly through your vendor’s support portal.

For more information, see Configuring SAML 2.0 SP

Forgerock Open Access Manager

Forgerock OpenAM can be configured to allow the ID.me network to operate as an Identity Provider (IdP). The following links below are to Forgerock documentation related to this process. These product pages may be updated from time to time by the vendor, please access the most current documentation directly through your vendor’s support portal.

For more information, see Forgerock Open Access Manager

SimpleSAML

Simple SAML can be configured to allow the ID.me network to operate as an Identity Provider (IdP). The following links below are to Simple SAML documentation related to this process. These product pages may be updated from time to time by the vendor, please access the most current documentation directly through your vendor’s support portal.

For more information, see the Simple SAML documentation

GluuSAML

Gluu can be configured to allow the ID.me network to operate as an Identity Provider (IdP). The following links below are to Gluu documentation related to this process. These product pages may be updated from time to time by the vendor, please access the most current documentation directly through your vendor’s support portal.

For more information, see Set up SAML 2.0 Trust Relationships in GLUU

Test credentials

Manual creation

When going through the “Create Account” process, you can submit most information as long as it meets the attribute format (i.e. phone numbers are the correct length and contain numbers) and sample documents (i.e. driver’s license from the DMV). All test credentials created this way will return a standard data set.

Automated creation

Working with your ID.me team, you can either complete a test credential template spreadsheet or randomly generated attributes can be used. Once created, the ID.me team will deliver a spreadsheet with email addresses and passwords which can be used to test your sandbox environment.