Question re: SP config to consume metadata

[Tom Scavo]

On Wed, Apr 30, 2014 at 1:36 PM, David Bantz <dabantz at alaska.edu> wrote:
>
> One of these vendors has configured the SP to consume/refresh InCommon
> metadata, following the example SP configuration in shibboleth2.xml:
>        <MetadataProvider type="XML"
> uri="http://md.incommon.org/InCommon/InCommon-metadata.xml"
>               backingFilePath="federation-metadata.xml"
> reloadInterval="7200">
>             <MetadataFilter type="RequireValidUntil"
> maxValidityInterval="2419200"/>
>             <MetadataFilter type="Signature" certificate="incommon.pem"/>
>         </MetadataProvider>
> This has the obvious advantage over point to point exchange that updates to
> our metadata will be automatically consumed, but seems a little extravagant
> since only a single entity’s metadata is needed.
>
> 1)  How could we add a MetadataFilter to consume only our IdP’s metadata and
> avoid storing and processing the entire largish InC metadata file?

Something like this (untested):

<MetadataFilter type="Whitelist">
    <Include>your_idp_entityID_here</Include>
</MetadataFilter>

See:
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPMetadataFilter#NativeSPMetadataFilter-WhitelistMetadataFilter

> 2) Is this a reasonable approach for a non-InC service provider?  I
> suggested the alternative of joining InC, but the vendor isn’t interested in
> putting their SP metadata in InC even though they want to use InC to get my
> IdP metadata.

Sure, it's a reasonable approach, I suppose.

> The second vendor wants to use a similar SP config, but point the uri to
> instance of my metadata only (not the InC metadata provider).  They
> attempted to set this up with my entityID as the uri, but it’s a name, not a
> url, so I can’t see how that could work.

What if InC were to provide a URL to your IdP entity descriptor (and
only your IdP)? It would be signed by the same key that signs the
production InC aggregate.

We don't have this yet but we've been given a mandate, which is why I
bring it up:

https://spaces.internet2.edu/x/F4G8Ag

Not sure when this will get done but I wanted to let you know.

> I suppose it could work if I agree
> to maintain an externally readable file of my IdP metadata.

I wouldn't do that.

> 3) Is this a reasonable approach on the part of the service provider?

Sure, but what about the other half of the metadata exchange process?

Tom