Metadata support: Supported resolver query semantics; Iteration

[Brent Putman]

On 8/12/13 5:48 PM, Cantor, Scott wrote:
> See above. Some of those are possibly relevant for discovery purposes, but
> that isn't an IdP use case.

Yeah, I was mainly concerned about whether we were going to screw people
using the OpenSAML-J metadata providers to implement discovery
interfaces.  I assume our CDS uses that, but not sure.

> Don't know how it aligns, but there are reasons one might want to find a
> matching entity and role, but still return the entity if no role can be
> found. At least there are in the SP.

Hmm, ok. I'd have to think about that, i.e. make the role eval
optional.  Maybe it's just that: note in the new API as it is, you'd
need 2 different components for that anyway: 1) a MetadataResolver
(which perhaps we should rename to EntityDescriptorResolver?) and 2) a
RoleDescriptorResolver.  The basic impl I have right now of the latter
wraps and delegates to an instance of the former, but they have to be 2
different impls b/c you can't have a class which in Java which
implements a generically-parameterized interface twice (or more)
differing only in the generic parameterization (b/c generics are
implemented by erasure).  So if you want both the EntityDescriptor and
RoleDescriptor when the latter is found, it's just: resolve the role
with RoleDescriptorResolver and then getParent() to get the
EntityDescriptor.  However if you want the EntityDescriptor in the case
where no RoleDescriptor was found, that's going to be a second
resolution against the Metadata(/EntityDescriptor)Resolver

I guess a more fundamental question here is: should the
Metadata(/EntityDescriptor)Resolver really process any input criterion
other than entityID?  I guess entity attributes would be one case,
perhaps other arbitrary Extensions.  But the role-related criteria seem
to make less sense.  Is it useful for it to support "search on entityID
X and role Y" if it's still going to return the whole EntityDescriptor
with *all* the roles, not just role Y?  If you want just role Y,
presumably you'd just use the RoleDescriptorResolver instead.  Same
thing for protocol and binding location, the other criteria which Chad
had already defined.


>
>> I *think* in Columbus we had discussed potentially having another
>> interface provide an API like: Iterable<EntityDescriptor> etc.
>> Resolvers that can could optionally support this API also. This could be
>> used for the basic iteration cases.
> That's what I recalled. And our time right now needs to be spent on what
> the IdP needs, so keeping things separate is a reasonable way to do that.

Fortunately this should be pretty easy to implement, just need a simple
Iterable/Iterator that traverses a metadata tree, returning
EntityDescriptors.