Single-Sign-On (SSO) Integration

Single Sign-On Explained

Single Sign On (SSO) is a mechanism by which a multitude of services can be accessed with only one login id and password. This means that by logging into one account, multiple services that are connected under a common wing or platform will all be accessible. If we consider a system without Single Sign on, each service or application that is provided will require an individual login id and password. The number of accounts for one user in that system will gradually grow with each new service or application that is available. As a result, it becomes very difficult for a user to remember and keep track of each individual user id and password. Furthermore, there is an added complexity to each of those services as they each require a mechanism for managing individual sessions for logging in and logging out. Finally, this leads to more security threats as users may resort to easy passwords or password reuse. SSO is a great method of overcoming these issues. By having one login id and password through which the user gains access to a system and its related components or services, the user can eliminate using multiple accounts for each service and focus on building one strong password which can be remembered well. It simplifies the authentication process for applications also by having an Identity Provider that provides a mapping between the different services. It keeps track of the access token generated against the credentials and utilizes it for all the services provided under the system.

Purpose of using SSO in N-Doptor

N-Doptor is a pioneering platform that aims to bring all processes of the Government System that can be automated under a single platform. As such, these programs will be inter-connected with each other to the extent that common information and core services are shared. As a result, it is in the interest of facilitating users of the system to provide a common credential. Consider the use case of Nothi as an example. We would need an application that can handle the files related to that. If we were to follow a traditional route, we would have a separate login id and password for Nothi. This would be more hassle for the users as they will have to remember an additional credential set and may lead to the case of password reuse, a dangerous security flaw. Additionally, it occupies extra data in our system and adds complexity to each individual service, which worsens the user experience. Thus, the usage of a Single Sign On makes it easier for individual users to interact with the service.

Advantages of SSO

There are numerous benefits to consider when we go for SSO in a platform like N-Doptor:

1. Centralization - The login management and authentication is handled independently of each individual application
2. Service Reusability - Since authentication is done centrally, each individual application or service does need an individual implementation of establishing credentials.
3. Reduced Password Fatigue - The end-users of the system do not require to remember separate login user_id and password for each application in the system, significantly reducing password fatigue and better user experience.
4. Faster Access - Activities related to the services available in the system are completed faster and are more efficient since credentials are not needed repeatedly for each service.
5. Enhanced Security - Redundancy is reduced for the users since there is only one account and one password. Thus the user can focus on creating one strong password instead of remembering many weak ones.
6. Increased Productivity - IT support is less frequently needed as there will be significantly fewer requests with resetting forgotten passwords or changing passwords since there are significantly fewer accounts and passwords in the system.
7. Shadow IT Prevention - This can be implemented using SSO to monitor employees’ activities on workplace servers, ensuring overall safety from cybercrime.

Explanation of SSO Functionality

SSO implementation can be implemented using different protocols. One such implementation is the usage of OpenID Connect (OIDC) with 0Auth2.0.

OpenID Connect (OIDC) is an authentication protocol that uses JSON Web Token (JWT), a type of token to validate and approve a login attempt. OAuth 2.0 Authorization Framework uses this OIDC protocol to help with authentication and authorization.

Authentication refers to verifying the identity of the user using credentials such as UserID and password. Authorization checks the rights administered to the user after they have been authenticated and grants access to resources accordingly. Once the authentication is completed, the process of authorization begins.

Once the user is authenticated by the SSO to gain access to a particular digital service, the SSO’s “Identity Provider” issues an Access Token, which serves as a “Identity” for the digital service to allow the user’s access. As a result, a user authentication solution is provided by an Identity Provider. This Identity Provider is a trusted provider that allows users to use the SSO to access different services and applications in the system.

We have also included a widget, i.e. a web component to assist with the login process and provide quick shortcuts to other features of the platform.

Al of these details fall under the implementation of SSO based on 0Auth2.0. OAuth is a simpler and more reliable way for users to allow you access to their resource data, as well as an easy way to publish and communicate with secured resource data. The credibility of this implementation is established because similar implementations have been taken by several tech giant companies for establishing SSO such as Google, Facebook, IBM, Microsoft, Salesforce, and Amazon.

Components of SSO in implementation

OAuth 2.0 with OpenID Connect

OAuth 2 is an authorization framework that allows apps to gain selective access to user accounts over a HTTP service. It operates by granting third-party applications access to the user account and delegating user authentication to the service that hosts the account. Authorization flows for online and desktop applications, as well as mobile devices, are provided by OAuth 2.

