<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 12/8/15 10:43 AM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:24B7F649-25C4-49FE-B168-F3342EB61814@osu.edu"
type="cite">
<pre wrap="">On 12/7/15, 4:53 PM, "dev on behalf of Marvin Addison" <a class="moz-txt-link-rfc2396E" href="mailto:dev-bounces@shibboleth.netonbehalfofmarvin.addison@gmail.com"><dev-bounces@shibboleth.net on behalf of marvin.addison@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
I would appreciate review and feedback. I'm not wedded to this approach; I'm just trying to move the ball forward on what I need for IDP-701. That said, the patch does provide a feature mentioned in Brent's TODO comments, so it's arguably generally beneficial. The biggest concern I guess is the functional change from requiring an EntityIdCriterion to being more flexible about required criteria.
</pre>
</blockquote>
</blockquote>
<br>
Honestly, I'm not keen on a one-off approach like this. It probably
works, but: Maybe you didn't get a chance to look at it before I
pulled it from 3.2.0, but I was probably 90-95% finished with the
more generalized secondary indexing framework I had in mind. And I
had a good chunk of the specific endpoint indexing plugin impl done
also, that does the indexing by sub-path segments for partial path
matching like is discussed in IDP-701. I think mostly what remained
was deciding on what the endpoint index input criteria would look
like - reuse existing multiple critieria or create a new compound
Criterion holding data for just this case. That's all covered in
OSJ-128 and its subtasks, specifically OSJ-129 for the endpoint
index.<br>
<br>
Only reason why I pulled it was: We weren't going to actually use it
in 3.2.0 (for neither your CAS stuff nor inbound SAML artifact
binding). I didn't want to unnecessarily and prematurely commit to
the APIs, without having a chance to really test them out "for
real".<br>
<br>
Unless there was some specific reason why you didn't want to go this
route, that's how I would prefer to proceed.<br>
<br>
<br>
<blockquote cite="mid:24B7F649-25C4-49FE-B168-F3342EB61814@osu.edu"
type="cite">
<pre wrap="">
Brent knows the APIs better than I do, but I'll just say that this seems to break the current separation between the MetadataResolver type and the RoleDescriptorResolver. Seems like we need to rationalize that one way or the other. It would seem odd to support role-based criteria above, but keep the RoleDescriptorResolver in there.</pre>
</blockquote>
<br>
Sort of, I guess. But remember that MetadataResolver is essentially
a Resolver<EntityDescriptor> and RoleDescriptorResolver is a
Resolver<RoleDescriptor>. Different output types, so not
really the same.<br>
<br>
You could absolutely support role-based indexes I think in a
MetadataResolver. If you wanted efficient lookup of a role
*without* an entityID supplied, you'd pretty much have to do that.
That would be true even if what you were really doing was calling
into a RoleDescriptorResolver, as the only current impl of that
interface just wraps a MetadataResolver, and applies some light
filtering on the returned EntityDescriptor(s). You'd need the
indexing on the wrapped MetadataResolver.<br>
<br>
IIRC I think I actually did already implement a RoleDescriptor
secondary index plugin, just because it was easy and a good
proof-of-concept for the secondary indexing framework. I didn't
include protocol in that index, but that would be trivial to add I
think. So this would be easy to accomplish within the secondary
indexing framework. If we wanted.<br>
<br>
But as I said above, I think what we really wanted for the CAS case
was full indexing of endpoints, and I think that's not too far away
from being done. Probably after the holidays, but sometime in
January.<br>
</body>
</html>