I configure a PartnerShip with protection level of 5, and when thebrowser access the RelayState URL which is protection level of 10, thebrowser doesn't get redirected to the remote IdP authentication
Here's the browser journey :
a. The realm I'll be using as relayState of SP-initiated SAML isprotected 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 authNrequestservice with partnerID targetting the IdP of the partenership, andrelayState targetting the realm defined in a)
d. once authenticated on IdP, I'm auto-POSTing the assertion on theSiteMinderAsSP 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 redirectedto a) URL but I enter automatically --> I should not because b) islevel 5 and a) is level 10, so I should be redirected to a)authentication scheme
Usually, IdP and SP sides have different domains. Let say IdP isidp.com and SP is sp.com.
Once logged on IdP (idp.com), so an SMSESSION cookie is produced withsecurity level 5 for domain idp.com. An assertion is also generatedand POSTed to the SP side. Then because the domain name is different,the SMSESSION will not be sent to SP side. Only the SAMLResponse. TheSP side (sp.com) will consume the assertion and because it trusts theidentity, it will create a session corresponding to the realm thatprotect 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 backto 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 auser be authenticated with a particular authentication context. TheService Provider includes an <RequestedAuthnContext> element as partof the authentication request that it sends to the IdentityProvider.As part of an SP-initiated SSO transaction, an SP can requestthat a user be authenticated with a particular authenticationcontext. The Service Provider includes an <RequestedAuthnContext>element as part of the authentication request that it sends to theIdentity 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 useby the partnership. In the template, each URI is mapped to anAuthentication URL. The IdP determines the authentication URL based onthe requested authentication context and redirects the user to thatURL. The IdP authenticates the user with that URL and a session forthat user is generated.
If the SP does not include a <RequestedAuthnContext> in the request,the IdP uses the default authentication URL from the template. Thedefault entry determines the authentication context. This contextdetermines the minimum authentication level.
If the user has a valid session, the IdP compares the authenticationlevel for the session with the AuthnContext requested by the SP. Thecomparison is based on the comparison operator that is sent in therequest. If the authentication level is high enough, the IdP generatesan assertion. If the authentication level is too low, the<RequestedAuthnContext> element and comparison operator determine theauthentication context URI to use. Based on the URI mapping in thetemplate, the IdP redirects the user to the correspondingauthentication URL. The IdP authenticates the user and a user sessionis generated. If there is no match, the IdP returns a NoAuthnContextresponse to the SP. The response includes a message that the IdP doesnot support the requested authentication context.
If configured, the SP verifies whether the authentication context URIin the assertion is valid as compared to its configuration. If thevalidation is successful, the authentication transaction is complete.
and to configure it :
Dynamic Authentication Context Template Configurationhttps://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 Partnershiphttps://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 SPbehavior. It will only accept the authentication at IDP if this onehas authentication level over the one defined here, whatever theAuthentication Level at the SP side.
Minimum Authentication Level
"Specifies the minimum level at which the user must have authenticatedto gain access to a realm. If the user has authenticated at this levelor higher, the Identity Provider generates an assertion for theuser. If the user is not authenticated at this level or higher, theyare redirected to the Authentication URL to authenticate at thislevel."
KB : KB000113081