Authn Better Matching

David Walker dhwprof at
Wed May 13 19:11:27 EDT 2015

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 <> we did says
this can be done; can you confirm or deny?


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

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:
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
2015-05-04 10:37:37,310 - DEBUG
- Registry located predicate factory of type
for principal type 'class
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

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

ShibRequestSetting authnContextClassRef


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list