v3 Tests failing

[Brent Putman]

On 4/8/16 11:09 AM, Cantor, Scott wrote:
>> Perhaps this is off-topic but will the dynamic metadata query (MDQ)
>> feature work against a base URL with scheme file:// (as opposed to
>> http:// or https://)?
> Don't know about the IdP, but I doubt the SP would (not to say it couldn't be made to). In fact, that's a really elegant way of implementing a "drop into a folder" model. 
>


For Java OpenSAML/IdP:  No, it doesn't currently do that, the concrete
dynamic class is HTTP only.  Note that the IdP config schema reflects
that, the type is "DynamicHTTPMetadataProvider".  So a filesystem-based
one would need to be a different config (and concrete resolver class)
anyway.

However, the dynamic resolver abstract base classes were deliberately
written such that implementing "dynamic" behavior for something other
than HTTP resources would be easy.  I had already mentioned elsewhere,
maybe dev list, that using this to implement a filesystem dynamic
resolver with the "drop into a folder" model would be pretty easy.

The main implementation issue that I know of is file naming.  Typical
entityIDs (certainly all URLs, some URNs) aren't amenable to directly
use as file names (depending on the operating system).  I.e. you can't
literally have "https://sp.examle.org/shibboleth.xml", at least on
Unix/Linux.  So you have to decide on a strategy about how to convert
the entityID to a string that will be used as the filename.  An obvious
one that's sure to always work would be a hex encoding of some
digest/hash of the entityID. (I think openssl supports something
similar for certs in a directory).  A better one would be something
that still leaves it relatively human-readable.


> Could you file that?

Also against IDP and/or OSJ.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160408/ca204b45/attachment.html>