Endpoint resolution

[Brent Putman]

On 2/18/14 2:13 PM, Cantor, Scott wrote:
>
> 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.

I just spent some time reviewing all your new BindingDescriptor and
EndpointResolver and related code.  Looks pretty good, I like it.

Just noting for my own (and anyone else's) edification that a couple of
things implied by the BindingDescriptor design are that:

1) you can inject different List<BindingDescriptor> instances  to
different components/flows to get different behavior for different use cases
and/or
2) a descriptor list can contain more than one BindingDescriptor for a
given binding URI, presumably with a different activation predicate

I think having the multiplicity and flexibility of that sounds good.




>  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.

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.

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.



>  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).

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.

Actually, I just noticed there'd already be beanName duplication in what
you have already, for shibboleth.OutgoingSAML2SSOBindings vs
shibboleth.OutgoingSAML2SLOBindings.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20140220/bc144491/attachment.html