Architecture for Single Sign-On (SSO) and Identity Provider
A Single Sign-on (SSO) system allows a user to perform a single authentication valid for multiple software systems or IT resources for which he is enabled and authorized.
Endless new applications and software, digitization of all processes and decentralized systems are becoming more common and authentication is an essential aspect of all of them. SSO solves a big problem: how to manage the growing number of users across an entire ecosystem of applications and services.
The goals are multiple:
- Simplify the management of access to the various services
- Unify password management
- Improving omnichannel - Simplify the definition and management of security policies
- Access to restricted and reserved areas
- Improve the management of groups and user categorization
- Centralize acceptance and compliance with corporate policies - Improve user experience
- Have a single access panel for all applications used
- Have a single login experience across all enterprise systems
- Provide greater sense of security
Possible information management solutions and policies
There are three approaches to building an SSO system: the centralized approach, the federated approach, and the cooperative approach:
Centralized approach
The principle is to have a global and centralized database of all users and centralize the security policy in the same way. This approach is primarily intended for services that all depend on the same entity, such as within a company.
Federative approach
With this approach, different managers (“federated” with each other) manage data of the same user. Access to one of the federated systems automatically allows access to all other systems.
A traveler could be either an airplane passenger or a hotel guest. If the airline and the hotel used a federated approach, they could enter into a mutual agreement on end-user authentication. For example, the traveler could authenticate himself to book the flight and be authorized, by virtue of that authentication alone, to book the hotel room.
This approach was developed to respond to a need for decentralized user management: each federated manager maintains control of its own security policy.
Cooperative approach
The cooperative approach starts from the principle that each user depends, for each service, on only one of the cooperating managers. In this way, if you try, for example, to access the local network, authentication is performed by the manager who takes care of the user for accessing the network.
As with the federation approach, each manager independently manages its own security policy.
The cooperative approach responds to the needs of institutional structures in which users depend on an entity, such as universities, research laboratories, administrations, etc.
First you enter from a single gate and then you move on to the other portals. You will never be able to access directly from the single portal.
Architecture without SSO
- The user to access each application needs to login each time with a different process
- Each application has its own management of user data, the rules applied to them and software maintenance
- The IT manager of the company needs to access different platforms with different processes to change permissions or user groups
Architecture with SSO
- The user to access each application uses a single login procedure
- The user uses only one process to manage their account
- All applications will have: user data, the rules applied to them and the maintenance of the software centralized in a single platform
- Compatibility between application and SSO is ensured by SSO
- Cybersecurity is centralized in one solution, so it’s easier to maintain
SSO DevOps architecture
- In the DevOps SSO architecture, each application has a proprietary system that is independent from the others
- Each application might have its own protocol for accessing SSO like: OpenID Connect, Facebook Connect, SAML, Microsoft Account (formerly known as Passport), etc
- We could find different systems such as: local server, cloud system or scalable cloud system. For this type of architect it is not a problem but it is normal
- This system will allow you to add a new application without any problems. Simply set up an SSO application to receive a new application request
- Each application will point to the single SSO system to authenticate its users
SSO process and architecture
The diagram below shows a simple SSO system integration process using the SAML protocol.
What is an identity provider (IdP)?
An identity provider (IdP) stores and manages users’ digital identities.
It is a list of users with details about them. It adds information such as roles, membership groups and …
How do identity provider work with SSO services?
There are different packages or interactions between SSO and IdP.
A simple example is shown to understand the process step by step.
- The user authenticates in an application
- SSO will retrieve the user’s identity
- The Identity Provider passes user information to SSO
- SSO return the user information to Application
- The application understands who the user is and what their role or group is
- The application only enables functions to which the user has access
Considerations and useful advice
Choosing a native SSO software for one of the chosen platforms in the entire enterprise digitization architecture would be ideal, in order to centralize the management of costs and resources.
Understand if and how many systems/software can integrate with the centralized SSO system with: plugins, SAML and other protocols. If the number is negligible, its implementation would not be worth it.
The first choice should be, where possible, the SSO system of the CRM since it is the centralizer of all master data.
Possible standard SSO solutions
Below is a list of the most used SSO providers:
- Hubspot
- Auth0
- Okta
- OneLogin
- Microsoft Azure
(Date of the list 31/07/2023)
Insights?
If you have any questions or corrections, please contact me.
Document version
Version: 1.1 — Last update: 06/08/2023 — Author: Corrado Facchini
