Benefits of single sign-on for eLearning authentication

‍What is SSO?

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.

Types of SSO

Tovuti uses SAML-based and OAuth-based SSOs. However, there are other types. Below is a list of all the available types.

• Security Access Markup Language (SAML).
• OAuth 2.0
• Federated Identity Management (FIM)
• OpenID Connect (OIDC) 1.0

SAML

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:

• OneLogin
• AuthO
• Centrify Identity Service
• Microsoft Azure Active Directory
• Microsoft Active Directory Federation Services (ADFS)
• Okta Identity Management
• Adaptive Next-Gen Access
• Amazon Cognito
• SecureAuth Identity Platform
• VMware Workspace
• OneEmpowerID
• Optimal IdM
• CloudCodes
• LastPass Enterprise
• Ping Identity
• PingOne
• Salesforce Identity
• Generic support for SSO systems that use SAML 2.0

OAuth 2.0

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:

• AWS Cognito
• Google Apps
• Facebook
• LinkedIn
• Instagram
• Windows Account
• Other OAuth2 supported Identity Providers

Federated Identity Management (FIM)

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.

OpenID Connect (OIDC) 1.0

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.

How Does SSO Login Work?

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:

1. A web visitor uses an application or visits a web page he wants access to, that is, the service provider.
2. The service provider releases a token containing the user’s information such as the email address, and sends it to the SSO system (identity provider), as part of the process of authenticating the user.
3. The identity provider first checks if the user is already authenticated. If already authenticated, the process skips to step 5.
4. If the user has not been authenticated, he will be prompted to enter his credentials by the identity provider. It can be simple such as a username or password or another advanced authentication form like a One-Time Password (OTP).
5. Once the credentials are authenticated by the identity provider, it sends a token back to the service provider to confirm that the user has been successfully authenticated.
6. The token is usually relayed via the user’s browser to the service provider.
7. The token is then received by the service provider and validated based on the trust relationship initially established between the identity provider and the service provider during configuration.
8. Lastly, the user is then allowed to access the service provider.

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.

SSO Token

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.

How Does SSO Token Work?

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.

How Secure is SSO?

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.

How SSO is Implemented

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:

• Is there access to an API (Application Programming Interface)?
• Will the SSO solution grow the same as your company and its needs?
• The types of users being served and their different requirements.
• Cloud-based or premium solution.
• The systems to be integrated with the SSO.
• What features are you looking for to ensure that only trusted users are granted access? These include MFA, Device Trust, Adaptive Authentication, and IP Address Whitelisting.

Advantages of SSO

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:

1. Stronger passwords: With only one password in use, it is easy to create, remember, and use stronger passwords.
2. No password repetition: ‘Password fatigue’ is a condition that sets in when users have to remember many different passwords. They will tend to reuse passwords across services which is highly risky. If one password is hacked, it can be used to infiltrate the whole system.
3. Enhanced password policy enforcement: Password security rules are better enhanced by single sign-on. For instance, users can be requested to change passwords periodically. Since it is only one password, it becomes easy.
4. Password re-entry single point enforcement: To check if a user is active, administrators may request him/her to re-enter his credentials. This is done from one central location instead of implementing it across many systems, some of which might not support SSO.
5. Internal management of credentials: Passwords stored externally present a security risk. When stored internally, IT teams have more control to enforce security.
6. Multi-factor authentication: It is the use of more than one identity to authenticate a user. For instance, in addition to a username or password, a user might be requested to enter a specific code sent to their phone. Since only the user can receive the code, the system becomes secure.
7. Time-saving: A lot of time is wasted in the recovery of passwords. SSO cuts down this time by providing the user with one single secure password.

Benefits of SSO With Learning Management Systems

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.

‍Conclusion

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.