Discussion Topic: Transport confidentiality and integrity; Implementing crypto 'conditional' flag

[Cantor, Scott]

On 2/13/14, 10:44 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>
>Hmm, yeah, I had completely forgotten about that.  In v2, the list is set
>on the ProfileHandler instance (specifically the
>AbstractSAMLProfileHandler).  Off-the-cuff it seems to me that it's an
>input somehow to the action where the binding selection is done (where
>the endpoint selector or Resolver runs).  Either a static config on that
>action, or populated on a subcontext.  Not seeing a reason at the moment
>for the latter, and the former is conceptually simpler.

Yes, I was thinking injection into the action, and my point was just that
I'd like it if we could inject a map of descriptor objects that is
ultimately the thing that is used to lookup the encoder too, one thing to
define (except for per-profile use, see below).

>So I guess you're saying with that approach the set of acceptable
>outbound binding URI's is associated with a given (inbound) binding URI
>basically globally, for all usages of that binding.

No, I was assuming it was a bean that's somewhat like a policy rule set in
that you could have more than one map/bean if needed, and inject per
webflow if needed, but in practice it's probably a global/single map in
most cases.

>Maybe, but that's a little different than what v2 did, since there
> it's really profile handler-specific.  In one profile handler (and in
>v3, a flow) might have X and Y as supported outbound for inbound X, but
>another profile handler/flow could have outbound X, Y and Z for inbound
>X.  I don't know if that always, or even ever, makes practical sense, but
>it's implied by the v2 design.

Whether it's important or not is a useful conversation, but I wasn't
intending to preclude it necessarily.

>Actually, I don't follow.  You mean the descriptor is the value of the
>map (binding URI -> descriptor)?  I guess that's possible, although the
>whole point of the map there is to map binding URI -> Spring bean ID.
>Having the latter as one of descriptor properties
> of a binding seems a bit odd, unless I'm misunderstanding what you mean
>by binding descriptor (I inferred general globally known info about the
>binding, not Spring/deployment-specific info).

I keep forgetting the encoders are not stateless and that it has to map to
a bean ID so it can manufacture the encoder on demand, and not just map to
the encoder. If it's a big deal that the BindingDescriptor would have to
map to a bean ID (i.e. a Spring specific notion), that could be abstracted
somehow with a factory interface that we populate in our situation with a
Spring-specific factory.

But I just wanted to be able to attach binding meta-bits if we need them
later and generally just have a structure to lay out the bindings in use
that fits the design of the other cases where we have descriptors used to
describe things to the actions. It's just a consistency thing that maybe
I'm more a fan of than I need to be.

Something like:

<util:list>
	<bean class=".....BindingDescriptor" p:uri="bindingURI">
		<property name="encoderFactory">
			<bean class="....SpringFactory p:beanID="encoderID"/>
		</property>
	</bean>
</util:list>

Or something along that line.

I guess we talked about whether to use factories or not way back when and
were moving away from that, but it does keep Spring from being baked into
it.

-- Scott