Delegation: Policy enforcement and ProfileConfiguration resolution

[Cantor, Scott]

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



>In v2 this was simple.  The RelyingPartyConfigurationManger essentially indexed RelyingPartyConfigurations by entityID, so it's pretty much a straighforward lookup.

It wasn't exactly that (the IDs were not just entityIDs but groups also), but the assumption was those namespaces wouldn't collide I guess.

>However, the problem for me is that the RPC encapsulates not only the user-configured data (e.g. entityIDs, entity attributes, etc), but also the strategy by which the data is compared to the PRC.

Yes, I see that was a mistake.

>The only possible way I can see to do this with the existing RPCR is very ugly and hacky, and probably not nice for the deployer:  Have additional RPC instances which have a different Predicate(s) which match against different data in the PRC, to reflect different
> roles in the profile/protocol.  These would have to be listed first in the relying-party.xml (otherwise the ones with relying party predicates would match first).  In order not to pollute the PRC for the relying party case, the caller would have to push the
> role data onto the PRC, call the resolver, and then pull it off, using it like a call stack.

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.

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

>Because of the encapsulation of the predicate strategy in the PRC, you'd have to up to 3 different RPCs for a given entity for the Liberty profile, for example.  E.g. 1) the SAML requester role (the standard "relying party" role); 2) the SAML presenter/ECP role; and 3) the "I was first in the delegation chain" role.

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?

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.

-- Scott