IdP metadata management for non-federated SPs?

[David Gersic]

I've been running an IdP here (Shibboleth v2) for a few years now. I know, I need to get to v3, that's not currently at the top of the list of things I need to do today.


Right now, we have no on-campus SPs. We are InCommon members, and as new "cloud" services have come along, management have been strongly encouraging the various people contracting for those services to integrate with Shibboleth. Some of the SPs are InCommon members, so are easy. Others are not, but are familiar with SAML2 and Shibboleth. Some haven't a clue what it means, but maybe they heard about SAML once, somewhere. I'm assuming that none of this is new to anybody reading this.


Right now, I have six or so of the "we've heard of SAML2, here's our SPs metadata" vendors. That's small enough to be managable, but I can see that this could easily grow to be a pain. What I'm doing for these is:


1. Add vendor-metadata.xml to the ../metadata directory.

2. Edit ../conf/relying-party.xml to add the metadata source.

3. Edit ../conf/attribute-resolver.xml if needed because the service has some new variation on what they need, mostly something to do with NameID where they can't possibly use something sane that's already in place.

4. Edit ../conf/attribute-filter.xml if needed, mostly because the new version of NameID from #3 has to be released to this SP.


Then, of course, I have to bounce the Shibboleth service to get it to read the updated files. For a couple of SPs, this isn't too bad. But before this grows out of hand, I'm looking at it and thinking that there has to be a better way.


Assuming that getting these service providers to join InCommon is just not going to happen, it seems like I should be able to deal with this through a similar model. I don't need to bounce the IdP every time InCommon adds a new SP. That would be crazy. But can I do something similar to what InCommon does, to make these singular SPs easier for me to deal with?


Looking at the InCommon metadata aggregate, it looks like it's basically the <EntitiesDescriptor> section, containing a bunch of stuff that is important for the federation, security, etc.. Then there's a whole bunch of <EntityDescriptor> sections, which describe the IdPs and SPs of the members. If I look at the metadata provided by these isolated SPs, they're just a <EntityDescriptor> with some stuff in it, so that looks familiar.


So is the solution simply to build my own little metadata aggregation service? Is there any reason I can't make my own <EntitiesDescriptor> to describe my "NIU federation of isolated services" service, add in a bunch of <EntityDescriptor> from the services, and close it off with an </EntitiesDescriptor> to be done with it? Taking this further, I could then put a bunch of these metadata files in to something (Git, SVN, whatever), script a compilation of the available metadata files in to a single "NIU federation" metadata aggregate, and define this in the relying-party.xml to same way I defined InCommon, so it updates itself and the only step needed to on-board a new non-federated SP is to drop its metadata in to [Git | SVN | whatever].


Is it really that simple, or am I missing something obvious here? I don't yet know how to better deal with each of these services wanting some special variation of NameID, but maybe I'll eventually define every possible variation of NameID, nameid-format, etc. to the point where that problem is solved by exhaustion.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160204/8c3a4e42/attachment.html>