Single Sign-On (SSO)

In the modern digital landscape, where we regularly utilise numerous applications and platforms, the management of diverse login credentials has become a notable challenge.

The constant need to log in and out of various systems can prove both time-consuming and frustrating. Additionally, having to memorise multiple passwords may lead to security risks, such as the use of overly simplistic passwords or the habit of writing them down on paper.

This is where Single Sign-On (SSO) comes into play.  In this article, we delve deeper into the concept of SSO, how it operates and why it holds such significance within today’s digital realm.

What is Single Sign-On (SSO)?

Single Sign-On, abbreviated as SSO, simplifies the user experience by allowing users to log in just once. The SSO software then takes care of automatic authentication for other applications.

In practical terms, this means that users, once logged into one application, are automatically granted access to all other authorised applications without having to log in again.

This represents a significant shift from just a few years ago when a limited set of applications was all a user needed to perform their work.

In today’s digital landscape, where users frequently require access to dozens of different applications, SSO offers an efficient and user-friendly solution for access management.

Advantages of Single Sign-On (SSO)

• User-friendliness: Users only need to remember a single set of login credentials, simplifying and expediting the login process.
• Increased productivity: Less time spent on logging in translates to more time for actual work.
• Enhanced security: By reducing the need to remember multiple login credentials, SSO lowers the risk of password practices that might compromise security.
• Efficient access management: Administrators can easily oversee which users have access to specific applications, all from a centralised location.
• Reduced IT support: With fewer password resets (due to forgotten passwords) being requested, IT teams can focus on more crucial tasks.

Disadvantages of Single Sign-On (SSO)

• Single point of failure: If the SSO solution experiences an outage, users may lose access to all applications.
• Security concerns: If a user’s login credentials are compromised, an attacker could potentially gain access to all authorised applications.
• Compatibility challenges: SSO is not supported by all applications, leading to inconsistencies in the user experience.

The risk with Single Sign-On is that once you’re logged in, you have access to everything. Hence, it is highly recommended to supplement every SSO solution with an additional layer of authentication. (Two-Factor Authentication).

How Secure is SSO?

Single Sign-On (SSO) is designed to enhance both user-friendliness and security. By reducing the number of login credentials users need to remember, SSO mitigates the risk of insecure password practices, such as using overly simplistic passwords or writing them down on paper.

Furthermore, SSO allows administrators to easily monitor and manage user access to various applications, helping prevent unauthorised entry.

However, like any security solution, SSO is not entirely risk-free. If a user’s login credentials are compromised, an attacker could potentially gain access to all authorised applications. Therefore, it is crucial to augment SSO with additional security measures, such as robust password requirements, regular password changes and potentially even.Multi-Factor Authentication (MFA).

MFA is a security method requiring users to provide two or more pieces of evidence (or factors) to verify their identity. These factors can include something the user knows (such as a password), something the user possesses (such as a security token or a mobile device) or something inherent to the user (such as a fingerprint or other biometric feature). By combining SSO with MFA, organisations can offer the ease of use of SSO while maintaining a higher level of security.

There are also alternatives to SSO, such as federated identity management, where identity information is shared among different organisations, and risk-based authentication, where the authentication level adapts based on the risk level of the user and the specific transaction. However, these solutions have their own advantages and disadvantages and may involve a more complex implementation compared to SSO.

For those seeking a comprehensive solution that balances user-friendliness and security, HelloID could be the perfect choice. With HelloID, you can enjoy the advantages of SSO, while also implementing other advanced security features, including Multi-Factor Authentication. Get in touch with us today to explore how HelloID can be of assistance.

Download white paper about security

How does Single Sign-On work?

The core principle of SSO is that a person can access all the applications they require by authenticating just once. Therefore, applications need a means to recognise that the user has already been validated. With a robust SSO solution, modern applications do not store a duplicate set of login credentials; instead, they rely on what is known as an Identity Provider (IdP).

Before we delve into how this process functions, let’s first clarify the terminology and corresponding definitions.

To use an application or gain access to a secure network, a person must be able to establish their identity. This is typically achieved through a combination of a unique username and a password. The pairing of a username and password serves as a method of authentication.

