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

[Brent Putman]

On 2/13/14 10:04 PM, Cantor, Scott wrote:
> I'm still struggling with how I think the various security parameters
> should be placed in the tree, but modulo that question, I don't see
> anything to disagree with in terms of all that.

I haven't really come up with anything concrete either, but I think the
2 issues are somewhat distinct.

>
> I think it does by definition because all you're really saying is that
> whatever can be known/determined is expressed in a manner that's
> independent of the binding/encoder abstractions, which is clearly
> necessary since it isn't always related to either. If you could conjure a
> use case in which it's impossible to determine from the emergent state of
> the system whether the flags are true or not, then by definition nothing
> we attempt to use to expose those values is going to work.
>
> Either we have a way to tell or we don't.

That was pretty much my reasoning as well, I just want to make sure I'm
not missing something obvious.

I just checked in my code, so there it is.


>
> The only comment I have is not really related to this question, but the
> earlier notion of how we talk about bindings. Specifically, there's a way
> in V2 to express the permissible outbound bindings (it's on the profile
> definition in handler.xml), and we need that in V3 (for endoint
> determination) but it's not obvious to me yet where to put it.

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.


>
> When I originally thought we needed to think about hanging these flags off
> of some kind of binding descriptor, I was thinking that set of descriptors
> might be the way we implement that signal of supported bindings.

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


> Anyway, point being, I think with the approach of using a map to lookup
> the encoder to use for a binding, we need to just have that map be a bean
> we can inject in at least one other spot.

Yeah, I think that's a given.  In what I did in the testbed, I did it as
an inner bean (albeit with an id), but that wasn't really intentional.


>  For generality, I'd favor having
> something called a BindingDescriptor even if there's not much in it, and
> have the map be of those objects.


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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20140213/9861036a/attachment.html