<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 2/18/14 2:13 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:CF291AF3.8DD8%25cantor.2@osu.edu" type="cite">
<pre wrap="">
Brent, I added a saml-binding-config.xml Spring file in idp-conf in "user"
space where the lists of outgoing bindings are laid out.</pre>
</blockquote>
<br>
I just spent some time reviewing all your new BindingDescriptor and
EndpointResolver and related code. Looks pretty good, I like it.<br>
<br>
Just noting for my own (and anyone else's) edification that a couple
of things implied by the BindingDescriptor design are that:<br>
<br>
1) you can inject different List<BindingDescriptor> instances
to different components/flows to get different behavior for
different use cases<br>
and/or<br>
2) a descriptor list can contain more than one BindingDescriptor for
a given binding URI, presumably with a different activation
predicate<br>
<br>
I think having the multiplicity and flexibility of that sounds good.<br>
<br>
<br>
<br>
<br>
<blockquote cite="mid:CF291AF3.8DD8%25cantor.2@osu.edu" type="cite">
<pre wrap=""> I'm still
thinking we could use this for encoder lookup, maybe by extending the
OpenSAML BindingDescriptor class with a Spring version that adds a bean ID
to use for the encoder.</pre>
</blockquote>
<br>
Seeing the concrete impl of your idea, it seems to make sense to do
that. Just also noting that the multiplicity of BindingDescriptors
means that in theory you could have different MessageEncoder impls
and/or beans "mapped" for the same binding URI. Also a nice
feature, albeit an unusual use case. Although the capability
carries with it the expense of presumably having to duplicate the
URI -> beanName mapping in multiple places. But since that's not
a typical use case, I imagine it's not a big downside.<br>
<br>
Btw, were you thinking that the actual MessageEncoder beans would be
defined in this file also, or elsewhere? Maybe makes sense to keep
them together to avoid getting out-of-sync. In the testbed I had
them (really the sole one) defined in abstract-sso-beans.xml, but
that was really just because there wasn't another logical place at
the time.<br>
<br>
<br>
<br>
<blockquote cite="mid:CF291AF3.8DD8%25cantor.2@osu.edu" type="cite">
<pre wrap=""> My concern is just the work of defining the
bindings multiple places if we keep the two uses separate
(ordering/enabling them vs. encoder lookup).
</pre>
</blockquote>
<br>
Yeah, I don't like the idea of defining in multiple places either
(and was the reason I didn't like the SWF transition-based
approach). If one does define multiple BindingDescriptors, then
you have to duplicate the beanNames across them, but that's less bad
than duplicating binding info in two places I suppose.<br>
<br>
Actually, I just noticed there'd already be beanName duplication in
what you have already, for shibboleth.OutgoingSAML2SSOBindings vs
shibboleth.OutgoingSAML2SLOBindings.<br>
<br>
</body>
</html>