Protection Level for Partnership not taken into account
book
Article ID: 113081
calendar_today
Updated On:
Products
CA Single Sign On Secure Proxy Server (SiteMinder)CA Single Sign On SOA Security Manager (SiteMinder)CA Single Sign-On
Issue/Introduction
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
Environment
Release: MSPJBO99000-12.52-Single Sign-On-Agent for JBoss-for MSP Component:
Resolution
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 :
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.
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."