Welcome back to another HelloID blog post. We’re bringing you a brand new, three-part series where we’re talking “What Is?” From SAML to User Account Onboarding, and Single Sign-On, we’re going to be looking at what they are and what exactly they can do for you. So, let’s get started with Single Sign-On.
What is Single Sign-On (SSO)?
In order to use any application, or to access a secure network, you need to first 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 an application. This combination of a username and password is referred to as credentials, which are 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 by. Nowadays, a person may be required to log in to as many as 9 applications just to do their job. And 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 unauthorised access.
It was these difficulties and security risks that gave rise to the concept of Single Sign-on, or “SSO” for short. The basic premise 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 like 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. But 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). This means that without an actual copy of the username and password, credentials cannot be leaked if one of the applications are compromised.
Before we cover how this works in practice, let’s familiarise ourselves with 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 Service and Identity Providers talk to each other to verify the user’s identity. If the Identity Provider positively identifies the user, then they are allowed access to the application.
An assertion is a package of information that is sent from the Identity Provider to the Service Provider. 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 Identity Provider and Service Provider have access to. This lets the Service Provider be sure that the information received is from a trusted source.
In general terms, SSO works by having an established trust between the Identity Provider and the Service Provider. This means that when the Identity Provider says that the person accessing the application is Bob Johnson, the Service Provider believes this and logs the user into Bob’s account.
The administrator of the systems establishes this trust in the first place. Information from the Identity Provider is passed to the Service Provider, and vice versa, along with a certificate. When a user opens an application, the Identity Provider uses the certificate to sign and encrypt an assertion. This assertion is then sent to the Service Provider, instead of the user’s credentials. It is then decrypted by the Service Provider and verified.
With this trust established, Service Providers no longer need to store any user credentials. This greatly reduces the likelihood of compromised credentials in the event of a data breach.
Now that we know how SSO functions in general terms, how does a user go about accessing an application? And how does a Service Provider know to check with an Identity Provider?
Most Single Sign-On Identity Providers come with application portals. These application portals are often web-based applications that a user can access from anywhere in the world, at any time. 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 job. Once the user chooses an application, an SSO assertion is sent to the Service Provider with the user’s information. If the assertion is accepted by the Service Provider, the user is taken to the application, and off they go! This type of SSO activity is known as “IdP Initiated”, because it came from the Identity Provider itself.
But what happens if a user doesn’t go to the portal first? What if, instead, they point their browser directly to an application such as Gmail? Well, in those cases, the Service Provider knows what to do based on the user’s username or email domain. Instead of storing credentials, they store the Identity Provider information and know where to route the authentication request. This type of request is known as “SP Initiated”, because the SSO request came from the Service Provider itself.
In addition to increasing security by lowering the risk of compromised credentials, a good 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.
However, there are risk associated with a Single Sign-On solution.
With an SSO solution in place, the Identity Provider and any connected authentication systems, become highly critical. This means that in the event of a loss or disruption to one or the other, access to all SSO-enabled applications is effectively denied. Additionally, then, 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 when using any SSO solution an additional level of authentication, such as Smart Cards of One-Time Password tokens, are also employed in combination with the SSO solution.
Despite the risks, however, a Single Sign-On solution carries many benefits to any sort of organisation. Currently, 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.
We hope you enjoyed this in-depth look at Single Sign-On, and what it can do for you. Keep an eye on our blog for the next blog post in the “What Is?” series.
As always, if you have any questions, please do get in touch with us through the “Contact” page on our website. We’ll get back to you as soon as possible.