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

Rod Widdowson rdw at steadingsoftware.com
Wed Oct 11 06:51:18 EDT 2017


Mostly for Brent, with a FU for Scott or Brent...

Can I test my understanding of the Java OpenSAML code here ?

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.

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.

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

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.

/Rod





More information about the dev mailing list