Metadata Changeover Questions

[McKean, Brandon Scott - mckeanbs]

> 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.
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.
I also have this line:
>   <ArtifactResolutionService
> Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https:/
> /itfederation.jmu.edu:8443/idp/profile/SAML2/SOAP/ArtifactResolution"
> index="2"/>
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.)
> 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?
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.
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.
Brandon
On Wed, 2015-07-22 at 16:39 +0200, Peter Schober wrote:
> * Cantor, Scott <cantor.2 at osu.edu> [2015-07-22 16:16]:
> > 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.
> 
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150722/a8ad6584/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5673 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20150722/a8ad6584/attachment.bin>