Shibboleth IdPv3 testing/deployment

[Curry, Warren]

+1 very nice…

From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Greg Haverkamp
Sent: Thursday, January 21, 2016 1:44 PM
To: Shib Users <users at shibboleth.net>
Subject: Shibboleth IdPv3 testing/deployment

We deployed IdPv3 on December 17, 2015.   I write mostly because what we did to test - and have others test - our IdPv3 implementation worked out well for us, and I figured maybe someone with similar infrastructure could benefit from it.

I made the decision fairly early, not unlike others I've spoken with, to proceed contrary to the documentation and Scott's recommendations at TechEx and to build configure IdPv3 from the ground up rather than migrate.  Historically, I just feel it's too easy to get stuck never moving away from the legacy configurations when upgrading that way.

We have roughly 200 internal SPs, of which 150 or so of those are owned by our central IT division and are enterprise applications. We made it incumbent upon the developers/owners to ensure that their applications worked with v3.  Working with those developers, we developed a fairly basic testing strategy: 1) Login to your application, and 2) Ensure you received all of the attributes you expected to receive.

In order to make this easier and somewhat more realistic, we turned to our F5 BigIP load balancers.  We already used an iRule ahead of our v2 IdPs to rewrite some Taleo URLs that otherwise caused us problems with v2.  We enhanced/rewrote this iRule to provide a cookie-based IdP selection mechanism.  Essentially, users were presented with a (static) list of available IdPs.  Selecting one of those IdPs set a session cookie.  Based on the presence and value of that cookie, the iRule routed users to the desired IdP.  In this way, the developers/owners could compare results side-by-side.  Along the way, we occasionally mixed in additional v3 servers with changes alongside those that others were testing.

We gave users 2 weeks.  One or two issues came up with NameIDs (we eradicated all "unspecified" formats during the upgrade) which we fixed.  SHA256 signing/encryption was the primary issue we saw.  Most of those came up during the testing window.  A few didn't test during the window.  (One failed to test and then didn't notify us even after discovering that things were broken.  He just informed users of his application to use the IdP selection page to change to v2.)

Obviously, this method works only if you have something ahead of the IdP dispatching requests.  We were looking for something better than /etc/hosts changes, as we've had poor luck with large numbers of users succeeding in using them.  And we were definitely looking for something other than our IdP operations staff (two of us) trying to test every application that uses Shibboleth, because we don't even have access to all applications.

If you're still gearing up for the move and have infrastructure like this at your disposal, maybe this idea will help.

Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160121/684a5c88/attachment.html>