Delegation: Policy enforcement and ProfileConfiguration resolution

[Brent Putman]

On 9/28/15 8:46 PM, Cantor, Scott wrote:.
> When you're looking up the entityID, what settings are you trying to access? It seems like they wouldn't really fit as a profile configuration very well. Maybe I'm just too limited in my thinking to the RP being a requester of the profile.

Well, as I said, it's really the ProfileConfiguation for the Liberty
profile.  That's the way we had it in v2 and whoever (you? Chad?) ported
stuff over to v3 preemptively put in on the ProfileConfiguration in v3. 
So it's already there.  We'd have to deprecate that (of course we
haven't used yet, so no big deal).  But actually it does feel like
profile config to me.

On specific settings: For the party in the presenter/ECP role: a setting
determines which SAML requesters/SP's are allowed to operate "through"
it.  In v2 it was just a list of entityID's.  Whoever did the the v3
port made it a Predicate<ProfileRequestContext>, which nominally sounds
fine.

The other one is weirder, because it's not really an active party in the
request at all.  Basically, have to pluck the first entityID in the
delegation chain in the DelegationRestrictionType Condition of the
inbound Assertion token.  It's that entity whose config for the max
delegation chain depth is effective.

>
> I guess coming at this differently, what's in the PRC for each of the actors you have to look up settings for?

Well, for the presenter/ECP, I guess right now it's just a tree under
PRC->InboundMessageContext->SAMLPresenterEntityContext.  I think. So far
there wasn't any need to put anything directly under the PRC as "profile
data".

For the other one, there's nothing.  It's not an active party in the
request, so that's why it's kind of weird.


>
> See above...how are we doing it anyway, leaving the config machinery aside?
>
> Should this be driven by the MultiRPContext I created, which can have labeled roles for its children?

Well, maybe, but to be strict about it, none of these are really
"relying parties", in my traditional understanding of the term, within
that particular instance of the request flow.  (They were of course
relying parties during earlier requests).  I vaguely remember your
MultiRPContext, but was thinking that was really for cases where you
really did have multiple RPs: targeting an Assertion at multiple
recipients, etc.  I didn't think this really fit that, but you would
know better.


>
> My thought is that perhaps we can make this more dynamic by attaching a lookup strategy function to the context tree to parametrize the logic inside the predicates.

Maybe.  But with the way that the looping over RPCs and predicates work,
isn't it still going to be highly dependent on the order of RPCs?  For
any given state of the PRC, you're going to get one particular result,
given a particular order of RPC's.  Unless you push stuff on and pull
stuff off of the RPC like I was describing.

Driving things *solely* from the PRC state seems to me to be the real
problem here.  I was kind of wondering why the RPCR was a
Resolver<RelyingPartyConfiguration,ProfileRequestContext> and not a
Resolver<RelyingPartyConfiguration,CriteriaSet>.  The latter could still
allow things to work the same way they do today (with a Criterion that
holds the PRC), but also allows additional params to the call.  I guess
too late for that, until 4.x at least.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150928/8ce1830d/attachment.html>