SAML 1.1 SSO sketched out

[Brent Putman]

On 1/18/14 6:05 PM, Cantor, Scott wrote:
>
>> 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.

Ok, I don't think I had actually seen any of that before.

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

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


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

Yes.  The (slightly) weird thing about this, also in v2, is that you use
the asserted RP identity before you've actually authenticated that
identity.  But there's no way around it, it's a chicken-and-egg thing.


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

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.  In v2 that stuff either runs in the ProfileHandler
(which orchestrates all this) or in the MessageDecoder, which did a lot
of context population (if I'm remembering correctly).


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

No, probably not.  Especially if what we're really talking about is
stuff that is mostly specific to the IdP (like dealing with
RelyingPartyConfiguration).


>
>> Moving on from there: CheckMandatoryIssuer. 
> 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?

Well, in v2, this didn't mean that it was *authenticated* (there's
another rule for that).  It was really just the place, at the end of the
decoding process, where we validated that we did in fact have that data,
so that later code could just assume that it would populated and not
have to check.  If it shakes out in v3 that we don't need it, then
that's fine, but if we do it's like 5 minutes of coding to implement as
a MessageHandler.

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.


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

Agreed, I have never liked the use of -Metadata- in that class name, too
overloaded in our world.


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

It's probably fine, I guess it's just (for SAML 2) changing the
StatusCode value on the Status and adding a StatusMessage.  Don't see
why it wouldn't work.
 

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


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