This section describes the certificates and settings that you must obtain from your Identity Provider (IdP) as well as the settings and requirements your IdP requires from xMatters. Once you have obtained this information from your IdP, ask your xMatters representative to configure SAML for you (see Configure SAML in xMatters). Some of the information from the IdP can be located by inspecting the SAML assertion files. Other information can be obtained by contacting your IdP.
You also need to determine how your IdP identifies users (for example, by email address) and ensure that xMatters uses the same method to identify users in either the User ID or Web Login ID field. You may need to adjust the values stored in the Web Login IDs to match how the IdP identifies users.
Your identity provider requires information about how xMatters configures Single Sign-On, including which kind of SAML implementation xMatters supports, how to encrypt and sign communications, and where to send assertions.
xMatters supports IdP-initiated SSO with POST Binding.
All communication between the IdP and xMatters must be made over an encrypted channel (HTTPS) using HTTP POST. xMatters expects message content from the IdP to be unencrypted as these messages are sent securely over HTTPS.
Responses from the IdP must be Base-64 encoded, and response and assertions must be signed. Individual elements within a SAML message must not be independently signed. xMatters expects the SAML response or assertion to have a nested signature section in the IdP's signature and certification information. xMatters compares this information to the certificate stored at xMatters to validate the authenticity of the message.
You can access xMatters metadata by appending /saml/metadata to your company URL.
If a company has the following URL:
The SAML metadata can be located at this URL:
You must provide your IdP with the xMatters URL that consumes assertions sent from the IdP. You can obtain this URL by appending /sp/SSO.saml2 to the end of your xMatters URL.
If a company has the following URL:
The assertion consumer URL can be located at this URL:
You can see the assertion claim URL in the SubjectConfirmationData element in SAML responses.
<saml:SubjectConfirmationData NotOnOrAfter="2014-06-16T17:30:29Z" Recipient="https://mycompany.na1.xmatters.com/sp/SSO.saml2"/>
Before you can configure SAML for xMatters, you must obtain information about how your identity provider configures SSO and obtain certificates for your production and non-production instances. The following sections describe the information that is required from your identity provider.
This identifier is a unique representation of identity provider.
To locate this value in the SAML assertion file find the <Issuer>, <saml:Issuer>, or <saml2:Issuer> element.
The following examples shows the identity provider ID within the <saml:Issuer> tag.
The Audience is a unique identifier that the identity provider uses to identify xMatters. This value is often a URL but may be any unique identifier such as a name or numeric ID.
You can locate the Audience value in the SAML response in the <Audience>, <saml:Audience>, or <saml2:Audience> element.
This is the URL of the identity provider's Single Sign On (SSO) login page. Users must first log in here before they can access xMatters using SSO. xMatters redirects users to this page when they log out or when they attempt to access an xMatters page without having an active session.
If this value is configured, clicking the log out button in xMatters redirects the user to this URL, bypassing the xMatters log out page. This value is optional.
Ask your identity provider to provide a public key certificate for each of your production and non-production instances.
xMatters uses this certificate to verify that SAML responses have been transmitted securely and originate from the identity provider. Once you obtain this certificate file, contact xMatters to install it on your system. SAML settings do not take effect until the certificate is installed.
xMatters supports X.509 certificates encodings:
xMatters identifies who is being authenticated by matching the user names from the IdP to xMatters users. xMatters can map the user name from the IdP to either the Web Login ID or User ID. You'll need to find out how your IdP identifies users and see whether it matches the Web Login ID or the User ID.
If the user names of the IdP do not match either the Web Login ID or User ID, you'll need to adjust how you identify users in xMatters. The easiest way to do this is to set the Web Login ID field to match the user name provided by the IdP. The Web Login ID is not usually used when Single Sing-On is configured, because users do not log in through the xMatters web user interface (except those users who have permission to log in natively).
For more information about viewing User IDs and Web Login IDs, seeUser Profile.
If the IdP identifies users by email address (for example, email@example.com) and xMatters identifies users by employee ID (for example, 329992) in both the User ID and Web Login ID fields, set the Web Login ID to contain the user's email address. You can then map identity provider user names to the Web Login ID field.
Some SAML implementations define the user name in the <NameID> element and others define the user in an attribute. You'll need to know whether your IdP specifies the user name in the <NameID> element or in an attribute, and if it defines the name in an attribute you also need to know the name of the attribute.
When the user is defined in the <NameID> element, it is located with in the <Subject> element in SAML assertions. (These elements may be named <saml:NameID> and <saml:Subject>, or <saml2:NameID> and <saml2:Subject>.)
When the name is stored as an attribute, it is stored in the <Attribute> element of assertions. (This element may be named <saml:Attribute> or <saml2:Attribute>.)
In this example the name is stored in an attribute named "uid".
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs-string"> firstname.lastname@example.org