<html><head></head><body><blockquote type="cite"><div>I assumed the OP already had SAML2 support in metadata and was merely</div><div>considering removing SAML1 wholesale. Seems that's not the case (no</div><div>sign of SAML2 for JMU, in 2015), so I misunderstood the much wider</div><div>implications of that question than removing potentially unneeded SAML1</div><div>endpoints.</div></blockquote><div><br></div><div>Hmm, perhaps I don't fully understand the implications of the metadata myself. What I previously emailed was the current metadata, with the SAML2 elements there.</div><div><br></div><div>I also have this line:</div><blockquote type="cite"><div> <ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="<a href="https://itfederation.jmu.edu:8443/idp/profile/SAML2/SOAP/ArtifactResolution">https://itfederation.jmu.edu:8443/idp/profile/SAML2/SOAP/ArtifactResolution</a>" index="2"/></div></blockquote><div><br></div><div>Maybe there's more to it that I'm not seeing? I thought having all the SAML2 lines that I posted before indicated SAML2 support was there. for our side. (And when I've used Testshib in testing it, it appears to be using SAML2, I could only make it use SAML1 when modifying the metadata to remove SAML2 bits.)</div><div><br></div><blockquote type="cite"><div>For the InC community: If there still are SPs that default to SAML1</div><div>(even when both their SP and the IDPs announce SAML2 support) I'd</div><div>appreciate any attempts to put some pressure on such SPs to change to</div><div>SAML2.0.</div><div><br></div><div>From my experience most of the problematic SAML1-only or</div><div>defaulting-to-SAML1 SPs fall into the academic publishers</div><div>category. Some of those are able to change the settings per</div><div>tenant/customer/IDP if approached.</div><div>But maybe use of such SPs is bigger in the UK (and Europe and Japan)</div><div>than in the US?</div></blockquote><div><br></div><div>That's our hope. We've wanted to enforce more SAML2 support but I wasn't aware it was a bigger problem than just configuration on our side.</div><div><br></div><div>I couldn't say for certain how much they're used elsewhere, though I can say that I hadn't heard of any of it in my career in information technology prior to working in higher education.</div><div><br></div><div>Brandon</div><div><br></div><div>On Wed, 2015-07-22 at 16:39 +0200, Peter Schober wrote:</div><blockquote type="cite"><pre>* Cantor, Scott <<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>> [2015-07-22 16:16]:
<blockquote type="cite">
You should consider a minimal change to the metadata in InCommon
that adds a SAML 2 ArtifactResolutionService endpoint only, no SSO
service. That will cause the 2.0 protocolSupportEnumeration constant
to be added to the metadata but won't change any SP behavior. That
allows push testing of SAML 2 responses from your IdP to the SPs one
by one to verify attribute consumption.
</blockquote>
I assumed the OP already had SAML2 support in metadata and was merely
considering removing SAML1 wholesale. Seems that's not the case (no
sign of SAML2 for JMU, in 2015), so I misunderstood the much wider
implications of that question than removing potentially unneeded SAML1
endpoints.
For the InC community: If there still are SPs that default to SAML1
(even when both their SP and the IDPs announce SAML2 support) I'd
appreciate any attempts to put some pressure on such SPs to change to
SAML2.0.
From my experience most of the problematic SAML1-only or
defaulting-to-SAML1 SPs fall into the academic publishers
category. Some of those are able to change the settings per
tenant/customer/IDP if approached.
But maybe use of such SPs is bigger in the UK (and Europe and Japan)
than in the US?
-peter
</pre></blockquote><div><br></div></body></html>