Roles of OAuth: OAuth defines four roles

OAuth 2 is an authorization framework that allows apps to gain selective access to user accounts over a HTTP service. It operates by granting third-party applications access to the user account and delegating user authentication to the service that hosts the account. Authorization flows for online and desktop applications, as well as mobile devices, are provided by OAuth 2.

1. Resource Owner - The user who authorizes an application to access their account is known as the resource owner. Access to the user’s account by the application is limited to the permissions given (eg. read or write access).
2. Resource Server - This hosts all the user accounts. From a development point of view, the Resource Server and Authorization Server’s roles are both utilized using a Service API and hence are collectively referred to as API role.
3. Authorization Server - This verifies the identities of the user and afterwards generates access tokens to use the applications.
4. Client - This is the application that wants to access the user’s data. Thus, it is the last stage of SSO since it has to be authorized by the Resource Owner and validated from the Authorization server.

Single Sign-On Widget

In general, a Widget is a self-contained web element that can be added to any website or software’s user interface to enable a set of functions.

All e-Services (Government Digital Services) connected to the N-Doptor SSO have an SSO Widget in their header. This allows users to transition from one connected program to another by using this widget. A screenshot of this widget interface is shown below.

Identity Provider / Identity Server

An identity provider (abbreviated as IDP) is a system entity that creates, maintains, and manages identity information for principals while providing authentication services to relying software systems within a distributed network. Identity providers offer user authentication as a service. Relying party software systems outsource the user authentication step to a trusted Identity Provider. In generic terms, an Identity Provider is a trusted provider that lets user to use single sign-on (SSO) to access other software systems.

An identity provider (IDP) is a part of the system that develops, retains, and handles identity information for principals while also delivering authentication services to relying software systems in the distributed network. User verification is offered as a feature by identity providers. The user authentication phase is outsourced to a trustworthy Identity Provider for the applications and services that require it. In simple terms, Identity Provider is a trustworthy provider that helps users to access other software services using single sign-on (SSO).

Basic Flow of SSO adopted in N-Doptor

SSO is broken down into the following steps:

1. The user will need to browse or visit the URL of a service provided by N-Doptor.
2. The user will be redirected to the Identity Provider Server (thus, Identity Server).
3. The user will type his or her username and password (therefore credentials).
4. The user will be authenticated by Identity Server.
5. The Identity Server will send a Token (JSON Web Token) with authentication information to the software framework.
6. The user will be redirected by the Software system to the landing page (therefore, Dashboard) after the authentication process is done.

Login, Logout, Session, and Token Management

As discussed above, the OAuth 2.0 Authorization Framework and OAuth 2.0 Bearer Token Usage specifications provide a general framework for third-party applications to obtain and use Access Tokens for access to resources. However, it falls short in defining standard methods of providing identity information. Without profiling 0Auth2.0, we are unable to provide authentication information of the users.

This is solved by the use of OpenID Connect, which implements authentication as an extension to the OAuth 2.0 authorization process. The use of this extension is requested by Clients through the inclusion of the OpenID scope value in the Authorization Request. Information about the authentication performed is returned in a JSON Web Token (JWT), also known as an ID Token.

Servers and clients using OpenID Connect are also known as OpenID Providers (OPs) and Relying Parties (RPs) respectively.

Multiple device login management

The SSO protocol with OpenID Connect is as follows

1. The RP (Client) sends a request to the OpenID Provider (OP).
2. The OP authenticates the End-User and obtains authorization.
3. The OP responds with an ID Token and usually an Access Token.
4. The RP can send a request with the Access Token to the UserInfo Endpoint.
5. The UserInfo Endpoint returns Claims about the End-User.

Under this Single-Sign-On process, the Identity Provider has a lookup function that provides a routing between the different services in the platform and this Identity Provider enables users to use the same password and authorization token to access multiple services. In particular, if various digital applications need different forms of authentication and login procedures, the Single-Sign-On mechanism simplifies the process by allowing for a single-way login.

Here, the process begins with the End User requesting a logout through clicking the appropriate button. The user agent then makes a call to the RP to end the user’s session, which corresponds accordingly and performs related tasks. The User Agent then calls the OP’s logout endpoint to terminate the user’s session as well.

