Migration from SAML1 to SAML2 and InCommon

[Cantor, Scott]

On 2/28/13 4:14 PM, "Chris Peters" <cjpeters at uci.edu> wrote:

>We are currently running Shibboleth 2.x IDP as an upgrade from a 1.x
>version.  When we upgraded we didn't deploy the SAML 2 endpoints to
>InCommon as part of the upgrade process.  So, we're in the situation that
>our IDP supports and is configured for SAML2, but they just haven't been
>utilized by our SPs to this point. Now we're finding a lot of SPs want to
>use only SAML2 so we want to get those endpoints published and move into
>the SAML2 era.

Same.

>To complicate matters, almost all of our SPs use InCommon Metadata.  So,
>in order to update them we have to publish the endpoints and then wait
>for them to take hold and see if anyone has any problems.

Same.

>I was wondering if anyone has any advice how to approach this transition
>and if anyone had dealt with this specific issue in the past.

I can at least give you an idea of where I stand on it here. My chief
concern was that we had dozens of SPs around campus, many running
unpatched software. I was very reluctant to move to SAML 2.0 because the
signature wrapping issue < 2.4.3 affects only SAML 2-capable SPs, and
because our InCommon metadata was limiting them to our IdP only, and SAML
1.1 only, we were safe. So I made it a precondition to do a patching push
here first. We're still going on that, but I have tentatively set a
deadline and can now get our security people involved to push harder, and
we can assess risk now that most critical apps have patched.

My particular approach to this transition has been to migrate off of
InCommon as a source of metadata for our IdP on campus. I thought it made
sense back then, and it's not so much a bad idea as just lacking
flexibility and I'm happier hosting my own now. But the main thing is that
I can use that to gracefully migrate systems to SAML 2.0 as they get
patched and switch their metadata source. That means they decide when to
switch right now, and can test without my involvement. So that's been
good. Downside is all the stragglers, and that's when you have to take the
plunge at some point.

Leading us to...

>The technique described there was to deploy the non-SSO endpoints, and
>then test the operability by crafting an UnsolicitedSSO url for each SP.
>This would test most of the transaction, but not allow any SP to directly
>trigger the use of SAML2 communication.

Yeah. The trick (for InCommon members) is that InCommon will let you add
SAML 2 artifact lookup endpoints only. That triggers the addition of the
SAML 2 protocol string into your metadata, which gives you the behavior
you describe. That gives you the chance to do more testing on your end to
verify behavior with attribute mappings, etc.

(If this was a case where you were totally outside of a federation, then
you can essentially do the same thing of course, based on whatever the
source of metadata is.)

>  This seems like a good plan, though it still eventually results in us
>having to deploy the SSO endpoints cold turkey and hoping they
>work--though I can't really fathom what could go wrong at that point.

Well, plenty, but ultimately all you can do is ask people to test and when
they don't, they take the risk.

>Anyway, I just would like to gather any advice I can on the subject and
>any links to information on this subject would be appreciated as well.

I'd be happy to share notes or hear your thoughts on this, since we're at
the same point.

-- Scott