Implement Single Sign-On (SSO)
Why this article?
This article lists all the important points to take into account when creating a Single Sign-On system. The principle of SSO may seem simple to explain, but in reality, it implies numerous functionalities that are important to take into account from the beginning of a project to avoid very costly changes later.
Additionally, your system may need to support certain complex technical specifications – listed below – that will add to the functional complexity.
Finally, we will compare these specifications to Visual Guard, a readily available solution that provides these security functionalities “out-of-the-box”.
The objective of SSO is to allow users access to all applications with a single account. It provides a unified mechanism to manage the authentication of users and determine user access to applications and data.
The principal features of an SSO system are as follows:
- A limit of 1 account per user to control access to several applications or websites
- User logs in once and gains access to all applications or websites without being prompted to log in again at each of them.
- Memorization of all or a part of the user’s credentials so they don’t need to re-enter them on their next visit (for example, login and password)
- Single Sign-off: a single action of signing out terminates access to multiple applications or websites. By default, each application will verify that the session managed by the SSO system is active before giving the user access to the requested pages. If needed, each application can also manage its own timeout independently. For example, if a user left website A XX minutes ago, they will need to reconnect to consult website A, even if the session continues uninterrupted on other sites.
For Visual Guard:
The functionalities listed above are available for Windows applications, websites and web services.
In addition to these functionalities, Visual Guard allows you to federate sites that support different types of user accounts:
- User accounts from each site are translated to a common format specific to Visual Guard
- The users from each site continue to use their initial account with the same credentials
- They can access other sites that do not initially support this type of account
There are two common scenarios for an SSO session:
- Login First: the user first logs into the SSO infrastructure and then chooses a service to access.
Application First: the user first tries to access a service, but because he hasn't yet been authenticated, he is redirected to the login service. After a successful logon he is redirected back to the service.
- SSO based on the user's Windows account. The session begins with the Windows Login and continues until the locking or stopping of the computer
- SSO via multiple websites: for a normal registered user of the services proposed by the websites. In this case, Login First makes sense because the user knows they need the services secured by the SSO
- SSO based on a user’s Windows account, with a high level of security that does not allow the session to stay open as long as the Windows session. The user must authenticate to access the service. The maximum length of the session is defined by the SSO system, and not by the Windows session
- SSO across multiple websites: the user is able to navigate across the sites, and must authenticate to perform certain operations. You often see this on e-business websites, where the user is asked to authenticate as late in their visit as possible to avoid creating obstacles to the visit.
With Visual Guard, these two scenarios are supported, for both Windows applications and web.
Single Sign-On will, of course, simplify the life of the users, but you can expect much more:
- Improved user productivity: users don’t re-enter multiple logins, and they are not required to remember multiple IDs and passwords for the same identity.
- Reduced IT costs: lower number of IT help desk calls; fewer requests to reset forgotten passwords
- Improved developer productivity: SSO provides developers with a common authentication framework. In fact, if the SSO mechanism is independent, then developers don't have to worry about authentication at all. They can assume that once a request for an application is accompanied by a username, then authentication has already taken place.
- Mixed-mode authentication: supports various authentication mechanisms like Windows (Kerberos), LDAP, R/DBMS, etc.
- Simplified administration: when applications participate in a single sign-on protocol, the administrative burden of managing user accounts is simplified. The degree of simplification depends on the applications as SSO only deals with authentication. Applications may still require user-specific attributes (such as access privileges) to be set up.
- Control & Audit: centralized reporting for compliance adherence.
- Improved Security:
- Reduces phishing success, because users are not trained to enter passwords everywhere without thinking.
- There is only one place of authentication, which receives user's credentials. The applications only receive information about whether they may let the user in or not. Also, the user authenticates only once, so there is a minimum transfer of sensitive information over the network, not to mention that SSO systems usually force the users to use secure communication channels.
For Visual Guard:
The above benefits are available and extend to the implementation of applicative permissions. Access rights are defined by administrators and centralized in a repository with the user accounts. They are then automatically provided to an application once a user is authenticated.
Technical Features - Main Components:
The main functionalities and technical components provided by an SSO system are as follows:
1 – A front-end that allows:
- Users to identify themselves and to memorize all or a part of their credentials via a login window or web portal (see the previous chapter)
- For Web SSO, the front-end will automatically redirect users that navigate between federated sites. The user will immediately arrive at each new site having been correctly authenticated and secured, transparently and automatically
2 – A back-end that will manage the authentication and the user session:
- The system provides a centralized authentication server that all applications and websites use for authentication purposes
- The user first authenticates to a trusted authentication authority - the SSO system - and is then granted access to all the applications trusting that authority
- The SSO system preserves the state of the user for a period, so the user may repeatedly access the applications/websites without needing to authenticate each time
In particular, for Web SSO, this will include the following functionalities:
A/ Identify the user
- Create the security token (a token that allows the security system to identify each user session uniquely)
- Transfer the token to the visited sites
- Verify that the token has not been intercepted (identity theft)
- Scalability: facilitate the performance. If each page viewed requires the re-authentication of a user and the reloading of their security, the system will encounter performance problems
B/ Load the user's security data
3 – An application integration solution for the SSO system:
- SSO integration should not impose significant modifications to the application.
- The integration process should be the same no matter the type of application or development technology used.
- SSO is often used by developers who did not create the solutions. Therefore, corresponding documentation should be provided.
For Visual Guard:
VG provides a coherent authentication strategy and framework for all applications and websites secured by the system.
Read more about Visual Guard's Technical Features...
1 – User sites are not all on the same network:
Example: an organization made up of multiple sites/subsidiaries/agencies
- Users are spread across multiple separate locations
- They are using Windows or Web applications, for example, an application developed with ASP.NET
- A centralized repository contains all security data
You need to plan to transport identities between the repository and the distant sites – simple for login/password type accounts, but more complex for Windows accounts.
2 – Accounts are not all stored in the same network as the SSO system
Example: Independent entities use the same application, but each manages their own Active Directory
- The application administrator needs to be able to give access rights to user accounts managed by a system to which they do not have access (in this case AD)
- The SSO system must be able to verify the credentials provided by a user at a distance
- The SSO system should not degrade the performance of the application, even with the significant constraints of networks at communication
3 – Not all sites are in the same Internet domain
Example: SSO federates websites managed by independent partners or distinct entities.
By default, web browser security does not allow different websites to share the same cookie to store information about a user or their session. You, therefore, need to create a solution that solves this problem.
4 – Applications and websites are not all developed with the same technology
Example: an organization manages multiple generations of application, each developed with a different technology (for example, ASP.NET, Java, etc..).
- Users should be able to access all applications with a single account
- The SSO system will centralize all the security data from these applications
- You should guarantee the interoperability of the authentication systems and security token management with all development technologies concerned (.NET, C++, Java, etc…)
More about Visual Guard Web SSO
With the VG WebPortal, a user of multiple
websites secured by Visual Guard will log in when they enter the
first site. They can then directly access other websites, without
re-entering their credentials (assuming, of course, that their permissions
allow the user to access the other sites)
- A user can begin their session with any site secured by the
- An unlimited number of websites can be federated with this system.
- Websites can be located on different servers or networks.
- This system provides SSO features for username/password accounts.
- For Windows accounts, SSO features are automatically made available
by Visual Guard without the VG WebPortal (Active Directory is
used instead). In case of multiple Active Directories located
on different networks, VG provides Identity Federation features.
- You can adapt the layout of the VG Web Portal to comply with
corporate presentation standards
1. Administrators manage users, groups, and roles with a Console and update the VG Repository.
2. When the user enters a website, they are automatically
redirected to the authentication website, where a login form
allows them to enter their credentials.
Once authenticated, the user automatically accesses the initial
3. When the user goes to access another website,
the system automatically goes through the authentication website
to verify the user’s access rights and then comes back
to the page requested by the user. As a result, the user can
automatically access the website without providing their credentials
Try Visual Guard