Here, the process starts as before with the End User requesting a logout from the user agent. The User Agent corresponds by calling the OP’s logout function. Here, there is an iframe for each RP that is connected to the OP for the user. Each of these iframes will also call the logout URL to begin the logout process from each RP.

The logout process is again started by the end user by clicking the appropriate link. The OP’s logout function is then called by the User agent and the OP destroys the user session. Additionally, the OP calls the logout url of each RP having an active session corresponding to the end user. As a result, the logout function is carried out in all of the RPs.

Logout Management

To end a session in a desktop computer, the user can log out by simply closing the application or turning off the computer.

Log out can be both single-device logout or multi-device logout.

Session management

The method of securing several requests to a service from the same user or entity is known as session management. In certain instances, a session is initiated by checking a user or entity’s identity using factors such as a password. Following the user’s authentication, future requests authenticate the session rather than the user. After obtaining a JWT SSO token, it is parsed to a new field, and this is saved with the session along with the user in the persistent data storage.

Token Management

Users use OAuth to obtain access to a protected resource on behalf of the resource owner. In most cases, a customer must first receive an authorization grant from the resource owner before exchanging the authorization grant for an access token in order to access the protected resource. The distance, length, and other attributes provided by the authorization grant are represented by the access token. The user presents the authorization token to the resource server to gain access to the protected resource. In certain instances, a client can receive an access token without first obtaining an authorization grant from the resource owner by directly presenting its credentials to an authorization server.

Single Logout Integration

First, the session, sub, and username is stored in persistent data storage by parsing the JWT SSO Token received.

After that, sso_menu provided by script.2.min.js is integrated with the system.

Finally, an end point is created by making a POST API available that can be called by any IDP app to cancel user sessions from the SSO integrated applications.

Password Policy

The importance of passwords in computer protection cannot be overstated. They serve as the first line of defense for user accounts. Depending on how a network architecture is designed, a faulty password can lead to the whole network being hacked. As a result, all staff employees and users of the system are responsible for choosing and protecting their passwords in compliance with the protocols described below.

General Policy

1. At least once in every four months, all system-level passwords (e.g., root, enable, NT admin, server administration accounts, etc.) must be changed and updated.
2. At least once in every four months, all user-level passwords (e.g., email, web, desktop computer, etc.) must be changed and updated.
3. All production system-level passwords must be included in the InfoSec administered global password management database.
4. User accounts that have system-level privileges granted through group memberships or programs such as “sudo” must have a unique password from all other accounts held by that user.
5. Passwords are to be avoided from being used in electronic communications such as email and chat.
6. Where SNMP is used, the community strings must be defined as something other than the standard defaults of “public”, “private” and “system” and must be different from the passwords used to log in interactively. A keyed hash must be used where available (e.g., SNMPv2).
7. All passwords used in the system should follow these guidelines.

Guidelines for Password creation

1. Contain both upper and lower case characters (e.g., a-z, A-Z)
2. Have digits and punctuation characters as well as letters e.g., 0-9, !@#$%^&*()_+|~=\‘{}[]:”;’<>?,./)
3. Be at least eight alphanumeric characters long.
4. Is not a word in any language, slang, dialect, jargon, etc.
5. Are not based on personal information, names of family, etc.
6. Passwords should never be written down or stored on-line.

Try to create passwords that can be easily remembered. One way to do this is create a password based on a song title, affirmation, or other phrase. For example, the phrase might be: “This May Be One Way To Remember” and the password could be: “TmB1w2R!” or “Tmb1W>r~” or some other variation.

Password Protection Standards

1. Don’t reveal a password over the phone to anyone.
2. Don’t reveal a password in an email message
3. Don’t reveal a password to the boss
4. Don’t talk about a password in front of others
5. Don’t hint at the format of a password (e.g., “my family name”)
6. Don’t reveal a password on questionnaires or security forms

Application Development Standards

When developers are creating applications for the platform that include authentication using passwords, the following security measures must be taken:

1. Individual users, not groups, should be able to log-in to applications.
2. Passwords should not be stored in plain text or some format that is easy to reverse.
3. Whenever practicable, TACACS+, RADIUS, and/or X.509 with LDAP security retrieval should be supported.
4. The system should provide for some form of role management so that one user can take the role of another without explicitly requiring the password.

Passphrases

Passphrases are stronger versions of passwords as they include more characters and generally consist of multiple words. The same guidelines that are provided for passwords should be followed for passphrases as well.