Dynamic metadata resolution and transformed identifiers

[Brent Putman]

I was thinking about how to do some testing of the dynamic metadata
provider.  Ideally I wanted to just use a plain web server, without the
complexity of a "metadata service app" sitting in the middle.  E.g. I
wanted to use a template-based URL builder with a template something
like "https://www.example.org/metadata/${entityID}.xml".

Problem is of course that many entityIDs have '/'  and possibly other
characters in them that are not legal filename characters on most
platforms and filesystems.  So I hit upon the idea of wanting to
transform the entityID in some way, and realized that this is probably
generally useful in the real world.  It allows for the possibility of a
simple, poor man's metadata "service" that is just a folder o' metadata
on a web server.

The template and MDQ request URL builders now support an optional
Function<String,String> transform function.  Since the main obvious
transform route is hashing, I also added in java-support a new
StringDigester impl of that which takes a String, digests it using a
specified digest algorithm, and then outputs in the specified format,
either Base64 or hexadecimal (either lower or upper case).

That then allows for example an entityID of "https://www.example.org/sp"
and a template of "https://www.example.org/metadata/${entityID}.xml" to
resolve to:

https://www.example.org/metadata/08ced64cddc9f1578598b2cf71ae747b11d11472.xml

using SHA-1 and hex output.

For the same filesystem reasons, I think this transform approach would
also have to be used in a hypothetical local filesystem "folder of
metadata" approach that was dynamic, such as I mentioned on the last dev
call.  This would have the advantage of dynamically picking up new files
that were dropped into the directory while the system was running.

For the MDQ request builder, the same transform function can be used to
issue queries using the defined "{sha1}..." identifier format, if that
is desirable vs the original entityID for some reason (I did a specific
function that handles that case), or could do other transforms with the
entityID as the spec progresses.

Just thought I'd share.

--Brent


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20141031/6647a7ea/attachment.html