Single Sign-On (SSO) for .NET

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."

Business Features

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 functionalities 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 / 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 / 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 a SSO session:

Login first - the user first logs in to the SSO infrastructure and then chooses a service to access.
Examples:

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

Application first - the user first tries to access a service, but because they have not yet been authenticated, they are redirected to the login service. After a successful logon they are redirected back to the service.
Examples:

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/or web.

Expected Benefits

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 administration 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 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:

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
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 of time, 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 uniquely identify each user session)
- 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
- Attributes
- Roles
- Permissions
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.

Different front-ends can be used according to your needs :

When an SSO session is based on a Windows session, the standard Windows login window will be used
A ready-to-use login window is provided for Windows applications developed in .NET. We can, for example, use this window when multiple account types are supported by the SSO security system: the user can choose the type of account before entering their credentials

Read more about the Visual Guard WinConsole...
A web portal is also provided out-of-the-box to manage SSO user authentication. This portal can simultaneously support multiple types of authentication: the user will indicate the type of account, enter their credentials and then access all websites

Read more about the Visual Guard WebConsole...
Finally, each application can have a custom front-end that will call the Visual Guard APIs to authenticate a user

Back-end functionalities are assured by different components, depending on the kind of application secured (Windows or web, ASP.NET or other technologies…). All these components are ready to use and are created to communicate with the Visual Guard repository, which centralizes the user accounts and access rights
Integration with .NET applications is done by adding a run-time (.NET assemblies) to the application. This integration doesn’t require any modification of the application aside from the call to this run-time to activate the security mechanisms
Applications based on other technologies call WebServices exposed by Visual Guard to authenticate the users and obtain their roles and permissions

Complex Configurations

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.
Accounts are not all stored in the same network as the SSO system
Example: Independent entities use the same application, but each manage their own Active Directory
- The application administrator need 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
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.
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...

Reference Sources

Hint: For improved responsiveness ensure Javascript is enabled and choose 'Normal' from the Layout dropdown and hit 'Update'.
You must Sign In to use this message board.

Search
	Per page