Shibboleth IdPv3 testing/deployment

Greg Haverkamp gahaverkamp at lbl.gov
Thu Jan 21 13:44:03 EST 2016


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/69586925/attachment.html>


More information about the users mailing list