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."
KB : KB000113081