<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 12/27/13 7:32 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote
cite="mid:BA63CEAE152A7742B854C678D9491383CA1B45EF@CIO-KRC-D1MBX01.osuad.osu.edu"
type="cite">
<pre wrap="">
<a class="moz-txt-link-freetext" href="https://wiki.shibboleth.net/confluence/display/IDP30/SAML+1.1+Browser+SSO">https://wiki.shibboleth.net/confluence/display/IDP30/SAML+1.1+Browser+SSO</a>
There are a number of design questions, mostly needing discussion with
Brent once he's back from vacation, but a lot of the code is already there
from Chad's work and just needs cleanup.
</pre>
</blockquote>
<br>
<br>
Here's my first pass comments on this. Apologies for the length.
Mostly it's on the beginning and end of flow where OpenSAML is
heavily involved. Most of the stuff in the middle I think either
sounds fine, or I don't know enough about it to comment
intelligently.<br>
<br>
<br>
** Preamble / Decode / Configuration Lookup **<br>
<br>
The big thing here is the message handler chain that runs via
WebFlowMessageHandlerAdaptor. Scott already mentions the need to
have the metadata resolved early b/c the message handlers need to
use metadata, but it gets worse... Scott and I discussed the
following a bit back in the Spring in Arlington, but we've never
fleshed this out, so I guess now's the time.<br>
<br>
Essentially: the MessageHandler(-Chain) that actually runs here
needs to be dynamically selected, it's not a static thing. At
least, it does if we want any semblance to what v2 supported. It
was/is specific to a relying party config and profile config.<br>
<br>
For comparison, in v2 see the SecurityPolicyResolver and its
IdP-specific impl RelyingPartySecurityPolicyResolver. The latter
uses the inbound message issuer's entityID and the configured
profile ID to lookup the correct SecurityPolicy to apply, using the
RelyingPartyConfigurationManager. The SecurityPolicy lives on the
ProfileConfiguration in v2. The SecurityPolicyResolver gets set on
the v2 MessageContext and is executed by the message decoder (which
in v2, unlike in v3, is responsible for applying the security policy
on the inbound message).<br>
<br>
Based on the current code, and what Scott and I had preliminarily
discussed: the WebFlowMessageHandlerAdaptor would get injected with
a special MessageHandler impl that would use inbound message data
(from MessageContext) to resolve the MessageHandler(-Chain) to run,
and then run it. In order to do this resolution, it would need
access to the relying party and profile config info, and something
would have to tell the flow (statically I guess) what the profile ID
was and so forth. So this "resolving MessageHandler proxy" would
necessarily live in the IdP. <br>
<br>
I don't think this is terribly hard code-wise, esp since we already
have pretty much the same model from v2. Just need a
"MessageHandlerResolver" component that gets injected with the
thing that can resolve RelyingPartyConfigurations (what is this in
v3?). Looks like what's missing is that we don't have any slot
currently on the v3 ProfileConfiguration to hold a
MessageHandler(-Chain). And then we'd need to decide how this code
knows or looks up the profile ID in use (maybe we already have a
context where for where that lives, haven't gotten that far in my
code review). <br>
<br>
Moving on from there: CheckMandatoryIssuer. Scott questions whether
we need it. In v2 this runs at the end of the security policy, and
I would think that if we do this check at all, we could just do it
as a MessageHandler in the inbound chain. (This action was left
over from Chad, who saw everything as an action, but we've somewhat
changed from that). I had meant to do a SAML-specific version of
this in opensaml-saml-impl, but looks like I didn't yet. It's
probably 6 lines of code. It would verify the presence of a
SAMLPeerEntityContext#getEntityId().<br>
<br>
A related comment regarding the BasicMessageMetadataContext is: It
had been my intention that at a minimum, the messageIssuer property
there would go away, in favor of the more protocol/spec-specific way
of identifying actors (e.g. SAMLPeerEntityContext), which then gets
copied into the other subsystems' contexts where and as needed.
It's been on my todo list, but there was a lot in the IdP that
referenced it and hadn't tackled it yet. <br>
<br>
MessageContext children: I'll work on a write-up of this next
week. In general, Scott mentions the need to populate these. One
thing to note is that a lot of the SAML-specific message contexts
intended to be used as direct children of MessageContext are
"smart", and know how to lookup info from the SAML message in the
MessageContext#getMessage(). See for example SAMLPeerEntityContext,
SAMLMessageInfoContext, SAMLSubjectNameIdentifierContext. The goal
was to avoid needing to have explicit handler/action code that
populated these as simple bean properties. So you can just take
advantage of subcontext autocreate, grab one of these from the
MessageContext and access the relevant message data, with nothing
else needed.<br>
<br>
<br>
** Response Generation **<br>
<br>
As we discussed recently and Scott mentions, the plan currently is
to go with outside-in as far as building things up. This sounds
fine, but it did occur to me, for the Response: I guess you start
out by building it up by assuming "success". But what happens in
the case of an error later in the flow, where you're going to return
a non-success SAML protocol message? Do you reuse what you were
building, or do you start from scratch? I guess this gets in to the
whole error handling aspects of the flows, and I'm interested to see
how we're going to do that, esp things like handling outbound
message signing and other outbound message handling stuff on the
error flow (as in: reuse the same outbound message handler and
encoders, etc, or have separate ones).<br>
<br>
<br>
** Post Processing / Encode **<br>
<br>
I guess the big question here is how we're going to do the dynamic
encoder selection for SAML front-channel, since that's based on the
binding URI selected at runtime. As Scott notes, I had come up with
2 main approaches to that.<br>
<br>
The first is essentially WebFlow-centric: You have a distinct
message encoder action for each binding you support. You select
which action you use based on a <transition> expression. The
latter would have to evaluation something available to it, so for
example something might populate a "bindingURI" property on the
flowScope.<br>
<br>
The second is to have a single message encoder action which is
injected with a Spring-aware component that looks up the
MessageEncoder instance (which is a prototype bean) based on the
binding URI. I came up with 2 ways to implement the lookup: A) one
with a simple map, similar to what we had in v2, except that the map
values are bean ids rather than actual bean instances) and B) use a
naming convention to translate binding URIs -> bean names, and
take advantage of bean aliases (<bean name="..." />). The
draft impl in the testbed of the lookup component supports both
(idp.SpringAwareEncoderLookup).<br>
<br>
These 2 (really 3) are sketched out in the testbed, but since
they're all there, it may not be immediately obvious what goes with
what approach. If there's a specific question, let me know. The
one that actually runs right now on the SAML 2 flow in the test bed
is the lookup one using the map, so 2A.<br>
<br>
I think the work to implement any of these is largely done, at least
in the testbed. We just need to pick one (or come up with another
solution). Of the 2 fundamental approaches, I personally prefer the
second, lookup-based one (2A with the map, followed in preference by
2B with URI->bean name translation). I think the WebFlow
transition stuff could get messy (split across flow and bean
definitions), and it also means you have to maintain that in every
flow definition potentially (unless it's in an abstract one I
guess). The Spring-aware lookup-based stuff is all localized in one
place in the Spring bean config, so just one place to keep
synchronized.<br>
<br>
That's what I've got for now.<br>
<br>
--Brent<br>
<br>
<br>
<br>
<br>
<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
</body>
</html>