Identity Provider (IdP):
This is where login credentials are stored and all authentication takes place. An Identity Provider could be the local Active Directory, Azure AD, or, for example, our Cloud IDaaS solution, HelloID.

Service provider (SP):
This refers to the system or application that a user has access to and where verification is required. When a user opens an application, the service and identity providers engage in communication to confirm the user’s identity. If the identity provider successfully authenticates the user, access to the application is granted.

Assertion:
An assertion is a package of information transmitted from the IdP to the SP. The contents of an assertion can vary depending on the SSO protocol (such as SAML, OAuth or OpenID), To use an application or gain access to a secure network, you need to establish your identity, which often involves a combination of a unique username and a password. This combination of a username and password constitutes a form of authentication.
An assertion is a package of information transmitted from the IdP to the SP. The contents of an assertion can vary depending on the SSO protocol (such as SAML, OAuth or OpenID), but typically include the unique ID, name and various other attributes. It is signed and encrypted by a certificate accessible to both the IdP and the SP, enabling the SP to verify that the information originates from a trusted source. To use an application or gain access to a secure network, you need to establish your identity, which often involves a combination of a unique username and a password.. This combination of a username and password constitutes a form of authentication.

Here is a detailed overview of how SSO works:

1. User authentication: The user logs in to a central authentication server, known as the Identity Provider (IdP). This could be the local Active Directory, Azure AD or our Cloud IDaaS solution, HelloID, for instance.
2. SSO session: After a successful authentication, the IdP initiates an SSO session, often by placing a cookie in the user’s web browser.
3. Accessing applications: When a user opens an application, the service and identity providers communicate to verify the user’s identity. If the identity provider confirms the user’s identity, access to the application is granted.
4. Authentication verification: The IdP verifies the SSO session. If the user is already authenticated, the IdP sends an assertion to the SP containing the user’s authentication details. This assertion is secured and encrypted using a certificate accessible to both the IdP and the SP.
5. Granting access: Based on the received assertion, the SP grants the user access to the application without requiring the user to log in again. This eliminates the need for SPs to store login credentials.

It’s important to note that this is a simplified overview, and the specific steps may vary depending on the SSO solution being used and the configuration of the applications.

In simpler terms, Single Sign-On (SSO) operates based on a trusted connection between the Identity Provider (IdP) and the Service Provider (SP). This means that when the IdP confirms that the person using the application is ‘Jan Jansen’, the SP trusts this confirmation and allows the user access under the ‘Jan Jansen’ account.

This trust is established and managed by system administrators. Information from the IdP is shared with the SP along with a certificate, and vice versa. When a user opens an application, the IdP uses the certificate token to create an encrypted assertion. This assertion is then sent to the SP instead of the user’s login details. The SP ensures that it decrypts and validates this assertion.

By establishing this trust, SPs no longer need to store users’ login credentials in their systems.

How does Single Sign-On work in practice?

The above explanation outlines how SSO can function in general. But how does this work in practice? How does a user go about opening an application, and how does an SP know it needs to check with the IdP?

The majority of Single Sign-On Identity Providers (IdPs) are accompanied by application portals. These are typically web-based applications accessible to users worldwide. Once a user logs in to the portal using their credentials, they gain access to all the necessary applications and resources required for their work. Subsequently, when the user selects a specific application, an SSO confirmation is transmitted to the Service Provider (SP) containing the user’s details. Upon acceptance of this assertion, the user is redirected to the chosen application, enabling them to start working immediately. This form of SSO activity is termed ‘IdP-initiated’ as it originates from the Identity Provider (IdP) itself.

What if the user doesn’t start by visiting the portal? For example, what happens when they go directly to Gmail in their web browser? In such scenarios, the Service Provider (SP) determines the necessary actions based on the user’s username or email domain. Instead of storing user credentials, the SP retains information from the Identity Provider (IdP) and directs the authentication request accordingly. This kind of request is termed “SP-initiated” because it originates from the service provider (SP).

[1] https://www.businesswire.com/news/home/20170918005033/en/Information-App-Overload-Hurts-Worker-Productivity-Focus

Learn more about Cloud Single Sign-On