SAML 1.1 SSO sketched out

[Cantor, Scott]

On 1/22/14, 9:58 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>
>I don't fully grok the ConfitionalRelyingPartyConfiguration yet.  It
>seems more involved than what we had in v2, where it was just relying
>party entityID resolves to RelyingPartyConfiguration.

Yes, this is what supports the extensible model where you can supply
predicates that extend the matching policy. The V2 syntax is supported by
the one I just wrote and checked in, RelyingPartyIdPredicate (but it
supports a superset, it can match against a set of candidates, not just
one Name).

There are several places where we'll have an activation condition that is
of type Predicate<ProfileRequestContext>, so these plugins will work for
all of them.

>Just curious, why
>does that new resolver take as input the ProfileRequestContext, as
>opposed to Criterion or Predicate?  Don't think I've seen us do a
>resolver like that before.

It was Chad's design (I've renamed and refactored a little, but the
signature was there already).

I find it intuitive this way, and I'd probably have to twist my brain to
come up with a way to reverse it, but the request context *is* the
criteria, and then you have predicates attached to the individual objects
being resolved. The Predicates are specific to the data in the context
tree they know how to use (or are injected with strategy functions to get
it).

>Given that, I don't think this would then work exactly as I had been
>envisioning, as a MessageHandler that was just a proxy that executed the
>MessageHandler(-Chain) that it dynamically resolved.  So not as
>generalizable within OpenSAML.  But as long as it works...

Well, a message handler doesn't have to be in OpenSAML, it can be
IdP-specific, if that's what you mean.

I have also toyed with moving the RelyingParty/ProfileConfig layer down,
but when I considered that, it seemed to me that this is really the core
of what makes the IdP the IdP to a significant degree. If we move that
down, we're essentially building the entire IdP in OpenSAML and not
creating a library that can be adapted easily to other IdP designs.

I guess I just decided that was the stopping point, but it does push a lot
of actions up into the IdP that would otherwise be fine in OpenSAML
(unless we inject non-default strategy functions to do the indirection).

>Yeah, I think that's fine.  Thinking about it more, I believe there
>necessarily has to be some work done after the MessageDecoder runs but
>before the "standard" MessageHandlers (the ones that most closely
>reflect what was the SecurityPolicy in v2).  Things like setting
>up/populating context data for the profile in use, including things like
>what the requester's SAML role is (e.g. SPSSODescriptor).  And resolving
>metadata of course.

I did implement that stuff as a MessageHandler, that's installed in the
testbed now. You can decide if the Metadata lookup handler seems like it
should. So that's all there, but the parts that would depend on the
ProfileConfiguration right now wouldn't work as part of that chain,
because those actions run after the chain is done. So that's the part that
has to be broken off.

>Also, I don't think the Anonymous RP config is relevant here, is it?  In
>v2, if we don't have an asserted entityID from the message, we can't run
>(and apropos the above, the MandatoryIssuerRule SecurityPolicyRule
>throws and results in a IdP-side error to the user.  That's not the same
>as having no metadata for the asserted entityID, which is what triggers
>the Anonymous case in v2 (IIRC).  Unless I'm misremembering, there's no
>way to continue if the inbound message does not contain an asserted
>requester entityID.

My view was that we can eliminate that distinction, in order to generalize
this to protocols that don't have requester identity.

I don't see any material difference in those cases, really, policy-wise.
In fact, this is why I've been pushing all the code to rely on
RelyingPartyContext.getRelyingPartyId() any place it wants to do rules
based on the identity. That isn't a Nonnull property, so the code
downstream does in fact check for null now.

But if the SAML cases always set it, then the rule is fine I guess, if
that saves some checking in other places.

>I was hoping it would be that simple to reuse subflows, etc.  Just
>wasn't sure if we know that it actually will work. :-)

It does, I've used them in the authentication flows. I've done some of the
more advanced inheritance that actually adds transition states to actions
in the child flow, and that also works.

So far everything in WebFlow has worked fine with two caveats:

- the coversation state storage issue, which I had to turn off snapshots
and break the back button to make work

- when it runs all these action states in a row, it seems to push them on
the stack recursively rather than run them like functions individually as
a series

I'm mildly concerned that we may blow the execution stack if we keep
chaining actions together in larger numbers, but I have no idea what the
stack size is.

WebFlow is really not designed to run lots of actions, it's meant for
view->action->view kinds of flows that are short bursts of states. It
works nicely for what we're doing with it as a design framework, but it
isn't designed to do so, or it wouldn't be executing states recursively.

-- Scott