Single sign-on (SSO) is an authentication standard that lets users use one set of credentials to access multiple software systems. It is a technology that combines different login screens into one.
With SSO, the user only has to input their username and password once to access multiple software systems. SSO is mainly used by businesses where applications are managed by IT teams. Remote workers part of these organizations can also log in and use these applications using SSO.
To better understand SSO, we will present an analogy. For instance, if customers of a certain liquor store always have to show their identification cards every time they go to purchase alcoholic beverages, the experience would be frustrating. Consequently, they would either complain every time they are asked to do so or look for another liquor store altogether.
However, most liquor stores would not request identification from returning customers every time they buy alcoholic beverages. Only new customers would be requested to do so. In perspective, this is how SSO works.
Instead of being asked for your credentials over and over, the user will identify himself once and will be able to access all the other services. For instance, once you log in to a company’s computer you can access your LMS and CRM (customer relationship management) systems using the same credentials.
SSO is a vital element of identity and access management (IAM). The verification of users’ identities is important to establish which permissions each user should be granted. Tovuti is single sign-on ready and is currently working with any SAML-based and OAuth-based SSOs.
Tovuti uses SAML-based and OAuth-based SSOs. However, there are other types. Below is a list of all the available types.
SAML-based SSO allows the centralization of client authorization for federated security domains. As a result, SAML eliminates the need for multiple usernames and passwords for easier access to applications and services. It also reduces tickets for blocked access to systems and gives an organization greater control over an entity’s user lifecycle.
Examples of SAML-based SSOs that Tovuti LMS is currently working with includes Active Directory, Okta, and OneLogin.
SAML 2.0 is the most common version in use and is based on XML-based protocols that use security tokens that come with assertions to relay information about a principal (end-user) among SAML authorities commonly known as identity providers and SAML consumers commonly called service providers.
SAML 2.0 allows cross-domain SSO that reduces the administrative authentication tokens being sent to a user. It was ratified as an OASIS-based standard in 2005, therefore, replacing SAML 1.1. About 24 companies were involved in the development of SAML 2.0. Notably, Liberty Alliance donated its ID-FF (Identity Federation Framework) specification to OASIS, in turn, making it the basis of SAML 2.0.
Tovuti supports Single Sign-On (SSO) with any Identity Provider that supports SAML such as:
Tovuti currently supports OAuth 2.0 authentication. This is the industry standard authorization protocol. OAuth 2.0 focuses on client developer simplicity and also provides web application authentication flows for mobile phones, desktop applications, and other devices.
The IETF OAuth Working Group is credited for developing this standard. OAuth 2.0 is an open standard authorization framework that defines how unrelated services and servers can securely grant authenticated access to corporate assets without disclosing the initial, related single username and password.
An example of OAuth 2.0 at work is when you visit a website and it gives you more services and opportunities using another website’s credentials. When you click on a hyperlink directing to another website, the other website authenticates you and grants you access while the initial website you visited logs itself out using the permission from the second website.
Another example is when you are sending files stored on a cloud to another user using email, and the cloud and email service provider are unrelated. When the sender attaches the files to their email, OAuth 2.0 seamlessly authenticates the email system and browses the file without requiring credentials for the file storage system.
Tovuti supports Single Sign-On (SSO) with any Identity Provider that supports OAuth 2.0 such as:
FIM is an arrangement made between different corporations allowing their users to use the same credentials to access services in the larger enterprise group. This type of SSO links a user’s credentials across various security domains, each with its own identity management system.
OIDC is an identity layer placed on top of the OAuth 2.0 protocol. It allows clients to verify users’ identities based on authentication done on an authorization server. It also collects basic profile information about the user.
It allows clients of all types (mobile, web-based, and JavaScript) to send and receive information about end-users and authenticated sessions. It also comes with extensible features such as identity data encryption, session management, and OpenID Providers discovery, when necessary.
SSO works based on a trust relationship established between an application, a known service provider, and an identity provider such as OneLogin. The trust relationship is set when a certificate is exchanged between the known service provider and the identity provider.
The certificate is used to authenticate information being sent between the service provider and the identity provider to ensure that the source is trusted. In the case of SSO, this identification is in the form of tokens that contain a user’s identifying elements such as a username or email address.
The login flow is described below:
If the user tries to access another website, the second website will have to create trust using the same SSO process and the authentication will follow the same steps outlined above.
This is data or information that is passed from one system to another during the SSO authentication process. For instance, the data or information can be the user’s email address and other details about the system sending the token.
To verify that the token is coming from a trusted source, it must be digitally signed. The certificate used for the digital signature is exchanged during the first configuration process.
During the SSO process, the sending of authentication tokens to external applications and services is important. This process allows authentication to take place securely and separately from cloud services, making SSO a possibility.
As an example, think of an ‘invite-only’ event where entry is limited to a few selected people. Security guards at the gate can be ordered to stamp each guest’s hand to allow them access to the event. As a security measure, other event and security staff can be tasked to check if all the guests have stamps on their hands.
However, not just any stamp will pass as legitimate. There are other things that they will be looking for such as the shape and color of the stamp authorized by the event organizers.
Hence, just like these stamps have to match certain criteria, so do tokens. Tokens have communication standards that ensure that they are legitimate and correct. SAML is the main authentication standard for tokens. In perspective, websites are written in HTML (hypertext markup language), while tokens are written in SAML.
It is not very certain as to the secure nature of SSO but, indeed, it does improve security. SSO enhances security for a variety of reasons. Single sign-on simplifies the management of usernames and passwords both for the administrators and users.
Instead of having several credentials for different systems, users can just have one complex set of credentials. Essentially, SSO grants faster access to applications.
Administrators will usually control requirements such as multi-factor authentication (MFA) and password complexity from one central location. They can also quickly block access to particular applications for users who leave an organization.
Nonetheless, SSO has its disadvantages. For instance, there are those applications you might want to have some extra layer of security. Hence, in this case, it would be appropriate to have an SSO solution that requests users for additional authentication information before being granted access to certain applications. Also, the SSO solution can be configured to grant users access to applications only when they are connected to secure networks.
The type of SSO solution deployed by your organization will determine how SSO is implemented. Regardless of the requirements and the steps you need to take, you must have clear goals and objectives that you want to implement.
Here are some points to consider:
SSO is widely accepted to be more secure. It is also simpler and more convenient for users. However, critics question whether having one universal password is more secure than multiple passwords. Proponents, nonetheless cite the below benefits:
Using an identity provider, through SSO, allows the learning and development management team to seamlessly synchronize the provisioning and deprovision of learners in the Learning Management System with the centrally managed census of corporate employees. In addition, most identity providers contain the concept of employee roles, which can be mapped to the Learning Management System roles or groups. This is valuable since role-based learning can be automatically assigned. The end result of using an identity provider, through SSO, with your LMS, is the ability to alleviate the adding and removing users and assigning roles and assigned learning manually.
SSO provides a single set of credentials to access various applications and services, especially in corporate environments. It eliminates the need of having many passwords for different systems. Despite its downsides, it is still a reliable secure way to access applications and services in a user-friendly fashion.