HTTPResource and multiple Metadata Provider files

[Jeffrey Crawford]

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 12:39 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> > We are looking at doing something kinda similar to what Keith Wessel does
> > with HTTPResource and attribute filters, but using metadata providers and
> > metadata attribute filters instead (We found it to be more flexible)
>
> 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.
>
> > We want to load InCommon metadata using various filters in the following
> > order:
> >
> > metadata-providers-local-override.xml
> > metadata-providers-remote-uc-approved.xml
> > metadata-providers.xml
>
> 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.
>

​so an example of an Metadatata attribute filter we want to use is:
        <MetadataFilter xsi:type="EntityAttributes">
            <saml:Attribute Name="urn:mace:ucsc.edu:metadata:attr:profile">
                <saml:AttributeValue>urn:mace:ucsc.edu:
metadata:attr:profile:app:idm-test-sp</saml:AttributeValue>
            </saml:Attribute>
            <Entity>https://sp-test.idm.ucsc.edu/shibboleth</Entity>
        </MetadataFilter>

we then have attribute-filter.xml rules that process the attribute value
​"urn:mace:ucsc.edu:metadata:attr:profile:app:idm-test-sp"

>
> > The first two files would need to whitelist the entities in which we
> want to
> > add additional attributes, so we don't load the entire InCommon metadata
> > three times.
>
> Basically, you *are* loading the metadata three times unless I'm not
> following you. And you don't want that, so...
>

​Even if the first filter in each file has something like:
        <MetadataFilter xsi:type="Predicate" direction="include"
removeEmptyEntitiesDescriptors="true" trim="true">
          <Entity>https://sp-test.idm.ucsc.edu/shibboleth</Entity>
        </MetadataFilter>

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

>
> > But the last one would be the fall through that loads metadata in
> > it's entirety. I'm finding that which ever file lists the metadata first
> will have
> > it's attributes or lack of attributes as the metadata descriptor entry.
> Is this
> > expected behavior?
>
> 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.
>

​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.​

​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.​

>
> But again, this is about resolvers, NOT filters. Filters run inside a
> resolver, never at the "top" across all resolvers.
>
> > Also is the HTTPResource only available in IDP30?
>
> 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.
>

​Okay, not sure what to do about that one, I guess a cron'd curl script
could do something similar.​


>
> I realize many federations do this, and it remains, IMHO, a really bad
> idea.
>

​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.​

​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.

>
> -- 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/832c50de/attachment-0001.html>