Delegation: Policy enforcement and ProfileConfiguration resolution

[Brent Putman]

TL/DR: The v3 RelyingPartyConfigurationResolver doesn't work the way I
need to get at ProfileConfigurations for non-"relying party" entityIDs,
so I'm stuck.  Help.

******

I think the last functional part of the Liberty delegation profile flow
left to do is the policy enforcement.  The policy code itself is easy,
could knock it out quickly.  But I think I've run into a stumbling block
due to the differences in relying party config between v2 and v3.

Essentially, the functional requirement is that: Given an entityID, I
need to resolve the Liberty ProfileConfiguration
(net.shibboleth.idp.saml.idwsf.profile.config.SSOSProfileConfiguration)
for the entity.  That's where the policy data currently lives.

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

In v3, I've realized that the equivalent component
RelyingPartyConfigurationResolver functions entirely differently, and
makes this very difficult, perhaps impossible.  For those who don't know
(and also to state my understanding in case I'm missing something), the
RPCR essentially has (in addition to the default and unverified configs)
a List<RelyingPartyConfiguation>.  Each RPC is a
Predicate<ProfileRequestContext>.  The resolution operation is simply to
loop over all the RPCs and return the one(s) that match the Predicate. 
That's actually ostensibly nice, and simple, and is more flexible than
v2 since it allows to resolve based on things other than entityID.

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.  The existing,
primary ones match against the data in the PRC->RelyingPartyContext,
reflecting the (overwhelming) majority use case of the "relying party"
role.  Problem is, what I need to resolve is data expressly for entities
in roles other than the formal "relying party" role in the particular
request flow.  So there's no way to do that with the existing impls.

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.

Aside from the obvious nastiness, it's not nice for the deployer because
of the ordering requirement, which is easy to screw up/misunderstand,
but also because of the seemingly unnecessary duplication of config for
the same entityID for the same profile (assuming entityID-centric
configs, and not entity groups or attributes).  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.

So I really can't see that working very well.  Hoping Scott or Tom or
anyone else more familiar with this subsystem can confirm my
understanding of the fundamental issues, and point me at potential
solutions I may be missing.

But if we can't re-use the RPCR machinery, the only other option I see
is to ditch the ProfileConfiguration as the storage for the policy bits,
and just do something specifically for the Liberty profile. All I really
need is something like a Map<String, DelegationConfig>, perhaps with a
Resolver abstraction around it.  That also feels wrong from a
deployer/support point of view (uh, shouldn't config for a profile be on
the ProfileConfiguration...), but at least I know I can make that work.

Ideas, suggestions, comments?

Thanks,
Brent


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