SAML Consumer with SP Init Realms

Version Affected:  All

Description:  

When Federating with another IdP, if the Users don't already exist in a Datastore connected to SecureAuth, you need to set the DataStore to No Data Store. 

With this setup, we will consume the attributes as the 3rd Party IdP has sent them, as long as they match our naming criteria. 

However, what happens if you're adding a federation to an existing SAML integration where you also have some users from your own Datastore. 

With IdP initiated realms, you simply clone the existing realm and set up the SAML consumer. 

With SP initiated realms, you'll need the SP Start URL to send you to the SP to get an AuthN request. Which will then redirect you to the "original" realm, not the new federated realm.

If you only need the NameID, you can use TransparentSSO so that the federated user follows this path.

3rd Party IdP > SecureAuth Saml Consumer Realm (creates Cookie)

SP Start URL (Get's AuthN request)

SecureAuth Saml SP initiated Realm (Consumes AuthN request and cookie and logs you in)

However, this doesn't work if you're sending additional claims

Cause:  

Only the SAML Consumer realm will have access to the additional claims that the 3rd Party IdP sent as these will be stored in a session cookie. 

Resolution:  

Use URL rewrite to move the 3rd Party users back to the SAML consumer realm.

1. Clone the original SP init realm and set the Datatab and workflow to consume SAML
2. On the original realm, setup a URL rewrite rule to look for {HTTP_REFERRER} and redirect to the SAML consumer realm with a 307 and include the query string.
3. See screenshot for an example of how a referrer looks - you can find the referrer by looking in a SAML trace.
   
    

End Workflow/User Experience

1. User logs into their IdP and launches their app which sends an assertion to the saml consumer realm (Realm22)
2. Realm 22 consumes the assertion and triggers the SPStartURL (Salesforce in my case)
3. Salesforce redirects to the original Salesforce realm (Realm5) with an AuthN request
4. URL ReWrite on Realm5 inspects the HTTP Referrer header and redirects me to Realm22
5. Realm22 sees the AuthN request from Salesforce and already has the Email, FirstName, Lastname from the 3rd Party SAML assertion so it sends these in a new SAML assertion to Salesforce and the User is logged in.

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.