Metadata Changeover Questions

Wed Jul 22 10:38:58 EDT 2015

Hmm, so essentially there isn't really a safe way to do it across the board without disruption? I wasn't aware that SAML1 was that extensively required still.

If that's the case I'll regroup with our team to discuss our plans. For now it seems like it'd be better to ensure all SPs explicitly support it before trying that cutover, and to only give newly onboarded SPs outside of InCommon the modified metadata.

Just to make sure I understand correctly, some SPs/software literally just apply selective listening of sorts when it comes to metadata? I'd view that as a major implementation issue on their part, though I'm sure I'm preaching to the choir on that front.

Thanks,

Brandon

On Wed, 2015-07-22 at 14:15 +0000, Cantor, Scott wrote:

On 7/22/15, 8:39 AM, "users on behalf of McKean, Brandon Scott - mckeanbs" <users-bounces at shibboleth.net<mailto:users-bounces at shibboleth.net> on behalf of mckeanbs at jmu.edu<mailto:mckeanbs at jmu.edu>> wrote:

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.

You really don't want to do this without a ton of up front testing and verification.

There are a ton of variables involving the SP software, how discovery's being done, how attributes are being handled at the other end, etc.

(The least of concerns here are all the cases where metadata's not being used, since obviously you won't break any of those by changing your metadata, but eventually they have to be dealt with.)

When I transitioned here, I did it after upgrading the IdP to 2.x and spent about 2 years effecting a transition. And I still have some SAML 1 SPs. It's a huge undertaking unless you're willing to break and fix.

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.

You will find breakage when you do that, and will likely have to reach out to some of them. Particularly SimpleSAML SPs, which are frequently (in my experience as a customer) misconfigured to support only one set of attribute mappings.

Even if things work, you may well not see them switch to SAML 2 just because you complete the metadata change, due to discovery and hardwired behavior, so there's still follow up needed at times.

-- Scott

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150722/22ecd481/attachment-0001.html>