<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div><br>
</div>
<div><br>
</div>
<blockquote type="cite">
<div>(Don't forget about the protocolSupportEnumeration attribute on the</div>
<div>IDPSSODescriptor element.)</div>
</blockquote>
<div><br>
</div>
<div>Good catch, thanks!</div>
<div><br>
</div>
<blockquote type="cite">
<div>Giving SPs metadata w/o any traces of SAML1 in it is certainly</div>
<div>possible. Whether that's /advisable/ in any given deployment is a very</div>
<div>different question. I'd at least look at the logs (as far back as you</div>
<div>care) whether all services you need to support are actively being used</div>
<div>over SAML2. (Presence of SAML2 support in SP's metadata does not mean</div>
<div>you can be certain it's also used.)</div>
<div>The IDP log analyzer I wrote ages ago might be of help for this:</div>
<div><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_display_SHIB2_IdP-2BAudit-2BLog-2BAnalysis-2BTool&d=BQICAg&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=iZ_ekq9_90q96juMacb0Sg&m=HASRktjo370-yjHlVXkCdJqrP1bK-_AKXVdUWnm8_lQ&s=5P-OXbPdAvOxeeJlme_olMQ42y7-CyZIHzzAH6FRIw4&e=">https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_display_SHIB2_IdP-2BAudit-2BLog-2BAnalysis-2BTool&d=BQICAg&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=iZ_ekq9_90q96juMacb0Sg&m=HASRktjo370-yjHlVXkCdJqrP1bK-_AKXVdUWnm8_lQ&s=5P-OXbPdAvOxeeJlme_olMQ42y7-CyZIHzzAH6FRIw4&e=</a>
</div>
<div>Option "--msgprofiles"</div>
</blockquote>
<div><br>
</div>
<div>Hmm, well we plan to start contacting SPs to see what attributes they need released as part of an effort to drop anonymous attribute release, so perhaps making sure they support SAML2 is a good idea to do at that point.</div>
<div><br>
</div>
<div>That said, I think InCommon's current policies mandate SAML2 support, so we may well be good on that front. (Most SPs we correspond with are members of InCommon, very select few aren't.)</div>
<div><br>
</div>
<div><a href="https://www.incommon.org/docs/guides/InCommon_Resources.pdf">https://www.incommon.org/docs/guides/InCommon_Resources.pdf</a></div>
<div><br>
</div>
<div>Not sure if any other InCommon affiliates can verify this?</div>
<div><br>
</div>
<div>Thanks for that info on the tool, I'll grab a copy of it for my toolset.</div>
<div><br>
</div>
<blockquote type="cite">
<div>Ignoring broken SPs that will unconditionally send</div>
<div>"Shibboleth"-protocol SAML1 requests, even if you don't announce any</div>
<div>suppport/endpoints for SAML1 in metadata (something to consider -- you</div>
<div>may not be able to actually ignore those!), that would break all SPs</div>
<div>that need SAML1 to work.</div>
<div>With the proposed strategy you'd only keep those SAML1-only systems</div>
<div>working that do /not/ use SAML metadata to determine run-time</div>
<div>behaviour, breaking others.</div>
<div><br>
</div>
<div>It will certainly be interesting to see what breaks if you remove</div>
<div>SAML1 support from metadata, though. That's not a safe deployment</div>
<div>stagegy, of course.</div>
</blockquote>
<div><br>
</div>
<div>Hmm, that certainly complicates things... I would think being InCommon affiliates would mean they have to support SAML2, but I suppose that has nothing to do with software at the other end when InCommon is moreso about what's in the metadata.</div>
<div><br>
</div>
<div>Thanks for these tips. I'll try seeing if new SPs can handle just SAML2 with those changes. If so those should be good, but I'll have to reconsider how the remaining transition goes.</div>
<div><br>
</div>
<div>Thanks much,</div>
<div><br>
</div>
<div><br class="Apple-interchange-newline">
<span style="font-family: monospace; white-space: pre;">-- Brandon McKean IT / Systems Linux Administrator (540)568-4235</span></div>
<div><br>
</div>
<div>On Wed, 2015-07-22 at 15:03 +0200, Peter Schober wrote:</div>
<blockquote type="cite">
<pre>* McKean, Brandon Scott - mckeanbs <<a href="mailto:mckeanbs@jmu.edu">mckeanbs@jmu.edu</a>> [2015-07-22 14:40]:
<blockquote type="cite">
I've been looking at adding new SPs to our existing IDP, but also
transitioning away from SAML 1 in favor of SAML 2 as best we can. To
this end, I'm suspecting I could give new SPs a copy of our metadata
that has SAML1 elements removed in order to achieve a transition.
</blockquote>
(Don't forget about the protocolSupportEnumeration attribute on the
IDPSSODescriptor element.)
Giving SPs metadata w/o any traces of SAML1 in it is certainly
possible. Whether that's /advisable/ in any given deployment is a very
different question. I'd at least look at the logs (as far back as you
care) whether all services you need to support are actively being used
over SAML2. (Presence of SAML2 support in SP's metadata does not mean
you can be certain it's also used.)
The IDP log analyzer I wrote ages ago might be of help for this:
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_display_SHIB2_IdP-2BAudit-2BLog-2BAnalysis-2BTool&d=BQICAg&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=iZ_ekq9_90q96juMacb0Sg&m=HASRktjo370-yjHlVXkCdJqrP1bK-_AKXVdUWnm8_lQ&s=5P-OXbPdAvOxeeJlme_olMQ42y7-CyZIHzzAH6FRIw4&e=">https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_display_SHIB2_IdP-2BAudit-2BLog-2BAnalysis-2BTool&d=BQICAg&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=iZ_ekq9_90q96juMacb0Sg&m=HASRktjo370-yjHlVXkCdJqrP1bK-_AKXVdUWnm8_lQ&s=5P-OXbPdAvOxeeJlme_olMQ42y7-CyZIHzzAH6FRIw4&e=</a>
Option "--msgprofiles".
<blockquote type="cite">
Am I on the right track with this? What I'd want to do is supply the
modified metadata to new SPs so that we have one less thing to worry
about transitioning, and supply it to InCommon so that we could, in
theory at least, have a fairly seamless transition since the IDP still
technically supports SAML1, but would only be advertising SAML2 in
metadata.
</blockquote>
Ignoring broken SPs that will unconditionally send
"Shibboleth"-protocol SAML1 requests, even if you don't announce any
suppport/endpoints for SAML1 in metadata (something to consider -- you
may not be able to actually ignore those!), that would break all SPs
that need SAML1 to work.
With the proposed strategy you'd only keep those SAML1-only systems
working that do /not/ use SAML metadata to determine run-time
behaviour, breaking others.
It will certainly be interesting to see what breaks if you remove
SAML1 support from metadata, though. That's not a safe deployment
stagegy, of course.
-peter
</pre>
</blockquote>
</body>
</html>