Delegation: Policy enforcement and ProfileConfiguration resolution

[Cantor, Scott]

On 9/28/15, 9:15 PM, "dev on behalf of Brent Putman" <dev-bounces at shibboleth.net on behalf of putmanb at georgetown.edu> wrote:


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

These are the SPs the delegate is allowed to access? Constraints the delegation in other words.

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

Well, it's more abstract than that, it's just anything that relies on the IdP from my perspective.

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

Well, my incomplete thought was that it would obtain the relying party the predicates (which are mostly RP-based) are looking at using a lookup strategy, so the only ordering that would matter would be the same type of order that matters already.

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

I have a hard time understanding that abstraction, so I didn't design around it.

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

Not necessarily, we could make it implement a dual interface and change the calling code we control to use the new one.

-- Scott