Question re: SP config to consume metadata

David Bantz dabantz at alaska.edu
Wed Apr 30 13:36:30 EDT 2014


For nearly all the service providers using our Shibb IdP we either rely directly on the InCommon metadata for metadata exchange, or swap metadata files out of band.  But two vendors I’m working with right now propose to obtain and automatically refresh our IdP metadata even though they are building specific service instances tied to our IdP (that is, a single identity provider for each of their customers).

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?

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.

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.  I suppose it could work if I agree to maintain an externally readable file of my IdP metadata.

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

David Bantz
U Alaska
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20140430/75df628e/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://shibboleth.net/pipermail/users/attachments/20140430/75df628e/attachment.bin 


More information about the users mailing list