What Is Single Sign On and How To Implement?
We are just asked the above question. And while we have done many projects with single-sign-on, we realized that we can not answer this question clearly. So we want to make a research to have single-sign-on can be correctly defined, understood and implemented.
What Is Single-Sign-On?
According to Wikipedia:
Single sign-on (SSO) is a property of access control of multiple related, but independent software systems. With this property a user logs in once and gains access to all systems without being prompted to log in again at each of them.
Seem too general, right? We can take a quick search around the Internet and know that, many people are defining SSO in many ways:
…the user only has to provide credentials a single time per session, and then gains access to multiple services without having to sign in again during that session…
…users are authenticated only once, regardless of how many other applications they attempt to access after the initial login…
Or:
…merely that the same credentials are used for multiple services; the user might have to login multiple times, but it’s always the same credentials…
Sometimes, you will hear about Federated Login:
Federated Identity (FID) refers to where the user stores their credentials. Alternatively, FID can be viewed as a way to connect Identity Management systems together. In FID, a user’s credentials are always stored with the “home” organization (the “identity provider”)…
Now, as almost definitions only reflect user’s perspective, I would like to have SSO understood as:
single authentication credential–user ID and password, smart card, one-time password token or a biometric device–to access multiple or different systems within a single organization
Federated Identity
Federated Identity usually comes with Single Sign On, however they do not share the same domain. It refers to where the user stores their credentials. Alternatively, FID can be viewed as a way to connect Identity Management systems together. In FID, a user’s credentials are always stored with the “home” organization (the “identity provider”). When the user logs into a service, instead of providing credentials to the service provider, the service provider trusts the identity provider to validate the credentials. So the user never provides credentials directly to anybody but the identity provider.
FID and SSO are different, but are very often used together. Most FID systems provide some kind of SSO. And many SSO systems are implemented under-the-hood as FID. But they don’t have to be done that way; FID and SSO can be completely separate too.
OAuth
Sometimes you will use OAuth as a SSO implementation, however it is not true. OAuth is a standard just for Authorization while SSO related to both Authentication and Authorization. You also know that Facebook, which implement their Facebook Connect based on OAuth 2.0, also is a SSO. But Facebook Connect is not true SSO because OAuth is just a way for them to grant access from third-party applications to their user data.
Some examples of real SSO usecases may include:
- You work for a company. The company assigns an account and password for you to logon to Windows work machine. After you logged in, you also open company Intranet website, company portal, Skype for Business and no need to enter any credential. That’s true SSO.
- You use an internal dashboard of your organization. You use email and password to login. Then the dashboard includes many application, some of them are internal while others are third party products like Word, Excel, Exchange, you can access 10 applications by the same email and password which you have just used to log into dashboard, and you are restricted from accessing to 2 other applications because your account does not meet needed security level. That’s true SSO.
- You use Facebook and log into Facebook site in Chrome. Then you navigate to medium.com, and sign in with your Facebook account, you don’t have to enter Facebook account again, but you have to grant Medium app permission to access your Facebook profile. That’s social login, where OAuth comes in play, a part of SSO, but not true SSO.
Implementation
In order to have SSO work, there are many aspects to consider:
Protocol
Most SSO protocols related to security, including: SAML, OpenID, OpenID Connect, OAuth 2.0, SCIM, XACML, Passive Federation, WS-Trust or WS-Federation. When it comes to implementation, based on chosen solution, you may have to implement these protocols by yourself, or leave it to solution provider instead. Another note that almost SaaS applications now support SAML 2.0, so you can easily integrate your SSO solution with those app, like Box or Google Apps.
Identity Provider
You can have your own provider, but many SSO solutions are already available by another provider like Active Directory on-premises, or Windows Azure Active Directory on cloud. My advice is any Active Directory solution, and based on your requirements, place it on cloud or have it installed on your own private network.
Access Management
OneLogin, PingIdentity or Saleforce are some of the leading providers for Identity Access Management. They offers end-to-end solution to have SSO integrated to your existing system, or designed in new infrastructure. They also provides other features like multi-factor authentication with biometric or passcode. And of course, you can deploy your own Active Directory Federation Service to manage access to your applications. A typical scenario can be: all internal or third party applications inside a company network, can redirect to an Active Directory server for authentication.
Yeah, it’s all about SSO and it’s aspect, I hope you have found enough information about true SSO and implementation. Please comment below or send me email if you have any concern. Thank you.