<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace"><br></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 12:39 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">> We are looking at doing something kinda similar to what Keith Wessel does<br>
> with HTTPResource and attribute filters, but using metadata providers and<br>
> metadata attribute filters instead (We found it to be more flexible)<br>
<br>
</span>Do you mean an entity attribute filter? And that isn't something you load remotely by itself, only resolvers can really be configured. Filters are attached to resolvers.<br>
<span class=""><br>
> We want to load InCommon metadata using various filters in the following<br>
> order:<br>
><br>
> metadata-providers-local-<wbr>override.xml<br>
> metadata-providers-remote-uc-<wbr>approved.xml<br>
> metadata-providers.xml<br>
<br>
</span>I don't understand the reference to filters. There isn't any way to load filters indirectly, is there? Maybe that was something we did to support referencing a Spring bean as a filter? You could supply additional resources to the MetadataResolver service's config set, but those would contain actual MetadataResolvers, not filters. Filters are attached to resolvers, basically, so they're "inside" the thing you'd be loading with those resources.<br></blockquote><div><br><div class="gmail_default" style="font-family:courier new,monospace;display:inline">so an example of an Metadatata attribute filter we want to use is:<br> <MetadataFilter xsi:type="EntityAttributes"><br> <saml:Attribute Name="urn:mace:ucsc.edu:metadata:attr:profile"><br> <saml:AttributeValue>urn:mace:ucsc.edu:metadata:attr:profile:app:idm-test-sp</saml:AttributeValue><br> </saml:Attribute><br> <Entity><a href="https://sp-test.idm.ucsc.edu/shibboleth">https://sp-test.idm.ucsc.edu/shibboleth</a></Entity><br> </MetadataFilter><br><br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">we then have attribute-filter.xml rules that process the attribute value "urn:mace:ucsc.edu:metadata:attr:profile:app:idm-test-sp"</div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class=""><br>
> The first two files would need to whitelist the entities in which we want to<br>
> add additional attributes, so we don't load the entire InCommon metadata<br>
> three times.<br>
<br>
</span>Basically, you *are* loading the metadata three times unless I'm not following you. And you don't want that, so...<br></blockquote><div><br><div class="gmail_default" style="font-family:courier new,monospace;display:inline">Even if the first filter in each file has something like:<br> <MetadataFilter xsi:type="Predicate" direction="include" removeEmptyEntitiesDescriptors="true" trim="true"><br> <Entity><a href="https://sp-test.idm.ucsc.edu/shibboleth">https://sp-test.idm.ucsc.edu/shibboleth</a></Entity><br> </MetadataFilter><br><br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">I know it has to load the file, but then I thought it throws away all the entities that are not in the <Entity> lists<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class=""><br>
> But the last one would be the fall through that loads metadata in<br>
> it's entirety. I'm finding that which ever file lists the metadata first will have<br>
> it's attributes or lack of attributes as the metadata descriptor entry. Is this<br>
> expected behavior?<br>
<br>
</span>Duplicate entities across metadata sources are resolved in order in which the resolvers appear, but I don't know what happens if you supply multiple files, that would potentially be a mess. In general, I think you can only safely count on the order within a single resource's MetadataResolvers. So you could hijack metadata for an entity from InCommon's feed with a local feed, but that's about as far as I would go with it.<br></blockquote><div><br><div class="gmail_default" style="font-family:courier new,monospace;display:inline">Okay but the idea is that someone outside of our local university wants to be able to make decisions on our behalf for "some" entities about what's being requested/released, However it's still up to the institution to decide what the requested population means.</div> <div class="gmail_default" style="font-family:courier new,monospace;display:inline">However I'm hearing you say about the order. It seems to be working the way I described now but you are saying that's just by chance.</div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
But again, this is about resolvers, NOT filters. Filters run inside a resolver, never at the "top" across all resolvers.<br>
<span class=""><br>
> Also is the HTTPResource only available in IDP30?<br>
<br>
</span>It was possible, and constantly unreliable, to load HTTP resources into V2 services. I don't think it's substantially more reliable now. I wouldn't do it, and there's no security on it anyway. I would do it out of band, and rsync them over as files.<br></blockquote><div><br><div class="gmail_default" style="font-family:courier new,monospace;display:inline">Okay, not sure what to do about that one, I guess a cron'd curl script could do something similar.</div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I realize many federations do this, and it remains, IMHO, a really bad idea.<br></blockquote><div><br><div class="gmail_default" style="font-family:courier new,monospace;display:inline">Okay, so an alternate thought we have one metadata-providers.xml file and we have a process that "sed"'s a list of Metadata filters that add attributes inline, where the list of filters comes from somewhere else.</div> <div class="gmail_default" style="font-family:courier new,monospace;display:inline">the only problem is if that metadata filter is ever incomplete it could break the entire metadata-providers.xml config, having separate files just breaks that feature set.<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class=""><font color="#888888"><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>
</font></span></blockquote></div><br></div></div>