<!doctype html>
<html>
<head>
<meta charset="UTF-8">
</head>
<body>
<p class="default-style">Hi,</p>
<div>
we have an idp based on shibboleth idp 4 libs customozied with the External flow.
<br>With the pages we have implemented the user can choose different methods to log in.
<br>We have listed these methods in idp.authn.External.supportedPrincipals in authn.properties.
<br>When the login process with one of these methods has concluded correctly, we programmatically set this method in this way:
<br>..
<br>principals.add(new AuthnContextClassRefPrincipal(methodUsed));
<br>..
<br>request.setAttribute(ExternalAuthentication.SUBJECT_KEY, new Subject(false, principals, Collections.EMPTY_SET, Collections.EMPTY_SET));
<br>..
<br>ExternalAuthentication.finishExternalAuthentication(key, request, response);
</div>
<div>
So far nothing strange, it was an introduction to our situation.
</div>
<div>
SPs send authentication requests listing one or more of these methods inside the RequestedAuthnContext with exact comparision type.
</div>
<div>
</div>
<div>
For example SP_1 send a request with these methods:
</div>
<div>
<em><samlp:RequestedAuthnContext Comparison="exact"></em>
<br><em><saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">method_a</saml:AuthnContextClassRef></em>
<br><em><saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">method_b</saml:AuthnContextClassRef></em>
<br><em></samlp:RequestedAuthnContext></em>
<br>(in real case we can have more than 2 methods , in this example we list only two for simplicity)
</div>
<div>
</div>
<div>
On the main login page the user chooses a login method with which to authenticate, for example the login type associeted with method_a and he logs in successfully.
</div>
<div>
</div>
<div>
The user subsequently moves to a resource protected by another sp, let's call it SP_2 which sends this inside the authentication request:
</div>
<div>
</div>
<div>
<em><samlp:RequestedAuthnContext Comparison="exact"></em>
<br><em><saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">method_a</saml:AuthnContextClassRef></em>
<br><em><saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">method_b</saml:AuthnContextClassRef></em>
<br><em></samlp:RequestedAuthnContext></em>
</div>
<div>
</div>
<div>
The idp does not ask for a new authentication and the user logs in without doing anything: the sso occurred.
</div>
<div>
</div>
<div>
The user subsequently moves to another sp, let's call it SP_3 which sends this inside the authentication request:
</div>
<div>
</div>
<div>
<em><samlp:RequestedAuthnContext Comparison="exact"></em>
<br><em><saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">method_b</saml:AuthnContextClassRef></em>
<br><em><saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">method_a</saml:AuthnContextClassRef></em>
<br><em></samlp:RequestedAuthnContext></em>
</div>
<div>
</div>
<div>
In this case, the idp ask for a new authentication and the user must to re-login: the sso did not happen.
</div>
<div>
</div>
<div>
We have do a lot of test with different SPs and various combinations It seems like the idp doesn't check all of the "saml:AuthnContextClassRef" items listed inside "samlp:RequestedAuthnContext" from SP's request. It seems that only the first element is checked, and SSO will only occur when the method with which you have already logged in appears in the first position.
</div>
<div>
</div>
<div>
In this example SP_3 don't have SSO because method_a is not in first position. SP_2 or any other sp with method_a in first position they will have sso.
</div>
<div>
</div>
<div>
In previous versions of our product based on shibboleth idp v2, sso occurs if method_a is present in the request anywhere in the list.
</div>
<div>
</div>
<div>
Is there something in the configurations that we may not have configured correctly when moving to idp v4?
</div>
<div>
</div>
<div>
Thanks
</div>
<div>
Domenico
</div>
<div>
</div>
</body>
</html>