<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/13/14 10:04 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:CF22EE72.8B41%25cantor.2@osu.edu" type="cite">
<pre wrap="">
</pre>
<pre wrap="">
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.</pre>
</blockquote>
<br>
I haven't really come up with anything concrete either, but I think
the 2 issues are somewhat distinct.<br>
<br>
<blockquote cite="mid:CF22EE72.8B41%25cantor.2@osu.edu" type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
<br>
That was pretty much my reasoning as well, I just want to make sure
I'm not missing something obvious.<br>
<br>
I just checked in my code, so there it is.<br>
<br>
<br>
<blockquote cite="mid:CF22EE72.8B41%25cantor.2@osu.edu" type="cite">
<pre wrap="">
</pre>
<pre wrap="">
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.</pre>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote cite="mid:CF22EE72.8B41%25cantor.2@osu.edu" type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote cite="mid:CF22EE72.8B41%25cantor.2@osu.edu" type="cite">
<pre wrap="">
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.</pre>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote cite="mid:CF22EE72.8B41%25cantor.2@osu.edu" type="cite">
<pre wrap=""> 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.
</pre>
</blockquote>
<br>
<br>
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).<br>
<br>
<br>
</body>
</html>