Configuring Multiple Instances of a SAML 2.0 Service Provider in an Identity Server Cluster

You can create different instances of the same SAML 2.0 service provider in an Identity Server instead of having separate Identity Server for each instance.

Consider a scenario where a service provider requires different SAML 2 policies to be defined for different set of users. You need one Identity Server cluster to specify different policies for different set of users of the same service provider.

When you import a service provider for the second time in the same Identity Server cluster, you must provide a unique ID. Access Manager uses this unique ID to change its metadata for a specific instance of the service provider. This helps Access Manager to recognize the policy that should be used for each SAML 2.0 request from the same service provider. To import the same service provider subsequently, add Unique ID for different instances and ensure that the ID is unique and not used by any instance of any service provider. To understand the changes and how Access Manager uses the unique ID, refer to the following example:

An Office 365 service provider has two domains namely, abctest.com and abc.com. For any number of domains that are created in Office 365 the entity ID is same.

If the Office 365 service provider uses Access Manager as the identity provider, perform the following steps:

  1. Import Office 365 for the first instance with the domain abc.com.

    The Access Manager metadata contains the following details:

    The entity ID: entity ID="https://www.idp.com:8443/nidp/saml2/metadata"

    The SSO endpoint: <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://www.idp.com:8443/nidp/saml2/sso>

  2. Import Office 365 for the second instance with domain abctest.com. Access Manager prompts for a unique ID. If the unique ID is uid, Access Manager generates a new metadata that includes separate entity ID and endpoint URLs for the domain abctest.com.

    The generated metadata contains the following details and this metadata must be imported by Office 365:

    For entity ID: entity ID="https://www.idp.com:8443/nidp/saml2/metadata?namInstance=uid"

    For SSO endpoint: <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://www.idp.com:8443/nidp/saml2/sso?uniqueId=uid"/>

    Similarly, all other endpoints include uid as mentioned in the preceding SSO endpoint.

    This metadata must be imported by the service provider.

    The unique ID, uid in entityID helps a service provider to recognize Identity Server as a separate entity. The uid specified for a SAML 2 endpoint is for Identity Server to recognize the service provider as a separate entity. Hence, the service provider must import the metadata specified in the Identity Server cluster for each domain.

The unique ID configuration is available only when you add the trusted service provider whose metadata is already imported. For information about creating a unique ID for different instances of a service provider, see Creating a Trusted Service Provider.

NOTE:After federation, if you change the unique ID, Access Manager’s metadata is changed for the service provider. The metadata URL will not be the same as the entity ID. The metadata link is displayed on the Trust tab of the trusted service provider page in Administration Console.

Hence, the service provider must ensure to re-import the Access Manager metadata.