SAML 2.0 Setup: Metadata vs No-Metadata

This article covers the benefits of using SAML 2.0 Metadata when establishing trust between two SAML 2.0 Federation servers, as opposed to providing and entering information manually by typing/copying/pasting URLs, certificates.

Establishing Trust

Trust establishment in the context of SAML 2.0 WebSSO is the act of configuring a SAML 2.0 Identity Provider and a SAML 2.0 Service Provider so that they can perform Federation SSO operations.

Establishing trust involves the following steps:

Creating a partner entry at the SAML 2.0 Identity Provider that represents the remote Service Provider with the following information
The SP’s EntityID or ProviderID which is the unique identifier referencing the SP
The Assertion Consumer Service URL(s) where the IdP redirects the user with the SAML Assertion
Each one might have a different URL and a different binding (for example urn:oasis:names:tc:SAML:2.0:bindings:HTTPArtifact, urn:oasis:names:tc:SAML:2.0:bindings:HTTPPOST or urn:oasis:names:tc:SAML:2.0:bindings:PAOS)
The Logout Service URLs where the IdP redirects the user during the SAML 2.0 Logout exchange
Each one might have a different binding (for example urn:oasis:names:tc:SAML:2.0:bindings:HTTPRedirect, urn:oasis:names:tc:SAML:2.0:bindings:HTTP- POST)
Each Service might have different URLs to receive a LogoutRequest message and a LogoutResponse message
The X.509 certificates corresponding to the private key used by the SP to sign outgoing SAML 2.0 messages, such as the AuthnRequest,
LogoutRequest/LogoutResponse, or ArtifactResolve messages
The X.509 certificates corresponding to the private key used by the SP to decrypt incoming SAML 2.0 messages encrypted by remote IdPs with the certificate(s), such as the Assertion/NameID/Attribute elements inside an SSO Response
Creating a partner entry at the SAML 2.0 Service Provider that represent the remote Identity Provider with the following information
The IdP’s EntityID or ProviderID which is the unique identifier referencing the IdP
The Single Sign On Service URLs where the SP redirects the user with the SAML AuthnRequest
Each one might have a different URL and a different binding (for example urn:oasis:names:tc:SAML:2.0:bindings:HTTPRedirect, urn:oasis:names:tc:SAML:2.0:bindings:HTTPPOST or urn:oasis:names:tc:SAML:2.0:bindings:SOAP)
The Logout Service URLs where the SP redirects the user during the SAML 2.0 Logout exchange
Each one might have a different binding (for example urn:oasis:names:tc:SAML:2.0:bindings:HTTPRedirect, urn:oasis:names:tc:SAML:2.0:bindings:HTTP- POST)
Each Service might have different URLs to receive a LogoutRequest message and a LogoutResponse message
The X.509 certificates corresponding to the private key used by the IdP to sign outgoing SAML 2.0 messages, such as the Assertion, LogoutRequest/LogoutResponse or ArtifactResponse messages
The X.509 certificates corresponding to the private key used by the IdP to decrypt incoming SAML 2.0 messages encrypted by remote SPs with the (s), such as the NameID element inside a Logout Request

The above only covers the Federation SSO setup. If the Federation partners support other services, such as Attribute Authority and Attribute Requester, then more Service URLs and certificate information need to be exchanged.

Manual Process

As you can see, there can be a lot of information exchanged between the administrators responsible for managing the Federation servers, and any minor error might result in the Federation agreement not being set up properly and cause runtime errors.

The errors that could occur due to a manual trust establishment could be:

Wrong certificate used
Incorrect Service URL/binding combination, where for example an Assertion Consumer Service URL used only for Artifact binding is used for the HTTP-POST binding
Typo in the URLs
Incorrectly specifying the hostname in the Service URLs: Since cookies are used during Federation SSO operations. It is primordial to use the same fully qualified hostname, which is the public endpoint that users use to access the Federation servers. (IP Addresses or non fully qualified hostnames results in errors)
Typo in the ProviderIDs
URLs missing

Those errors result in:

Signature verification or decryption failures when using incorrect certificates Server throwing an error because
- Certificate is not valid
- URLs are missing for the functionality that is exercised (for example Logout URL is missing)
- Inconsistent hostnames were used (fully qualified vs IP Address vs non fully qualified) ProviderID is unknown, caused by a typo
- Infinite loops, due to the use of inconsistent hostnames

The errors listed above occur more than people assume, and this leads to time spent chasing down why Federation SSO is not working correctly that almost point to a Federation Trust establishment mistake.

Using SAML 2.0 Metadata

The SAML 2.0 specifications define the Metadata document which contains all the information a server has to know about its counterpart to perform Federation operations with the remote partner.

This information includes:

Service URLs
SAML bindings for the services
Certificates for signature and encryption operations
Which messages will be signed (AuthnRequest, Assertion)
Roles supported by the Federation Server (IdP, SP, Attribute Authority…)

The SAML 2.0 Metadata is typically generated by the federation server itself and is consumed by the partner’s Federation server: so no manual intervention takes place to create and consume this document and thus reducing the number of potential errors.

Using SAML 2.0 Metadata offers the following advantages:

All the information is contained in a single document
The document is generated and consumed by the Federation servers (signatures might be used to protect against tampering with)
No information is omitted
The data is consistent (same hostnames used in all URLs)

More importantly, it saves time by reducing the possibility of mistakes during the federation trust establishment, so that there will be fewer chances of runtime errors later on.

More Learning Resources

Explore other labs on docs.oracle.com/learn or access more free learning content on the Oracle Learning YouTube channel. Additionally, visit education.oracle.com/learning-explorer to become an Oracle Learning Explorer.

For product documentation, visit Oracle Help Center.

Title and Copyright Information

SAML 2.0 Setup Metadata vs No Metadata

F61884-01

September 2022