Authn Better Matching

[David Walker]

Catching up after vacation...

The way the MCB handles what I think you want to do is to allow you to
specify which authentication contexts satisfy the requirements of other
contexts.  In this case, you'd specify that Silver satisfies Bronze, and
then the MCB could use Silver authentication to satisfy an SP's request
for Bronze.

My memory is that the v3 IdP also has this concept, although I'm not
finding it on a quick scan of the documentation.  Scott, the gap
analysis <https://wiki.shibboleth.net/confluence/x/EoEEAQ> we did says
this can be done; can you confirm or deny?

David

---------- Forwarded message ----------
From: Marvin Addison <marvin.addison at gmail.com>
Date: Mon, May 4, 2015 at 9:58 AM
Subject: Authn Better Matching
To: SHIB-USERS <users at shibboleth.net>


Apparently I don't understand the better matching facility in
idp/conf/authn/authn-comparison.xml. I'm trying to support both silver
and bronze assurance profiles by defining a handler that supports
silver exclusively, while using better matching to drive the IdP to
the silver handler when the SP requests bronze since silver is indeed
better than bronze. That does not work; I get the following logs when
the SP sends the bronze AuthnContextClass:

2015-05-04 10:37:37,309 - DEBUG
[net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:341] - Profile
Action SelectAuthentication
Flow: Specific principals requested with 'exact' operator:
[AuthnContextClassRefPrincipal{authnContextClassRef=http://id.incommon.
org/assurance/bronze}]
2015-05-04 10:37:37,310 - DEBUG
[net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:348] - Profile
Action SelectAuthentication
Flow: No active results available, selecting an inactive flow
2015-05-04 10:37:37,310 - DEBUG
[net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:369] - Profile
Action SelectAuthenticationFlow: Checking for an inactive flow
compatible with operator 'exact' and principal
'AuthnContextClassRefPrincipal{authnContextClassRef=http://id.incommon.org/assurance/bronze}'
2015-05-04 10:37:37,310 - DEBUG
[net.shibboleth.idp.authn.principal.PrincipalEvalPredicateFactoryRegistry:80]
- 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'

I can infer from the message that the matching semantics are exact,
which presumably doesn't engage inexact matching. But I would think
this is exactly the kind of case for which inexact and better matching
in particular is intended to support. I think I can get this to work
another way, but I'd like to understand why this doesn't work; and if
it doesn't work by design, what kinds of cases it's intended to
support.

FWIW, my test SP simply has the following configuration directive in
the Apache config:

ShibRequestSetting authnContextClassRef http://id.incommon.org/assurance/bronze

Thanks,
M


--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150513/c0dce365/attachment.html>