Does SecureAuth IdP support AssertionConsumerServiceIndex in SAML AuthNRequests

Follow

SecureAuth IdP Version Affected:  9.3 and lower

 

Description: 

Are AuthNRequests using AssertionConsumerServiceIndex instead of AssertionConsumerServiceURL supported by IdP, e.g.:

SAML Request from ServiceProvider: 
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 
                ID="s28cb348252f8d30dd32ae2fda8cf1eb25411bb861" 
                Version="2.0" 
                IssueInstant="2018-09-30T11:55:01Z" 
                Destination="https://idp.domain.com/SecureAuth123/
                ForceAuthn="false" 
                IsPassive="false" 
                AssertionConsumerServiceIndex="0" 
                 > 
 <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">ServiceProvider.domain.com</saml:Issuer> 
 <samlp:NameIDPolicy xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 
                Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" 
                SPNameQualifier="ServiceProvider.domain.com" 
                AllowCreate="true" 
                 /> 
 </samlp:AuthnRequest> 

 

Cause:

AssertionConsumerServiceIndex is used when multiple Service Providers send AuthNRequests to the same IdP endpoint (realm), i.e. many SPs to a single realm.  The IdP should then use the SPs metadata together with the AssertionConsumerServiceIndex to map to the correct AssertionConsumerServiceURL which to send the SAML response back to.

 

Resolution

AssertionConsumerServiceIndex is not currently supported in SecureAuth IdP.
Enhancement request IDP-4685 has been logged to include this feature in a future version of IdP.
 
 
Workaround:
 
Configure a separate realm per Service Provider instead of pointing all Service Providers at a single realm.
 

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

0 out of 0 found this helpful

Comments

0 comments

Please sign in to leave a comment.