<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<div class="moz-cite-prefix">On 2/21/19 1:23 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:4982CA9D-7EB3-45FB-9BEE-EC94EE386207@osu.edu">
<pre class="moz-quote-pre" wrap="">On 2/21/19, 12:18 PM, "users on behalf of Liam Hoekenga" <a class="moz-txt-link-rfc2396E" href="mailto:users-bounces@shibboleth.netonbehalfofliamr@umich.edu"><users-bounces@shibboleth.net on behalf of liamr@umich.edu></a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Is it possible to use the LocalDynamicMetadataProvider for CAS?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Yes.</pre>
</blockquote>
<p><br>
</p>
<p>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?<br>
</p>
<p>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.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:4982CA9D-7EB3-45FB-9BEE-EC94EE386207@osu.edu">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">But when I try to log in, the looks in the metadata, doesn't seem to find it, and decides that it's unverified...
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.
</pre>
</blockquote>
<p><br>
</p>
<p>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. <br>
</p>
<p>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.</p>
<p><br>
</p>
<p><br>
</p>
</body>
</html>