Delegation: Policy enforcement and ProfileConfiguration resolution

[Brent Putman]

On 9/28/15 9:23 PM, Cantor, Scott wrote:
> These are the SPs the delegate is allowed to access? Constraints the delegation in other words.

Yeah, I think so.  That's looking at it in the opposite direction from
the way I phrased it, but I think they're the same. 

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

My go-to for these role definitions has always been SAML 2 core 3.4, and
this is what it says for RP:

Relying Party

The entity or entities expected to consume the assertion(s) to
accomplish a purpose defined by
the profile or context of use, generally to establish a security context

So neither of the cases here fits that definition.  Of course we can
(re)define things any way we like, but I generally start from things
that already exist.  'Cause you know, I'm lazy. :-)


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


I don't really follow (yet), but I'll think about it more.


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

A whole new interface, yes.  Just remember that with generics you can't
implement an interface multiple times merely by varying the generic
params (due to the type erasure), so the new 2nd interface couldn't be a
Resolver.



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