HTTPResource and multiple Metadata Provider files

Fri Aug 19 18:09:23 EDT 2016

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

service.xml
-----------------------------
...
    <util:list id="shibboleth.MetadataResolverResources">
        <bean id="testFilterFile" class="net.shibboleth.ext.spring.resource.
FileBackedHTTPResource"
            c:client-ref="shibboleth.FileCachingHttpClient"
            c:url="http://sp-test.idm.ucsc.edu/metadata-test/
metadata-filter.xml"
            c:backingFile="/opt/app/shibboleth/shibboleth-idp/
conf/metadata-filter.xml"/>
        <value>%{idp.home}/conf/metadata-providers.xml</value>
        <value>%{idp.home}/system/conf/metadata-providers-system.xml</value>
    </util:list>
...

metadata-filter.xml (you have to pretend it's loading InCommon metadata)
------------------------------
<MetadataProvider id="ShibbolethMetadataRemote" xsi:type="
ChainingMetadataProvider"
    xmlns="urn:mace:shibboleth:2.0:metadata"
    xmlns:resource="urn:mace:shibboleth:2.0:resource"
    xmlns:security="urn:mace:shibboleth:2.0:security"
    xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="urn:mace:shibboleth:2.0:metadata
http://shibboleth.net/schema/idp/shibboleth-metadata.xsd
                        urn:mace:shibboleth:2.0:resource
http://shibboleth.net/schema/idp/shibboleth-resource.xsd
                        urn:mace:shibboleth:2.0:security
http://shibboleth.net/schema/idp/shibboleth-security.xsd
                        urn:oasis:names:tc:SAML:2.0:metadata
http://docs.oasis-open.org/security/saml/v2.0/saml-schema-metadata-2.0.xsd">

    <MetadataProvider id="IdmInternalTest"
                      xsi:type="FilesystemMetadataProvider"
                      metadataFile="/opt/app/shibboleth/shibboleth-idp/
metadata/idm-test-metadata.xml">

        <MetadataFilter xsi:type="Predicate" direction="include"
removeEmptyEntitiesDescriptors="true" trim="true">
          <Entity>https://sp-test.idm.ucsc.edu/shibboleth</Entity>
        </MetadataFilter>

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

    </MetadataProvider>
</MetadataProvider>

metadata-providers.xml (again pretend it's loading InCommon Metadata)
--------------------------------
<MetadataProvider id="ShibbolethMetadata" xsi:type="
ChainingMetadataProvider"
    xmlns="urn:mace:shibboleth:2.0:metadata"
    xmlns:resource="urn:mace:shibboleth:2.0:resource"
    xmlns:security="urn:mace:shibboleth:2.0:security"
    xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="urn:mace:shibboleth:2.0:metadata
http://shibboleth.net/schema/idp/shibboleth-metadata.xsd
                        urn:mace:shibboleth:2.0:resource
http://shibboleth.net/schema/idp/shibboleth-resource.xsd
                        urn:mace:shibboleth:2.0:security
http://shibboleth.net/schema/idp/shibboleth-security.xsd
                        urn:oasis:names:tc:SAML:2.0:metadata
http://docs.oasis-open.org/security/saml/v2.0/saml-schema-metadata-2.0.xsd">

    <MetadataProvider id="IdmInternalTest"
                      xsi:type="FilesystemMetadataProvider"
                      metadataFile="/opt/app/shibboleth/shibboleth-idp/
metadata/idm-test-metadata.xml"/>

</MetadataProvider>

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

> > so an example of an Metadatata attribute filter we want to use is:
>
> Yes, I assumed so. But that is *inside* a MetadataResolver. So you have a
> resolver, and you tell it where to get metadata from, e.g. InCommon. So it
> loads *all* that metadata, and then it runs the filter(s) you define inside
> the MetadataResolver.
>
> If you have multiple MetadataResolvers, I don't care where, one file,
> three, whatever, each of those resolvers is loading some set of metadata,
> and then applying filters to that metadata. There's no relationship
> *between* MetadataResolvers.
>
> At the very top level, you have a chain of resolvers, from across all the
> different configuration resources loaded into that service, usually just
> one (metadata-providers.xml), and that lets it search all the resolvers one
> at a time.
>
> I didn't *think* we specify an order across resources, but I'm looking at
> the code and now I see some kind of sortKey thing. So, bottom line, I don't
> know. I simply don't think it's a good idea. Duplicates are not a goal of
> this system, you don't want to load the same metadata twice.
>
> > 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>
>
> You keep referring to the filters as being "in files", but that's not how
> they work unless we implemented something I'm unaware of. They're in
> *resolvers* in files. The resolvers are what are loading the metadata, and
> then applying filters *within* that resolver's metadata.
>
> So I'm having trouble connecting what you're describing with the way it
> works. I don't see anything in the parsers that supports loading a filter
> from a separate Spring resource. Like we did in the attribute resolver with
> those springResourceRef hooks. I don't think those exist for metadata
> filters. Or I could be wrong.
>
> Within a given resolver, yes, if one filter throws out a ton of entities,
> the remaining filters don't have to go plowing through everything that was
> thrown out. But I'm not sure if that's what you're doing, because you were
> referencing separate files.
>
> > 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
>
> Within a single resolver, yes.
>
> > 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.
>
> Right, but the problem is that unless we did something I'm not familiar
> with, that "outside" agent needs to supply you with the *entire*
> MetadataResolver it wants you to use. There's no way to remotely reference
> a set of *filters* alone. Not that I know of.
>
> > 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.
>
> If you have two files containing MetadataResolvers, I don't think there is
> any guarantee as to the order they'll be checked, but now I don't know. If
> there is, ok. It certainly wouldn't be by accident, you would have to be
> using some kind of sort value to control it.
>
> > 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.
>
> Obviously with enough textual magic, you can manage anything, but I'm not
> aware of any supported features for piecemealing together a complete
> MetadataResolver with filters with bits of it coming from different places
> and resources. Not without writing code to do all the wiring up at runtime.
> Declaratively, I don't think our schema can do that, not that I can see.
>
> Probably it *could* be extended to. We have other places in the code where
> we injected references to arbitrary beans, and there's no inherent reason
> that can't be done with metadata filters, we just didn't have a use for it.
>
> It would really help to see what in the heck you're trying to load to
> answer anything specifically.
>
> -- 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/8f9ca99a/attachment-0001.html>