How To: Send Additional Claims From a 3rd-Party IdP Through an Existing SP-Initiated SAML Realm

Version Affected: All

 

Overview

This article explains how to federate a 3rd-party Identity Provider (IdP) with an existing SP-initiated SAML realm when you need to pass additional claims — not just the NameID — from the 3rd-party IdP through to the downstream Service Provider (SP).

When federating a new 3rd-party IdP whose users do not already exist in a Datastore connected to SecureAuth, the realm's Datastore is normally set to No Data Store so the realm consumes the attributes the 3rd-party IdP sends directly, as long as they match SecureAuth's naming criteria. This is straightforward when you are adding a brand-new IdP-initiated realm — you simply clone the existing realm and configure it as a SAML consumer.

It is more involved when you are adding this federation to an existing SP-initiated realm that already serves some users from your own Datastore. An SP-initiated flow always starts with the SP Start URL, which sends an AuthN request back to the original realm — not to the new SAML consumer realm the 3rd-party assertion actually landed on. If you only need the NameID, Transparent SSO alone is enough, because the session cookie created by the SAML consumer realm carries the user through. This method is needed when you also need to pass additional claims the 3rd-party IdP sent (such as email address, first name, or last name), because those claims exist only in the SAML consumer realm's own session cookie — the original realm has no access to them when it receives the AuthN request.

Redirecting the Original Realm's AuthN Request to the SAML Consumer Realm

1. Clone the original SP-initiated realm to create a new realm, and set that new realm's Data tab and workflow to consume the SAML assertion sent by the 3rd-party IdP. This is the SAML consumer realm.
2. On the original realm, add an Internet Information Services (IIS) URL Rewrite inbound rule that matches the {HTTP_REFERER} server variable against the 3rd-party IdP's domain, and redirects matching requests to the SAML consumer realm with a Temporary (307) redirect, appending the query string.
3. You can find the exact referrer value to match on by looking at a SAML trace for a login through the 3rd-party IdP. The screenshot below shows an example of this rule: an inbound rule matching {HTTP_REFERER} against the 3rd-party IdP's domain, redirecting to the SAML consumer realm with Append query string checked and Redirect type set to Temporary (307).

Example Login Flow

The following walks through this setup end-to-end, using Salesforce as an example downstream SP:

1. The user logs into the 3rd-party IdP and launches Salesforce, which sends a SAML assertion to the SAML consumer realm.
2. The SAML consumer realm consumes the assertion and triggers Salesforce's SP Start URL.
3. Salesforce redirects back with an AuthN request to the original Salesforce realm — not the SAML consumer realm — because that is the realm configured as the SP-initiated endpoint for Salesforce.
4. The URL Rewrite rule on the original realm inspects the AuthN request's HTTP referrer header and redirects it to the SAML consumer realm.
5. The SAML consumer realm receives the AuthN request from Salesforce and already has the additional claims (such as email address, first name, and last name) cached from the earlier 3rd-party assertion, so it sends a new SAML assertion with those claims to Salesforce and the user is logged in.

Special Considerations

If you only need to pass the NameID and no additional claims, Transparent SSO alone is sufficient and this URL Rewrite redirect is not needed.


 

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.