Problem AuthnContextClassRef with Comparison="exact"

Domenico Cervino cervinodomenico at libero.it
Tue Mar 5 13:24:30 UTC 2024


Thanks everyone, we have already set idp.authn.External.addDefaultPrincipals to false.
 
We were hoping that our strange behavior was a known problem, from our point of view if it is not our configuration error it seems like a shibboleth bug.
 
Precondition: logged in with method_a.
 
Possible shibboleth bug or our configuration error -> An sp arrives with method_a NOT in the first position in RequestedAuthnContext in its request, there is no SSO as expected because only the first element is evaluated:
 
[net.shibboleth.idp.authn.impl.FilterFlowsByNonBrowserSupport:57] - Profile Action FilterFlowsByNonBrowserSupport: Request does not have non-browser requirement, nothing to do
2024-03-05 09:13:20,372 - 192.168.43.178 - DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:401] - Profile Action SelectAuthenticationFlow: Specific principals requested with 'exact' operator: [AuthnContextClassRefPrincipal{authnContextClassRef=method_b}, AuthnContextClassRefPrincipal{authnContextClassRef=method_a}]
2024-03-05 09:13:20,373 - 192.168.43.178 - DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:512] - Profile Action SelectAuthenticationFlow: Checking for an inactive flow or active result compatible with operator 'exact' and principal 'method_b'
2024-03-05 09:13:20,374 - 192.168.43.178 - DEBUG [net.shibboleth.idp.authn.principal.PrincipalEvalPredicateFactoryRegistry:126] - Registry located predicate factory of type 'net.shibboleth.idp.authn.principal.impl.ExactPrincipalEvalPredicateFactory' for principal type 'class net.shibboleth.idp.saml.authn.principal.AuthnContextClassRefPrincipal' and operator 'exact'
2024-03-05 09:13:20,374 - 192.168.43.178 - DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:527] - Profile Action SelectAuthenticationFlow: Active result for flow authn/External not usable, ignoring
2024-03-05 09:13:20,375 - 192.168.43.178 - DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:369] - Profile Action SelectAuthenticationFlow: Selecting inactive authentication flow authn/External
 
An sp arrives with method_a in the first position in its request, there is SSO as expected:
 
FilterFlowsByNonBrowserSupport: Request does not have non-browser requirement, nothing to do
2024-03-05 09:31:05,097 - 192.168.43.178 - DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:401] - Profile Action SelectAuthenticationFlow: Specific principals requested with 'exact' operator: [AuthnContextClassRefPrincipal{authnContextClassRef=method_a}, AuthnContextClassRefPrincipal{authnContextClassRef=method_b}]
2024-03-05 09:31:05,098 - 192.168.43.178 - DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:512] - Profile Action SelectAuthenticationFlow: Checking for an inactive flow or active result compatible with operator 'exact' and principal 'method_a'
2024-03-05 09:31:05,100 - 192.168.43.178 - DEBUG [net.shibboleth.idp.authn.principal.PrincipalEvalPredicateFactoryRegistry:126] - Registry located predicate factory of type 'net.shibboleth.idp.authn.principal.impl.ExactPrincipalEvalPredicateFactory' for principal type 'class net.shibboleth.idp.saml.authn.principal.AuthnContextClassRefPrincipal' and operator 'exact'
2024-03-05 09:31:05,103 - 192.168.43.178 - DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:385] - Profile Action SelectAuthenticationFlow: Reusing active result authn/External
 
Has no other user experienced this problem?

Thanks
Domenico

> Il 04/03/2024 17:57 CET Cantor, Scott <cantor.2 at osu.edu> ha scritto:
> 
>  
> You should also bear in mind the property idp.authn.External.addDefaultPrincipals is true by default.
> 
> What that means, as is documented, is that any "supported" Principal in the configuration of the External login flow will be automatically attached to the Subject created by the flow, which means that SSO will work for any requests that carry any of those context classes.
> 
> If your Exernal flow is programatically controlling which AuthnContext class to include, then by definition you also have to turn the property off, which is also documented, or you will get unexpected behavior.
> 
> -- Scott


More information about the users mailing list