<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Catching up after vacation...<br>
<br>
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.<br>
<br>
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 <a
href="https://wiki.shibboleth.net/confluence/x/EoEEAQ">gap
analysis</a> we did says this can be done; can you confirm or
deny?<br>
<br>
David<br>
<br>
<pre wrap="">---------- Forwarded message ----------
From: Marvin Addison <a class="moz-txt-link-rfc2396E" href="mailto:marvin.addison@gmail.com"><marvin.addison@gmail.com></a>
Date: Mon, May 4, 2015 at 9:58 AM
Subject: Authn Better Matching
To: SHIB-USERS <a class="moz-txt-link-rfc2396E" href="mailto:users@shibboleth.net"><users@shibboleth.net></a>
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=<a class="moz-txt-link-freetext" href="http://id.incommon">http://id.incommon</a>.
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=<a class="moz-txt-link-freetext" href="http://id.incommon.org/assurance/bronze">http://id.incommon.org/assurance/bronze</a>}'
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 <a class="moz-txt-link-freetext" href="http://id.incommon.org/assurance/bronze">http://id.incommon.org/assurance/bronze</a>
Thanks,
M
--
To unsubscribe from this list send an email to <a class="moz-txt-link-abbreviated" href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a>
</pre>
<br>
</body>
</html>