Artifact metadata resolution in java OpenSAML and FU question on using the MDQ

[Brent Putman]

On 10/11/17 6:51 AM, Rod Widdowson wrote:
>
> 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.

Yep.  I pretty much already implemented the metadata resolver support
for this, for the batch metadata resolver case.

>
> 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.

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.

>
> - 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.

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:

https://issues.shibboleth.net/jira/browse/OSJ-181

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.

> 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

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.

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).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20171011/30b7687b/attachment.html>