<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 10/11/17 6:51 AM, Rod Widdowson
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:00b001d3427e$de829a50$9b87cef0$@steadingsoftware.com">
<pre wrap="">
If we ever decided that the IdP would need metadata lookup in pursuit of implement an artifact profile (consuming someone else's
artefacts that is, not generating and then looking up its own) we would (of course) have to be able to get hold of the Entity for
the artifact. This is what the ArtifactCrtiterion is about.</pre>
</blockquote>
<br>
Yep. I pretty much already implemented the metadata resolver
support for this, for the batch metadata resolver case.<br>
<br>
<blockquote type="cite"
cite="mid:00b001d3427e$de829a50$9b87cef0$@steadingsoftware.com">
<pre wrap="">
Adding the ability to process ArtifactCrtiterion in an IdP would mean:
- For the Batch Resolver, do something smart with configuring a secondary Index Manager (I see that there is a
SAMLArtifactMetadataIndex just waiting to be wired in to a metadata store. This can be done by configuration, all the code exists.</pre>
</blockquote>
<br>
Yep. The index just needs to be wired up. We don't do by default
now since we don't have full inbound artifact support (decoder,
etc), but when we do, we probably should wire the
SAMLArtifactMetadataIndex in by default. Or at least make it a
boolean property + Spring magic, etc.<br>
<br>
<blockquote type="cite"
cite="mid:00b001d3427e$de829a50$9b87cef0$@steadingsoftware.com">
<pre wrap="">
- For the LocalDynamicMetadataResolver, do something smart inside fetchFromOriginSource (having done something equally smart in the
AbstractDynamicMetadataResolver, probably to do with secondary indices as well). This would need that some code be written.
Also needing code is the one that actually interests me: for the XYZDynamicHTTPMetadataResolver: probably add a Function which
takes the artifact and generates the MDQ URL using the {sha1}HEXDIGIT identifier (section 2.2.2 of the MDQ SAML profile). Handwave
about caching.
</pre>
</blockquote>
<br>
That is all correct wrt to likely having function(s) to generate MDQ
request URLs and appropriate indexing. There is actually already an
issue for this:<br>
<br>
<a class="moz-txt-link-freetext" href="https://issues.shibboleth.net/jira/browse/OSJ-181">https://issues.shibboleth.net/jira/browse/OSJ-181</a><br>
<br>
It was mostly for my own note-taking, so if any questions arise from
what my notes there meant (may only make sense to my brain), just
let me know.<br>
<br>
<blockquote type="cite"
cite="mid:00b001d3427e$de829a50$9b87cef0$@steadingsoftware.com">
<pre wrap="">
The follow up question is whether, for the purposes of any of our code targeting the MDQ protocol (and here I really mean the SP),
do we care about the small subset of SAML1 artifacts which don't use the SHA1 of the entityID (and thus are consumable by the MDQ).
I think that these are just SAML1Artifacts of type 2 and SAML1Artifacts with a <SourceID> inside them</pre>
</blockquote>
<br>
For the Java side of the house I did support indexing by source
location for the artifact types that carry that instead of the
source ID notion. That's primarily for batch though. I did not
concretely consider that one could resolve that type of artifact via
MDQ since there is no profile for that. But I did not want to
exclude that possibility nor any assumptions about future MDQ
extensions/profiles, which is why the design and issues noted in
OSJ-181 are what they are.<br>
<br>
For the SouceID artifact types, I very much did not want to limit
this to the common SHA-1 implementation, which is not all that is
allowed for via the spec. And as a particular case, a metadata
extension can explicitly specify the SourceID artifact value for an
entity).<br>
<br>
</body>
</html>