The process for creating the relying party trust in your STS (Security Token Service) will differ between applications and services. However, as stated earlier, you can download a copy of SPP's federation metadata by clicking the link when you entered the STS information in SPP. You can also download the SPP federation metadata at any time using one of the following methods:

  1. Go to Appliance Management > Safeguard Access > Identity and Authentication.
  2. Click Download Safeguard Federation Metadata.
  3. Download the file from the following URL:
https://<SPP server>/RSTS/Saml2FedMetadata

If the STS does not support importing federation metadata, but instead requires you to manually input values, you will typically need an App ID and Login or Redirect URL. Both of these values can be copied from the SPP federation metadata XML file you downloaded.

  • The App ID for SPP will come from the entityID attribute of the <EntityDescriptor> element in the XML file.

  • The Login or Redirect URL will come from the Location attribute of the <AssertionConsumerService> element within the <SPSSODescriptor> element.

    NOTE: Only the HTTP-POST binding is supported for this end point.

    NOTE: If using SPP in a clustered environment and you do not use a load balanced DNS name to access SPP, or you wish to be able to log in to a specific node of the cluster, you will have to add additional login redirect URLs to your STS configuration.

You must then configure or ensure that the STS returns the authenticated user's email address as a SAML attribute claim. The email address must appear in either the standard SAML email address claim or name claim:

  • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
  • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

If the emailaddress and name attribute claims are not present in the SAML assertion, the SAML Subject NameID can be used.

NOTE: Any other attributes or claims will be ignored.

The SAML Response or Assertion must be signed, but not encrypted. When the signing certificate used by your STS expires, you may need to update the metadata for the associated external federation provider in SPP depending on how it and your STS are configured:

  • If the external federation provider in SPP was configured by uploading a copy of the STS metadata file, then that needs to be repeated with the new copy of the STS metadata file containing the new signing certificate.

  • If the external federation provider in SPP was configured to use the URL that points to the STS metadata (and the STS supports having multiple active signing certificates for seamless rollover), then you shouldn't have to do anything. SPP periodically attempts to download the metadata and will use the new certificate when it becomes active. Otherwise, you can manually trigger SPP to download and refresh the STS metadata from the configured URL by selecting the external federation provider and clicking the Update Signing Certificates and Metadata toolbar button.

NOTE: Your STS's metadata can contain more than one signing certificate to allow for a grace period between an expiring certificate and a new one.

For further details regarding specific STS servers, see the following knowledge base articles on the One Identity support site: