<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace">Well, in any case thanks for your input.<br><br>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<br><br></div><div class="gmail_default" style="font-family:courier new,monospace">Thanks<br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><font face="courier new, monospace">Jeffrey E. Crawford<br>Enterprise Service Team<a href="mailto:jeffreyc@ucsc.edu" target="_blank"></a></font><div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">Both pilots and IT professionals require training and currency before charging into clouds!<br></font></div><div><font face="courier new, monospace">---------------------------------------</font></div></div></div></div></div></div>
<br><div class="gmail_quote">On Fri, Aug 19, 2016 at 3:23 PM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Although this is probably quickly becoming a moot point, I'm including the<br>
> config files that I'm working with for my test. basically these are only the last<br>
> two cases, download resolver with metadata attribute filters (the centrally<br>
> managed filter file), and the local metadata-providers.xml file has the same<br>
> metadata that is getting overridden by the first one. Just have to pretend<br>
> "idm-test-metadata.xml", is the InCommon metadata<br>
<br>
</span>Right, and in that setup, you're loading the InCommon metadata twice, and the filters are applied to *one* instance of that data.<br>
<br>
For the sake of argument, let's assume there's a predictable order (I really have no idea).<br>
<br>
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.<br>
<br>
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.<br>
<br>
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:<br>
<br>
<MetadataFilter type="Spring" ref="BeanName" /><br>
<br>
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).<br>
<br>
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.<br>
<br>
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.<br>
<div class="HOEnZb"><div class="h5"><br>
-- Scott<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.<wbr>net</a><br>
</div></div></blockquote></div><br></div>