<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">To the extent that your vendors are standing up local instances for your sole use (i.e., the entity ID is only used by your IdP, and not shared with others),
you can also consider registering the SP directly in the InCommon aggregate.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">We have done this for quite a few vendors that weren’t (and weren’t willing to) become InCommon members. If the operation of the application (or at least the
part behind the entityID you are registering) is done under contract or agreement with you, it is essentially “your” SP and you have the right to register it, so long as the operation is consistent with InCommon’s POP and other requirements.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Of course, this approach only solves the really simple problem of where you put the metadata/relying party information (you don’t need separate files or merge
processes!) It doesn’t help with automating population of the data into the InCommon Fed Manager. For UC, it’s frequently a useful approach because we have 10-13 IdPs that will connect to the same SP, so registering it once manually in the Fed Manager is easier
than us emailing around the metadata (or worse, the raw configuration information in essay form) to all of the campus IdP operators and having them each independently solve the problem you describe.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">--- Eric<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> users [mailto:users-bounces@shibboleth.net]
<b>On Behalf Of </b>David Gersic<br>
<b>Sent:</b> Thursday, February 04, 2016 12:15 PM<br>
<b>To:</b> 'users@shibboleth.net'<br>
<b>Subject:</b> IdP metadata management for non-federated SPs?<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div id="divtagdefaultwrapper">
<p style="background:white"><span style="font-family:"Calibri","sans-serif";color:black">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.<o:p></o:p></span></p>
<p style="background:white"><span style="font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
<p style="background:white"><span style="font-family:"Calibri","sans-serif";color:black">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.<o:p></o:p></span></p>
<p style="background:white"><span style="font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
<p style="background:white"><span style="font-family:"Calibri","sans-serif";color:black">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:<o:p></o:p></span></p>
<p style="background:white"><span style="font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
<p style="background:white"><span style="font-family:"Calibri","sans-serif";color:black">1. Add vendor-metadata.xml to the ../metadata directory.<o:p></o:p></span></p>
<p style="background:white"><span style="font-family:"Calibri","sans-serif";color:black">2. Edit ../conf/relying-party.xml to add the metadata source.<o:p></o:p></span></p>
<p style="background:white"><span style="font-family:"Calibri","sans-serif";color:black">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.<o:p></o:p></span></p>
<p style="background:white"><span style="font-family:"Calibri","sans-serif";color:black">4. Edit ../conf/attribute-filter.xml if needed, mostly because the new version of NameID from #3 has to be released to this SP.<o:p></o:p></span></p>
<p style="background:white"><span style="font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
<p style="background:white"><span style="font-family:"Calibri","sans-serif";color:black">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.<o:p></o:p></span></p>
<p style="background:white"><span style="font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
<p style="background:white"><span style="font-family:"Calibri","sans-serif";color:black">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?<o:p></o:p></span></p>
<p style="background:white"><span style="font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
<p style="background:white"><span style="font-family:"Calibri","sans-serif";color:black">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.<o:p></o:p></span></p>
<p style="background:white"><span style="font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
<p style="background:white"><span style="font-family:"Calibri","sans-serif";color:black">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].<o:p></o:p></span></p>
<p style="background:white"><span style="font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
<p style="background:white"><span style="font-family:"Calibri","sans-serif";color:black">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.<o:p></o:p></span></p>
<p style="background:white"><span style="font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
<p style="background:white"><span style="font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
</div>
</div>
</body>
</html>