<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 9/28/15 8:46 PM, Cantor, Scott
wrote:.
</div>
<blockquote cite="mid:E59ED4CD-0C85-4851-A654-07155220FB73@osu.edu"
type="cite">
<pre wrap="">
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.</pre>
</blockquote>
<br>
Well, as I said, it's really the ProfileConfiguation for the Liberty
profile. That's the way we had it in v2 and whoever (you? Chad?)
ported stuff over to v3 preemptively put in on the
ProfileConfiguration in v3. So it's already there. We'd have to
deprecate that (of course we haven't used yet, so no big deal). But
actually it does feel like profile config to me.<br>
<br>
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.<br>
<br>
The other one is weirder, because it's not really an active party in
the request at all. Basically, have to pluck the first entityID in
the delegation chain in the DelegationRestrictionType Condition of
the inbound Assertion token. It's that entity whose config for the
max delegation chain depth is effective.<br>
<br>
<blockquote cite="mid:E59ED4CD-0C85-4851-A654-07155220FB73@osu.edu"
type="cite">
<pre wrap="">
I guess coming at this differently, what's in the PRC for each of the actors you have to look up settings for?</pre>
</blockquote>
<br>
Well, for the presenter/ECP, I guess right now it's just a tree
under PRC->InboundMessageContext->SAMLPresenterEntityContext.
I think. So far there wasn't any need to put anything directly under
the PRC as "profile data".<br>
<br>
For the other one, there's nothing. It's not an active party in the
request, so that's why it's kind of weird.<br>
<br>
<br>
<blockquote cite="mid:E59ED4CD-0C85-4851-A654-07155220FB73@osu.edu"
type="cite">
<pre wrap="">
</pre>
<pre wrap="">
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?</pre>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote cite="mid:E59ED4CD-0C85-4851-A654-07155220FB73@osu.edu"
type="cite">
<pre wrap="">
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.</pre>
</blockquote>
<br>
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.<br>
<br>
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>. 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.<br>
<br>
<br>
<blockquote cite="mid:E59ED4CD-0C85-4851-A654-07155220FB73@osu.edu"
type="cite">
</blockquote>
<br>
</body>
</html>