<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 6/1/15 6:45 PM, Cantor, Scott wrote:<br>
</div>
<blockquote cite="mid:AD35F0CC-4DC2-4CB9-BF29-A5C7348A7654@osu.edu"
type="cite">
<pre wrap="">On 6/1/15, 9:31 PM, "Brent Putman" <a class="moz-txt-link-rfc2396E" href="mailto:putmanb@georgetown.edu"><putmanb@georgetown.edu></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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. </pre>
</blockquote>
</blockquote>
<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
<blockquote cite="mid:AD35F0CC-4DC2-4CB9-BF29-A5C7348A7654@osu.edu"
type="cite">
<blockquote type="cite">
<pre wrap="">Being
able to define a custom Criterion seems like the ideal approach.
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
</body>
</html>