Evaluable criteria

[Brent Putman]

On 6/1/15 6:45 PM, Cantor, Scott wrote:
> On 6/1/15, 9:31 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>
>
>> Additionally, I have a use case in IDP-701 that could benefit as well; I 
>> need to implement some creative logic to look up an EntityDescriptor when 
>> I don't have a true Entity ID provided by a SAML protocol message. 


I forgot to comment earlier on that specific detail.  I don't know what
is being envisioned here, but: doesn't anything involving use of SAML
metadata fundamentally assume an entity identifier of some kind?  It may
not truly be a "SAML entity ID" coming from a SAML protocol message, etc
- but I'd think you'd have some sort of required URI identifier that
would serve to identify the actor(s) in the exchange.

Fwiw, "entityID" in the library does not technically mean  "SAML entity
ID".  For example, Credentials (which exist in a module that doesn't
know anything about SAML) carry an entityID property, which is just a
(String) identifier for the owner of the credential (if known).  It was
obviously inspired by the need for and concept of SAML entity ID's, though.


>> Being 
>> able to define a custom Criterion seems like the ideal approach.
> It wouldn't work, but subclassing the existing plugins to add support for 
> an additional Criterion subtype should work, as does adding functionality 
> to the existing base classes.

Yes, I'd think supporting filtering on arbitrary Predicate Criterions
passed in the CriteriaSet to a MetadataResolver would be pretty easy. 
Maybe implement resolve(...) way up in AbstractMetadataResolver and have
it do the filtering, the way the abstract filtering CredentialResovler does.

The only reason I didn't just do that was:  Something like that is
mostly useful if you do *not* look up by EntityIdCriterion.  If you do,
then you get back (usually) just one any way, so not much to filter.

OTOH, per the TODO, if you want to support resolution *without* an
EntityIdCriterion, that brings up concerns about efficiency.  It might
not work well to iterate a large metadata batch of 100's or 1000's of
entity descriptors.

It works well for the credential resolver case, b/c:  You first lookup
some candidate Credentials based on the "lookup" criteria.  That may
very well be > 1, but is likely to be a small number.  You then can
reasonably filter that small number with predicates (e.g. only RSA keys,
only keys meeting a size constraint, etc).  It doesn't work as well for
metdata b/c the collection of pre-filter candidates is either going to
typically 1 (so not useful), or potentially very large.

Along those lines, I have given some thought to the need to support
additional indexes on EntityDescriptors besides entityID, hopefully
pluggable.  That would in some address this issue - although then the
relevant criteria would likely be used as "lookup" criteria, rather than
as predicates.

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