Protection Level for Partnership not taken into account

Document ID : KB000113081
Last Modified Date : 05/09/2018
Show Technical Document Details
Question:
I configure a PartnerShip with protection level of 5, and when the
browser access the RelayState URL which is protection level of 10, the
browser doesn't get redirected to the remote IdP authentication
scheme.

Why ?

Here's the browser journey : 

a. The realm I'll be using as relayState of SP-initiated SAML is 
   protected by an HTML Form authentication scheme with level 10 

b. The partnership has a protection level of 5 

c. I forge the first request on the SiteMinderAsSP authNrequest 
   service with partnerID targetting the IdP of the partenership, and 
   relayState targetting the realm defined in a) 

d. once authenticated on IdP, I'm auto-POSTing the assertion on the 
   SiteMinderAsSP ACS service that will generate a Siteminder cookie 
  --> for me, this cookie should be of level 5 because of b) 

e. cookie is generated and pushed to my browser, then I'm redirected 
   to a) URL but I enter automatically --> I should not because b) is 
   level 5 and a) is level 10, so I should be redirected to a) 
   authentication scheme 
Answer:
Usually, IdP and SP sides have different domains. Let say IdP is 
idp.com and SP is sp.com. 

Once logged on IdP (idp.com), so an SMSESSION cookie is produced with 
security level 5 for domain idp.com. An assertion is also generated 
and POSTed to the SP side. Then because the domain name is different, 
the SMSESSION will not be sent to SP side. Only the SAMLResponse. The 
SP side (sp.com) will consume the assertion and because it trusts the 
identity, it will create a session corresponding to the realm that 
protect the relaystate. 

In that case, another SMSESSION cookie will be produced with domain 
.sp.com and with a Security Level of 10. You're browser won't go back 
to the IdP to authenticate. 

In order to get the authentication level passed by the samlresponse, 
you should refer to the : 

Dynamic Authentication Context Processing (SAML 2.0) 

Dynamic Authentication for SP-Initiated SSO 

Authentication context processing follows these steps: 

As part of an SP-initiated SSO transaction, an SP can request that a 
user be authenticated with a particular authentication context. The 
Service Provider includes an <RequestedAuthnContext> element as part 
of the authentication request that it sends to the Identity 
Provider.As part of an SP-initiated SSO transaction, an SP can request 
that a user be authenticated with a particular authentication 
context. The Service Provider includes an <RequestedAuthnContext> 
element as part of the authentication request that it sends to the 
Identity Provider. 

[...] 

The SP sends an authentication request with the 
<RequestedAuthnContext> element and a comparison operator. 

The IdP receives the request. One of the following actions occur. 

If the user does not have a valid session, the IdP uses the supplied 
<RequestedAuthnContext> and the authentication context template in use 
by the partnership. In the template, each URI is mapped to an 
Authentication URL. The IdP determines the authentication URL based on 
the requested authentication context and redirects the user to that 
URL. The IdP authenticates the user with that URL and a session for 
that user is generated. 

If the SP does not include a <RequestedAuthnContext> in the request, 
the IdP uses the default authentication URL from the template. The 
default entry determines the authentication context. This context 
determines the minimum authentication level. 

If the user has a valid session, the IdP compares the authentication 
level for the session with the AuthnContext requested by the SP. The 
comparison is based on the comparison operator that is sent in the 
request. If the authentication level is high enough, the IdP generates 
an assertion. If the authentication level is too low, the 
<RequestedAuthnContext> element and comparison operator determine the 
authentication context URI to use. Based on the URI mapping in the 
template, the IdP redirects the user to the corresponding 
authentication URL. The IdP authenticates the user and a user session 
is generated. If there is no match, the IdP returns a NoAuthnContext 
response to the SP. The response includes a message that the IdP does 
not support the requested authentication context. 

If configured, the SP verifies whether the authentication context URI 
in the assertion is valid as compared to its configuration. If the 
validation is successful, the authentication transaction is complete. 

https://docops.ca.com/ca-single-sign-on/12-52-sp1/en/configuring/partnership-federation/set-the-user-authentication-context-required-by-the-sp/dynamic-authentication-context-processing-saml-2-0 

and to configure it : 

Dynamic Authentication Context Template Configuration 
https://docops.ca.com/ca-single-sign-on/12-52-sp1/en/configuring/partnership-federation/set-the-user-authentication-context-required-by-the-sp/dynamic-authentication-context-processing-saml-2-0/dynamic-authentication-context-template-configuration 

Enable Autentication Context Requests at the SP-to-IdP Partnership 
https://docops.ca.com/ca-single-sign-on/12-52-sp1/en/configuring/partnership-federation/set-the-user-authentication-context-required-by-the-sp/dynamic-authentication-context-processing-saml-2-0/enable-autentication-context-requests-at-the-sp-to-idp-partnership 

Remember that the "Minimum Authentication Level" won't affect the SP 
behavior. It will only accept the authentication at IDP if this one 
has authentication level over the one defined here, whatever the 
Authentication Level at the SP side. 

Minimum Authentication Level 

"Specifies the minimum level at which the user must have authenticated 
to gain access to a realm. If the user has authenticated at this level 
or higher, the Identity Provider generates an assertion for the 
user. If the user is not authenticated at this level or higher, they 
are redirected to the Authentication URL to authenticate at this 
level."