<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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.<br>
<br>
******<br>
<br>
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.<br>
<br>
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.<br>
<br>
In v2 this was simple. The RelyingPartyConfigurationManger
essentially indexed RelyingPartyConfigurations by entityID, so it's
pretty much a straighforward lookup.<br>
<br>
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.<br>
<br>
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. <br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Ideas, suggestions, comments?<br>
<br>
Thanks,<br>
Brent<br>
<br>
<br>
<br>
</body>
</html>