Why upgrade to Shibboleth Identity Provider (IdP) version 3.4.x?

Mike Grady , Software Architect , May 7, 2019

shibboleth logoThe latest release of the Shibboleth IdP is 3.4.4. The first 3.4 release of the Shibboleth IdP was in October 2018, over six months ago. If you have not already upgraded to 3.4.x, here are a variety of reasons why you really should do so.

First and foremost, only the latest release of the Shibboleth IdP is ever considered to be supported by the Shibboleth Consortium and its core Shibboleth development team. Given that the Shibboleth IdP is a key piece of the security infrastructure of your institution/organization, you really do want to keep your IdP current.

Second, 3.4 offers several new features that many will find highly useful. The biggest is its support for "metadata-driven configuration." You might ask, "What does that mean, exactly?" and "Hasn't the IdP always relied on SAML metadata?" What it means is that now almost all of the special settings you have needed to make in the past in order to integrate with a specific service (relying party) and all the things that you would need to configure per SP entityID in the IdP's relying-party.xml file can now be handled by adding specially-crafted metadata "tags" (entity attributes) into the metadata for a given SP instead. Even attribute release can be managed this way. No need to modify the relying-party.xml (or attribute-filter.xml) file. Now, while this sounds like it might be tricky to do, the key is that with the new Shibboleth IdP UI that has been developed, you have an easy-to-use tool to do just that. Adding new SP (relying party) integrations that would require editing multiple IdP configuration files can be handled without needing to hand edit any IdP config files.

So, upgrading to 3.4 sets you up to explore the use of the Shibboleth IdP UI, and minimize the hand-editing of config files you need to do after you get your IdP deployed. This can be a big win for Shibboleth IdP deployments, lowering the risk of making changes and the level of XML expertise needed to manage the Shibboleth IdP.

Other new features you might also want to look at include support for using Duo for non-browser (i.e. ECP) interactions, some simple "user impersonation" features for testing/support, and an easier way to make the "firing" of attribute definitions in the attribute-resolver.xml file be
dependent on a given SP entityID.

A third key reason to upgrade to 3.4 is in preparation for the next major release of the IdP, version 4.0. While that is still a little way off, there are already a number of ways of configuring things in version 3.x, particularly in the attribute resolver file, which we know will be done just a bit differently in version 4.0. What the 3.4 release does to help you start planning for the future is to add a number of "deprecation warnings" to the IdP logs that highlight what you will need to change. And the new syntax is already supported, so you can start updating your configuration sooner rather than later, minimizing the work to upgrade to version 4.0 when it does become available.

As you can see, upgrading to IdP 3.4.x offers a number of advantages, and keeps you fully current. It’s an upgrade that you really do want to make.

Mike Grady photo

Mike Grady

Software Architect

Mike Grady has expertise in a broad range of IT, with deep knowledge specifically in higher education IT, identity management, and research cyberinfrastructure. Since joining Unicon in 2012, Mike has focused on Identity and Access Management (IAM). He assists clients with a broad range of IAM needs, including strategy and assessment, consulting, implementation, and support. He has been involved with InCommon and Internet2 for years, and is currently a member of the InCommon Technical Advisory Committee. Prior to joining Unicon, he worked in academic IT at the University of Illinois at Urbana-Champaign for 36 years in a variety of roles. In total, Mike has spent 44+ years working in IT.