<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Starting a new thread on this for clarity.<br>
<br>
I had brought up the issue of how we implement the signing and
encryption 'conditional' enum value in the IdP. In v2 this is based
on the outbound MessageEncoder evaluating the message context and
returning booleans for message channel integrity and confidentiality
respectively. In v3 implementing this using the MessageEncoder is
less straighforward because of the loosely coupled nature of the web
flow, esp in the front-channel cases where the outbound
MessageEncoder is selected dynamically at runtime.<br>
<br>
Scott said:<br>
<blockquote type="cite">
<pre wrap="">
It does seem a little odd to me to ask an encoder for properties of a
binding. It's not wrong or anything, but it isn't any less wrong to
formally describe a binding, and have the encoder be one of its properties.</pre>
</blockquote>
<br>
<br>
This got me to thinking more about this whole problem "from
scratch". <br>
<br>
A couple of notes:<br>
<br>
1) We know that in some cases having the message encoder do the eval
is simply problematic, if not flat out wrong. Consider the SOAP
encoder. To provide the confidentiality and integrity eval, it
simply evaluates (in an indirect way via the Transport stuff we had
in v2) the HttpServletRequest#isSecure(). But we know this is wrong
in cases where there is a SOAP intermediary, e.g. ECP or delegation
cases. This is a key point.<br>
<br>
2) As a practical observation, the only encoders which actually did
any meaningful eval of these at all were the aforementioned SOAP
encoders. All the others (e.g. SAML front-channel) hard-code
'false', because it is known in advance that the message channel by
definition does not support those capabilities.<br>
<br>
I think I've come to the realization that the v2 model was wrong and
we shouldn't try and port as-is to v3. Whether or not
confidentiality and integrity are "active" for the messaging channel
is not really a function of MessageEncoder, or even of the binding
in use. It's basically determined by (and pardon the technical
jargon) "whatever the hell you are doing". <br>
<br>
In v3 that means it's essentially a property/characteristic of a
particular flow definition, or at least the knowledge behind how the
flow is fundamentally composed: inbound binding, protocol,
front-channel vs back-channel, etc. Which means that for a given
flow, you either know the confidentiality/integrity capabilities in
advance, or know how to evaluate them at runtime for that particular
flow.<br>
<br>
So what I'm proposing is that the confidentiality and integrity
flags just become runtime properties stored on a subcontext the
profile request context (location TBD). How they get populated is
flow-specific - but in practice it's also really simple. <br>
<br>
As noted above, most of the actual use cases we have implemented to
date are just hardcoded 'false'. For these flow cases, we therefore
don't even (technically) need an action to populate anything,
assuming 1) the subcontext which carries these defaults them to
false as is the case for most boolean properties and 2) the thing
wanting to eval the subcontext just uses auto-create. If we wanted
to explicitly document on the flow what was in effect, we could have
a simple action that just took 2 property-wired flags and just set
those on the subcontext. This is the approach that would be used
for most of our extant use cases (SAML front-channel, ECP,
back-channel delegation).<br>
<br>
For the no-intermediary SOAP case, we'd just have an action which
evaled the HttpServletRequest#isSecure() as in v2. So also a very
simple action.<br>
<br>
And then as far as the IdP actions and the crypto 'conditional'
flag, they really just have to examine this subcontext's flags which
were populated (or implicitly defaulted) earlier in the flow and
that's it. Very simple, and loosely coupled.<br>
<br>
The only outstanding question in my mind at the moment is whether
this approach works or not for other use cases and protocols they we
haven't implemented or considered . So far I haven't come up with
any, but that's mainly what I wanted to get others' input on.<br>
<br>
In meantime, I'll just check in these 2 or 3 classes as a straw man
(I know for me it's often easier to think looking at code). One of
the advantages of this approach is that it's simple and easy to
implement, and if it proves workable, then we're done.<br>
<br>
--Brent <br>
</body>
</html>