SAML 1.1 SSO sketched out

[Cantor, Scott]

On 1/17/14, 8:44 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:

>** Preamble / Decode / Configuration Lookup **

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

Ugh, I forgot about that.

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

The ConditionalRelyingPartyConfigurationResolver class is what does the
lookup, and the actual rules it follows are inside predicates that run
against the ProfileRequestContext. None of those are done yet.

Since the metadata lookup and really all of the config lookup is done
based on an "asserted" identity that should be known after the
MessageDecoder runs, could we break this up a little and do separate
MessageHandler chains, one that's "fixed" to do work like the metadata
lookup, and then the more dynamic one that runs after we run the IdP
actions that resolve the configuration?

I'm not wedded to the current actions, but it just seems like making the
profile actions that act on the ProfileRequestContext into message
handlers is not the ideal thing to do.


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

The profile ID is on the ProfileRequestContext already, and it's set by
the bootstrapping action (first one in the flow). We can obviously add
whatever is needed to the ProfileConfiguration.

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

My point though is what does it accomplish? If we don't have an issuer,
then a lot of the earlier code will either have to error out, or more
likely just ensure that the appropriate RP config is the Anonymous one. By
the time this runs, isn't it academic?

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

Ok. If it stays as a class, I think we should rename it and not call it
"Metadata", just too confusing.

>** Response Generation **
>
>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".

Chad did. I was halfway into changing that, but eventually concluded that
it worked better to just leave it, and then define new actions that set
error statuses. Some of that will likely change as the error handling
fleshes out.

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

Was planning to reuse, but don't know if it will work.

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

I was hoping all that would just drop in and be reused by making them
subflows. Note that we have parts of the flow now that I want to move off
into reusable subflows because they will be common to all profile flows,
or at least all the SAML ones. I'm just waiting until we have a complete
flow that's closer to done.

-- Scott