I have been working with Single Sign On a lot this year. I could fill this blog completely with SSO information. Most of my followers don’t care a whole lot about such things, so I’ll try to space out my SSO posts just a bit.

What is Single Sign On?

We all have tons of passwords, and in the corporate setting, it’s no different. Our companies and organizations use dozens of different web applications to get business done. Each of these comes with new credentials to remember, and many of them have different password complexity requirements, making it even more difficult.

For personal password management, tools like 1Password work like a champ. They help us to manage a vast army of credentials in a more secure manner.

In the enterprise, it’s a bit different. Corporate IT departments like to centrally manage account provisioning in many of the company applications. Single Sign On systems allow users in the company to sign in to one application and automatically be signed in to other Web applications throughout their current browsing session.

So, if an employee checks their email on the company Google Apps email account and then wants to access the employee portal, she only has to log in to the first application. The single sign on system remembers the session and automatically signs the user in to the next application.

Single Sign On vs. Reduced Sign On

Single Sign On systems automatically log users in to SSO-enabled applications after they’ve logged in to any one SSO-enabled application. Reduced Sign On simply means that each of the applications use a directory (like LDAP or Active Directory) for authentication. Each of the applications requires a login, but they can all use the same username and password.

An insecure application that uses an external directory for authentication could put your whole organization at risk. If an intruder is able to compromise a weak system, they could use a number of different tools to uncover users’ directory passwords. Once they establish these passwords, all other applications are fair game to the intruder.

With Single Sign On solutions, the applications never know the actual password. They have trust established with an identity provider (IdP) who can vouch for the user’s access level.

ADFS, SAML, Shibboleth, CAS

There are many different ways to accomplish Single Sign On. Lots of universities use CAS. I got confused and stopped trying, so I can’t provide much insight on it. Many other universities use Shibboleth, which is a flavor of SAML. Some use ADFS, but it’s Microsoft… also again, I got confused and stopped trying.

In the end, we partnered with a company using SAML (Security Assertion Markup Language) as the underlying SSO technology. SAML uses XML assertions between an Identity Provider (IdP) and Service Provider (SP). Our vendor serves as our Identity Provider website link. They have a graphical interface to add user directories and applications. The Service Providers are all of our connected applications. Since SSO is popular in higher education, there are a number of our applications that natively support SAML.

I’m not going to get bogged down in the nitty gritties of SAML here, but I did want to give you the highest level overview, hopefully in plain English.

Who should use SSO?

Any company or organization who wants to reduce username and password issues for its users. We currently have about a dozen applications enabled in our environment. Previously, that was a dozen different usernames and passwords for users to remember. We always encouraged them to make them the same (which isn’t really good advice in the first place), but we frequently had issues with users being confused and experiencing difficulties with credentials for various apps.

Here’s the deal, all the SSO vendors will tell you that single sign on drastically reduces help desk requests. I’ll tell you that your mileage may vary. I can almost guarantee that your volume will increase (probably drastically) during your first couple of months after implementation. It confuses people to start with. Then, they seem to get it.

It seems like our password tickets have decreased since the launch of SSO, but we don’t have great tagging in our help desk software to be able to give you hard data. Things “feel” better now, if that’s any consolation.

Roll Your Own or Get a Vendor?

Both CAS and Shibboleth were designed and developed by major universities. They, along with SAML, are open source and freely available to use, but they are quite complex to set up and master. If your organization has extra developers at its disposal, it’s most definitely possible to “roll your own” Single Sign On solution using SAML, Shib, or CAS.

If you don’t have extra developers, it makes sense to seek outside help. We launched our SSO solution in February of this year. Unfortunately times were tough for our start-up provider. They have gone out of business now, and we’re set to move to OneLogin as our IdP at the end of this month.

Ask Lots of Questions

When selecting a vendor, you’ll want to ask a bunch of different questions, like:

  • How do you connect to my directories (Active Directory, OpenLDAP, etc)?
  • Is your solution on premise or cloud based?
  • Does your solution allow users to reset their passwords? How?
  • Does your solution allow only SAML, or do you support other authentication methods?
  • Do you support non-SAML applications with a browser add-on or through a different method? (I personally don’t like the browser add-on solution)
  • Do you support multi factor authentication? Is that included with the base price?
  • Can you support authentication to internal applications (not publicly accessible)?

Why We Chose OneLogin

There are a bunch of players in this market. We landed on OneLogin for a number of reasons.

  • Their user experience is well designed. It’s easy for regular folk, like me, to add directories and applications, to set up security policies, etc.
  • They include multi factor authentication at no added cost. You can use their OTP app or Google Authenticator right out of the box.
  • They allow password resets through the application in an elegant and tightly integrated fashion. Password resets can be accomplished through email, SMS messages, or security questions. They also offer a method to require users to enter security questions on their first login.

However, in the end, or favorite feature was their company culture. We felt that they were approachable, adaptable, and nimble on their feet. We felt that they were a partner that could keep up with our oddball requests.

This turned out to be a super long post. I hope that it helps someone out. If you have any questions, hit me up in the comments.

Photo Credit: Ervins Strauhmanis (cc)