In order to use an application, or access a secure network, you need to identify yourself. This is often done with a combination of a unique username and a password. Nearly everyone is familiar with this method of logging in to a system or application. The combination of a username and password is referred to as “user credentials”, which provide a form of “authentication”.
Decades ago, a single set of user credentials were all that a person needed to do their job. Then, more applications were created that required separate credentials. And still more, as the years went on. Nowadays, a person may be required to log in to as many as 9 applications in order to do their job.i Each of those applications usually requires their own user credentials.
The rise in the number of applications wouldn’t be so bad if users could have the same credentials for all of them. However, that would create a massive security hole. If one system were breached and the credentials were leaked, then all systems with the same username and password would be vulnerable to unauthorized access.
These difficulties and security risks gave rise to “single sign-on” (SSO). The basic idea of SSO is that every application a person needs can be accessed by logging in only once with a single set of credentials. This may sound very similar to the scenario above, where each system could be accessed with the same username and password, but it’s quite different. In the scenario above, each system held a copy of the credentials in their own database. With a proper SSO solution, those applications don’t have a copy of the credentials—they simply trust what is called an “identity provider” (IdP). Without an actual copy of the username and password, credentials can’t be leaked if one of the applications are compromised.
Important SSO Terms
Before we cover how this works in practice, let’s go over some new terms and definitions:
- Identity Provider (IdP): This is where user credentials are stored. All authentication happens here. There are various popular IdPs available on the market, such as Active Directory Federation Services (AD FS), Okta, OneLogin, and HelloID.
- Service Provider (SP): This is often the application that a user is accessing that requires authentication. When a user opens an application, the SPs and IdPs “talk” to each other to verify the user’s identity. If the IdP positively identifies the user, then they are allowed into the application.
- Assertion: An assertion is a package of information that is sent from the IdP to the SP. The content of an assertion varies by SSO protocol (e.g., SAML, OAuth, or OpenID) but it usually contains the user’s unique ID, name, and various other attributes. It is signed and encrypted by a certificate that both the IdP and SP have access to. This lets the SP be sure that the information is from a trusted source.
In general terms, SSO works by having an established “trust” between the IdP and the SP. This means that when the IdP says that the person accessing the application is Bob Johnson, the SP believes this and logs the user into Bob’s account.
This trust is established by the administrator of the systems. Information from the IdP is passed to the SP, and vice versa, along with a certificate. When a user opens an application, the IdP uses the certificate sign and encrypt an assertion. This assertion is then sent to the SP, instead of the user’s credentials. It is then decrypted by the SP and verified.
By establishing this trust, SPs don’t need to store any user credentials. This greatly reduces the likelihood of compromised credentials in the event of a data breach.
SSO and User Access
Now that we know how SSO functions in general terms, how does a user go about accessing an application? How do SPs know to check with an IdP?
Most single sign-on IdPs come with application portals. These are often web-based applications that a user can access from anywhere in the world. Once a user logs into the portal with their network credentials, they’re given access to any number of applications they need to perform their work. Once the user chooses an application, an SSO assertion is sent to the SP (e.g. the cloud infrastructure hosting and managing access to that application). The assertion contains the user’s information. If the assertion is accepted, the user is taken to the application, and off they go! This type of SSO activity is called “IdP initiated”, because the assertion came directly from the IdP itself.
But what if a user doesn’t go to the portal first? What if they point their browser directly to an application such as GMail? In those cases, the SP knows what to do based on the user’s username or email domain. Instead of credentials, they store the IdP information and know where to route the authentication request. This type of request is called “SP initiated”, because the SSO request came directly from the SP.
In addition to increasing security by lowering the risk of compromised credentials, a quality single sign-on solution provides easier application access for end users. This can directly translate into higher morale and productivity, and possibly even increased revenue.
There are risks associated with a single sign-on solution, however.
With an SSO solution in place, the IdP and any connected authentication systems become highly critical. In the event of a loss or disruption to one or the other, access to all SSO-enabled applications is effectively denied. Additionally, with all applications being accessible through a single set of credentials, it becomes much more important to protect those credentials and make sure that they are not shared or misused. It’s highly recommended that any SSO solution is combined with an additional level of authentication, such as multifactor authentication (MFA)/one-time passwords (OTPs), or physical tokens.
Despite the risks, a single sign-on solution carries many benefits to any sort of organization. Presently, SSO is a hot topic at all levels of all industries. Everyone wants their business to perform faster and be more streamlined, and SSO is a key factor in achieving those goals.