HTTPResource and multiple Metadata Provider files

[Jeffrey Crawford]

Well, in any case thanks for your input.

If you just happen to be curious enough and do find that there is some
order preserved in loading multiple MetadataProfider Chains, it would be
good to know

Thanks

Jeffrey E. Crawford
Enterprise Service Team <jeffreyc at ucsc.edu>

Both pilots and IT professionals require training and currency before
charging into clouds!
---------------------------------------

On Fri, Aug 19, 2016 at 3:23 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> > Although this is probably quickly becoming a moot point, I'm including
> the
> > config files that I'm working with for my test. basically these are only
> the last
> > two cases, download resolver with metadata attribute filters (the
> centrally
> > managed filter file), and the local metadata-providers.xml file has the
> same
> > metadata that is getting overridden by the first one. Just have to
> pretend
> > "idm-test-metadata.xml", is the InCommon metadata
>
> Right, and in that setup, you're loading the InCommon metadata twice, and
> the filters are applied to *one* instance of that data.
>
> For the sake of argument, let's assume there's a predictable order (I
> really have no idea).
>
> I see that it would work if your goal would be to chop out all the
> "untagged" stuff andjust apply tags to some set of SPs in one of the
> resolvers. Then any requests would hit those first, and if not, fall into
> the "untagged" resolver and find the missing stuff there.
>
> But it only handles the case where the tagging is all happening in one of
> the resolvers (it couldn't combine tags across resolvers), and it *is*
> loading all the metadata twice before one of the two drops a bunch of it
> out. And it would be reloading all of it in two threads.
>
> What you need is a single file containing an InCommon resolver, and then
> some set of filters in it, but in the middle of it, something like this:
>
> <MetadataFilter type="Spring" ref="BeanName" />
>
> And then somewhere there'd be a raw Spring bean wired up for a
> MetadataFIlter of some sort standing alone, ready to be injected into that
> filter chain, and limiting the amount of wiring needed (and probably that
> would be the remotely supplied bean, so the nasty Spring wiring work is
> somebody else's job to get right).
>
> Security aside, anyway. The only way to do that with an HTTPResource
> securely is TLS, with a custom trust configuration to verify the server
> cert.
>
> I don't think we have any practical way to start allowing for top-level
> MetadataFilter objects to be reused or referenced across the resolvers and
> avoid any Spring wiring, but it might be possible, not sure.
>
> -- Scott
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160819/e9c17491/attachment.html>