<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Thanks, Scott. Comments below...<br>
<br>
David<br>
<br>
<br>
<div class="moz-cite-prefix">On 05/13/2015 04:35 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:07A620A0-EC58-4881-B8C9-F1CB87A27B35@osu.edu"
type="cite">
<pre wrap="">On 5/13/15, 11:11 PM, "David Walker" <a class="moz-txt-link-rfc2396E" href="mailto:dhwprof@gmail.com"><dhwprof@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">That's not "better" matching, and actually doing that outright would be
incorrect in SAML, so I'm pretty sure it doesn't do that. It's using a
login method that satisfies either Silver or Bronze and returning one or
the other depending on the request. Asking for Bronze and returning Silver
would be a spec violation.
"Better" means actually upgrading to a stronger method and then returning
that method, and requires knowing what's better or worse, not just what's
equivalent.
I didn't think the MCB supported inexact matching, but I could be wrong.</pre>
</blockquote>
<br>
Right. My reading of Marvin's use case was that he wanted to
configure the IdP so that a user who had previously authenticated
for Silver within a session would be able to access a
Bronze-requiring SP later in the session without further
authentication. As you indicated in your earlier note, inexact
matching is not the solution for this; I was suggesting an
alternative approach. I agree that the implementation of such a
capability must return Bronze to the Bronze-requiring SP, not
Silver, in this example. (And, yes, you're right that the MCB does
not support inexact matching.)<br>
<br>
<blockquote cite="mid:07A620A0-EC58-4881-B8C9-F1CB87A27B35@osu.edu"
type="cite">
<pre wrap="">
Marvin was asking about V3 in any case.
</pre>
<blockquote type="cite">
<pre wrap="">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 <a class="moz-txt-link-rfc2396E" href="https://wiki.shibboleth.net/confluence/x/EoEEAQ"><https://wiki.shibboleth.net/confluence/x/EoEEAQ></a> we did
says this can be done; can you confirm or deny?
</pre>
</blockquote>
<pre wrap=""><a class="moz-txt-link-freetext" href="https://wiki.shibboleth.net/confluence/display/IDP30/AuthenticationFlowSele">https://wiki.shibboleth.net/confluence/display/IDP30/AuthenticationFlowSele</a>
ction
-- Scott</pre>
</blockquote>
<br>
OK, so it's the supportedPrincipals field of the <a
href="https://build.shibboleth.net/jenkins/job/java-identity-provider-nightly/javadoc/net/shibboleth/idp/authn/AuthenticationFlowDescriptor.html">AuthenticationFlowDescriptor</a>,
right? There's more to it than this (like assuring that only
requested authnContexts are returned to the SP), but I'm planning to
draft an overview of how one would convert an MCB configuration to
v3 in the not too distant future, so more details can be added at
that point.<br>
<br>
</body>
</html>