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

[Brent Putman]

Starting a new thread on this for clarity.

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.

Scott said:
>
> 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.


This got me to thinking more about this whole problem "from scratch".

A couple of notes:

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.

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.

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

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.

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. 

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

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.

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.

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.

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.

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