Any "gotchas" to adding in SAML 2 support?

[Cantor, Scott]

On 7/5/12 7:11 PM, "Eric Goodman" <ericg at ucsc.edu> wrote:
>
>My question for the group is: are there any gotchas with doing this?

It depends who your partners are and their software limitations, but in
general one of the bigger issues is that if you have sites that have been
consuming that metadata to federate with you, they will experience an
instantaneous change if they're running Shibboleth, at least. If they've
never used SAML 2 before, they may be vulnerable to their own mistake. If
they leave SAML 2 enabled, but have no partners using it, the first one
that switches will trigger the failure when their software issues a SAML
2 request and their metadata doesn't give your IdP the ability to respond.

Another common problem can be attribute mapping errors.

One of the useful things to do is to enable SAML 2 support in the metadata
by adding an ArtifactResolutionService alone, but no 2.0 SSO endpoint.
That allows you to push 2.0 responses to SPs as a test, but doesn't cause
them to react and switch to sending you SAML 2 requests, so existing user
access is unaffected.

> After looking through the troubleshooting pages on the wiki, it seems
>like the most common mistake we could make is failing to update all of
>our relying party configs to support SAML2 before the SAML2 endpoints are
>published, but we're wondering if there are any other gotchas to look for
>on the IdP or SP before making the change.

I would suggest taking the opportunity to remove those kinds of relying
party exceptions, as they should not be needed in the vast majority of
cases.

But yes, that will certainly break things.

-- Scott