LocalDynamicMetadataProvider for CAS metadata?

[Brent Putman]

On 2/21/19 1:23 PM, Cantor, Scott wrote:
> On 2/21/19, 12:18 PM, "users on behalf of Liam Hoekenga" <users-bounces at shibboleth.net on behalf of liamr at umich.edu> wrote:
>
>> Is it possible to use the LocalDynamicMetadataProvider for CAS?
> Yes.


I think that might be a qualified yes.  Unless I'm mis-remembering,
this is still based on matching an ACS endpoint location against the
supplied CAS service URL, right?  Meaning, it's not based on an
entityID as with SAML?

If so, then like the HTTP/MDQ case, there's no way to *directly* ask
the dynamic providers for such metadata.  I.e. there's no "question"
defined (yet) to ask the metadata "oracle" for something matching an
endpoint location URI, in the way one can with the SHA-1 hash of the
entityID to support say SAML artifact.  So you can't fundamentally
fetch the metadata solely on that kind of criteria.


>
>> But when I try to log in, the looks in the metadata, doesn't seem to find it, and decides that it's unverified...
> Have you successfully managed it with the normal batch case? Some of the settings required to make it work are the same and have to be manually applied to either type of metadata plugin.
>

If you're talking about the secondary indexing config, that's the
"qualified yes" part.  You can certainly configure such secondary
indexing to support the CAS case, and the config is the same for batch
and dynamic. 

However with dynamic, that only works for resolving data that is
already fetched and indexed locally. You can't initially fetch the
entity data based on the CAS endpoint. So you could "pre-load" the
entity descriptor one way or another (such as the new-ish admin
endpoint), and then it will be indexed and resolvable via the
non-entityID criteria.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20190221/f7266699/attachment.html>