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 first of a five-part series on the Fundamentals of SSO Support for IT Administrators.† You can see our second post here, our third post here, our fourth post here, and our fifth post here.
SSO Support Doesn’t Have to Be Hard
You wouldn’t necessarily know this by researching “best practices”. Trying to find information about best practices for managing a Shibboleth environment, for example, will turn up a lot of lackluster information. For example, a brief inquiry on “managing a Shibboleth IdP environment” turns up some basic Shibboleth Wiki entries, a ton of integration instructions for getting popular Service Providers working with Shibboleth, and the only truly reasonable resource that turns up on the front page is an excellent, though aged whitepaper: “Implementing a Shibboleth SSO Infrastructure” from SANS.
So what are you to do?
Start Small: First Principles
Ask yourself this? Can you explain how a single sign-on interaction works? Can you explain it to your mother? What about a rubber duck? If the answer to any of these questions is “no”, perhaps it’s time to take a step back and assess your knowledge.
What technologies does your environment leverage? SAML? ADFS? OAuth? Make sure you’re familiar with the concepts of single-sign on before trying to dive in to a Shib IdP config and get MFA working.
For SAML —
The shib wiki isn’t a bad place to start here, surprisingly, but you should relatively quickly realize that Shibboleth != SAML. OASIS is the group that actually oversees that SAML protocol, and the high-level overview that they provide is a fantastic place to start if you don’t “get” SAML.
For ADFS —
You are, unfortunately, subject to the whims and whimsy of The Great Old Ones in charge of Microsoft. Fortunately, there is some good documentation to come out of Redmond, such as this piece on best-practices when deploying ADFS. They’ll even helpfully tell you that it only takes 9 minutes to read (do not misconstrue reading and understanding). Getting used to the nomenclature surrounding ADFS can be a bear — ADFS has it’s own language — though you’ll be able to go a long way if you just substitute “identity provider” every time you ready “claims provider” and “service provider” each time you read “relying party”.
For OAuth —
First thing first: do you understand that OAuth 1.0 ≠ Oauth 2.0 ≠ OpenID Connect ≠ OpenID? Here StackOverFlow provides! This new-ish technology (for the IAM community) has an abundance of posts on how it’ll solve all of your problems, but adoption at the enterprise is slow, which means that it can be a challenge to find trusted sources. What’s left then are commercial providers. Here, Auth0 takes the lead in providing a reasonable trove of materials.
Next… To the Lab!
Next week… we’ll dive into the crucible by which Help Desk turn into Engineers, the lab, and why development environments play an absolutely crucial role for those tasked with SSO Support for their Organization.
Can’t Wait?
Need help now? Well what would a blog post be without a sales pitch? 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.
