Metadata Changeover Questions

[Cantor, Scott]

On 7/22/15, 8:39 AM, "users on behalf of McKean, Brandon Scott - mckeanbs" <users-bounces at shibboleth.net on behalf of 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