SAML 1.1 SSO sketched out

[Brent Putman]

On 1/22/14 10:27 PM, Cantor, Scott wrote:
>> 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.

Yeah, that's what I meant, Dynamically resolving a
MessageHandler(-Chain) is something you generally might want to do, with
only the resolution logic being pluggable via an interface.  But if that
pluggable interface is going to be something that is inherently too-IdP
specific in terms of design, then we can just leave it out of
OpenSAML.   Such a MessageHandler impl itself is trivial, all the
complexity is in the resolution.

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

No, doesn't seem appropriate for OpenSAML to me either.

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

It's fine if we have Shibboleth IdP-specific impls of OpenSAML
interfaces, etc.  I don't think we should be trying push things that are
inherently about Shibboleth or our specific IdP design down, just
because we could.


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

Ok, I'll take a look.


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

Ah, hadn't really thought about that vis-a-vis non-SAML protocols (and
for that matter, how those protocols would even work...).  But I'd think
for SAML the implicit constraint will still necessarily match the old v2
definition: Anonymous (SAML) means you had no metadata, and no requester
identity means failure (although the latter can't really technically
happen in all the extant SAML profiles we implement). 


>> 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 really meant specifically whether we could factor the outbound
MessageHandler(-Chain) and MessageEncoder into a subflow such that it
would work for both the standard "success" case as well as the error
cases returning a SAML protocol-level error.  Maybe/hopefully it "just
works", seems like it would.  But then things often do until you go and
try them.


> I've done some of the
> more advanced inheritance that actually adds transition states to actions
> in the child flow, and that also works.

Cool.

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

Eeek.  I would have thought a chain/serially.  Yes, that is a bit
worrisome if it actually does that.  Hmmm.

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

Hmmm, yeah. 

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

Yeah.  We sort of knew that, but were hoping that it would work out.  I
guess we're reaching the point where we're going to find out if we bet
the farm on something good or bad.