SSO Support for Busy IT Admins 5 — Managing Integrations

So, that’s it… you’ve been given the weighty responsibility of SSO support for your organization. Or perhaps you’re new to the IAM team. Now what?

This post is the last in five-part series on the Fundamentals of SSO Support for IT Administrators.† You can see our first post here, our second post here, our third post here, and our fourth post here.

Keeping Integrations in Order

The primary purpose for a Single Sign On environment is to central authentication, and make things simpler for your users. However, one of the items that seems to plague busy academic and enterprise environments is a highly disorganized and disjointed SSO configuration. Here are some tips for keeping your SSO integrations in order, so that it’s easier to managing being the SSO Support “guy”.

Centralize as much as possible.

Many times we see orgs that are using some combination of Shibboleth, CAS, ADFS, and OAuth all at the same time, often with different administrators for each vying for the role of being the “SSO Support Principal”. With certain exceptions, you should reduce the number of deployed SSO solutions within your org’s ecosystem to as few as possible… for example:

Shibboleth and ADFS are both primarily SAML-speaking IdP packages. Do you really need both? Did you know that you can delegate Shibboleth authentication to ADFS? Did you know that you can delegate ADFS authentication to Shibboleth?
CAS works with a proprietary protocol… but Shibboleth IdP “speaks” that protocol. Ditch CAS and get Shib!
But hey… CAS also “speaks” SAML… Ditch Shib and get CAS!
Shibboleth, CAS, and ADFS all support OIDC to one degree or another, whether with native support or third-party plugins.

Mischief Configurations Managed

Configurations get out of sort, and quickly, when:

more than one person edits/adds integrations to the server, or
you fail to follow a standard operating procedure.

To that end, we strongly mention having a formal procedure in place (and documented, see below) for when an integration is built.

This doesn’t necessarily mean that you have to use git to manage configuration files and build a review process with PRs and commits to the production repo – not that that’s a bad idea 😉 – but what it does mean is that you follow simple things like:

Ensure that configuration file changes are commented, with an indication of who made the change, why they made it, and when. (For example, when I’m working in an IdP config file and I make a change on a users behalf I like to comment with things like:

Make a copy of all configuration files before you make changes, and make sure they’re dated… I can’t tell you how many times I’ve seen “relying-party.xml”, “relying-party.xml.bak”, “relying-party.xml.bak2”, and “relying-party.xml.broken” all in the same config directory. Without context in the files, they’re useless.
Don’t be afraid of deleting extra files that come with the software packages that aren’t needed after an initial deployment… I’m looking at you and your .dist files Shibboleth.

Documentation Prevents Problems

Do you have a single, centralized list of all of your SP integrations? Does that list come along with contact info for both the local responsible party as well as the vendor? Do you have metadata and/or testing URLs readily available?

Do you have a document that you provide to integration partners that specifies what information that you expect them to provide? Don’t be afraid to be a bit demanding here. SSO is difficult. You’ll help the partner organization improve by asking them to stick to standards and give you proper details.

Federate!

How many individual metadata files are you consuming? Can you limit the number of individual relying parties that you need to add by Federating with entities like InCommon or REFEDs.

Thanks for joining us!

Just following SOME of these tips will make your life managing an SSO support environment. It’s been a bit of an adventure, and we hope you’ve enjoyed this series. If you need support for your SSO environment we’re here for you. IDM Engineering is a team of dedicated, honest SSO support engineers that are readily available to help you architect a new single sign on environment, manage or improve existing SSO infrastructure, or just dig in and quickly solve a integration issue. We speak SAML… and OAuth… and ADFS… and SimpleSAMLphp… and more. Furthermore, we have a carefully curated collection of technological experience and expertise that can assist you with whatever single sign-on issue you’re facing. Give us a shot! Let us know how we can help you today!

† Or — how I learned to stop worrying and love XML.