Proposal to resolve entities by role+protocol

[Brent Putman]

On 12/8/15 10:43 AM, Cantor, Scott wrote:
> On 12/7/15, 4:53 PM, "dev on behalf of Marvin Addison" <dev-bounces at shibboleth.net on behalf of marvin.addison at gmail.com> wrote:
>
>
>> 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.

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.

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

Unless there was some specific reason why you didn't want to go this
route, that's how I would prefer to proceed.


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

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.

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20151209/2c260650/attachment.html>