Loading...
Der Autor des Artikels: Shadab Nawaz
Senior IAM Consultant
This white paper is aimed at discussing the introduction, evolution, need and benefits of Identity Federation and Single Sign-On. It also mentions different implementation strategies, key consideration and best practices.
Single Sign-On is a login concept that aims at providing a seamless user experience with logging into multiple enterprise applications with one set of credentials. It relies on a trusted identity provider for authentication and issues tokens that service providers use to grant access to various applications. This helps in reducing number of passwords to manage, reduces IT costs, improves productivity and login experience. This is implemented and enforced within the organization. Identity Federation is synonymous and complimentary concept to SSO having major difference that federation can be used across organizations, enabling application vendors and partners to connect and exchange information smoothly.
With the advent of technology and advancement in software, many enterprise applications were developed and are being used by a wide number of users in many organizations. This provides ease of access to users to perform their day-to-day activities. However, to access all such applications, user needs to create individual accounts on each application. Given the fact that these applications can and will hold sensitive information, it is evident that proper authentication mechanisms need to be implemented for all applications. As a result, users need to login to each application when they needed to use the application. With the increase in number of applications, it becomes difficult to manage and maintain login credentials for each application and users often ends up keeping same passwords for all applications. In few scenarios, it is easy to guess passwords for applications if someone just knows one password and nature of user, for example user keeps password like password@git, password@teams, etc. This posed a great security risk as this opened door for unauthorized access to many enterprise applications in organizations and unintended users can perform malicious activities resulting to data loss, reputational damage, financial penalty and loss of business.
A close to life example could be online banking experience. As a user, imagine you are asked to enter your username and password every time you want to check balance, transfer money to your family, view your personal details, view associated debit and credit card details, etc. This could be frustrating since the user is authenticated, has already logged in and now wants to perform legitimate and authorized activities but must enter his login details for each activity since it is equally important to protect and safeguard against unauthorized transactions. This presented a challenging situation for organizations and technical architects to develop a seamless user login experience with reduced number of logons while having secured authentication mechanism in place. This is where the idea of Single Sign-On came into existence. Over the period of time, SSO was being used effectively and had proven its efficiency and shown its benefits. As technology continued to grow, different organizations needed to work in collaboration and often needed common access to common data. A common example could be audits. When organizations need to be audited for regulatory and compliance checks, the auditor organization need access to organization being audited. This further ignited the idea of implementing SSO across organizations and Identity Federation came into existence. This allowed users to access data across organizations using same set of credentials. Of course, trust agreement has be created before this could hand, like SSO as we will see later.
There are few common terms that we will keep using over and again related to SSO and federation. Below is short description of each of the terms that would give some insight of the context.
Identity Provider is the source that provides the identity of the user who is accessing the service provider and sends user’ authentication data and access right for the service. Global IdPs include Google, Facebook and Apple while enterprise solutions like Microsoft Active Directory Federation Services (AD FS), Okta, Azure Active Directory.
A service provider is responsible to provide service to the user and get authentication data from IdP so that user can access the authorized content. Cloud services, web and enterprise applications are examples of SP.
A person who wants to use the service from the service provider.
A secured token containing user’s information. SAML assertions and JWT are common tokens.
An agreement must be established between IdP and SP to ensure that authentication tokens issued by IdP are accepted and trusted by SP to facilitate SSO.
Single Sign-On or SSO (as commonly referred) allows a user to sign on with one set of credentials and gain access to multiple applications within the organization. SSO improves safety and offers a better user experience by decreasing the number of necessary accounts and passwords. For example, Kerberos protocol allows automatic access of organization’s internal resources as soon as the user logs into computer. This can be advanced using federation and different vendor products like Workday, Zoom, Salesforce, etc. can be given access as well.
SSO end-to-end process can be broken down into individual steps as mentioned below
From the previous online banking example, all 10 steps are followed when logs into online banking and sees the dashboard. Now, if user wants to see balance, transfer money, view and update personal details, view associated debit and credit card details, etc., steps 4 and 5 are handled internally by the implemented SSO protocol and user doesn’t need to enter credentials multiple times, providing a seamless user experience.
Identity Federation, on the other hand, is used to have seamless authentication to a group of federated applications. This federation can include multiple organizations as needed and having a trust among them. In this case, the request is sent to a federation server and the federation server validates user credentials against the IdP. If the credentials are correct and user is authenticated, IdP issues an assertion which is passed via federation server to requested SP. The SP then validates and accepts the assertion and accordingly grants access to requested information for the user. Subsequent requests don’t require user to login again and rather uses the previously shared assertion to authenticate and grant access.
Identity Federation and SSO can be implemented via multiple protocols and standards as listed below.
SAML is an XML-based standard used for exchanging authentication and authorization data between an Identity Provider (IdP) and Service Provider (SP). It is an open standard supported by many IdPs and SPs and hence is compatible with different systems and platforms. It is widely used in enterprise environments.
Working model for SAML is same as described earlier. However, the key highlight is SAML Assertions and the way it works. There are three types of assertions commonly used
It is a framework for authorization, not authentication, often used to grant third-party applications access to user resources. This is commonly used in combination with OpenID Connect for SSO.
An authentication layer built on top of OAuth 2.0. It allows clients to verify the identity of the user and obtain basic profile information.
A network authentication protocol designed to provide strong authentication for client-server applications. It is widely used in corporate environments to securely authenticate users and services within network.
It must be noted that Kerberos protocol is only supported by SSO to provide access within the organization whereas SAML, OAuth and OpenID Connect can be used by both SSO and federation.
Though Federation and SSO look alike, there are few noteworthy and foundation differences between them
| Aspect | Identity Federation | Single Sign-On (SSO) |
|---|---|---|
| Scope | Cross-organizational, multi-domain | Single organization, single or multiple domains |
| Primary Function | Allow users from one domain to access resources in another | Allow users to log in once and access multiple applications within a domain or across domains |
| Trust Relationships | Establishes formal trust relationships between different IdPs | Often relies on a central IdP for a single organization, possible to have federated trust relationship |
| Dependency | SSO is needed for federation | Federation is not needed for SSO |
| User Management | Decentralized – each organization manages its own users and attributes | Centralized or semi-centralized – one entity (often within the same organization) manages user identities |
| Protocols | SAML, OAuth, OpenID Connect | SAML, OAuth, OpenID Connect, Kerberos |
| Data Sharing | Facilitates secure attribute sharing between organizations | Typically involves sharing user session data across applications within the same organization |
| Compliance | Requires adherence to agreements on data privacy and security across organizations | Usually needs to comply with internal policies and regulatory requirements relevant to the organization |
Using SSO for seamless experience has many benefits for organization as well as end users. Few of such benefits are discussed below –
By reducing number of passwords to manage, SSO empowers against compromised and shared passwords that are popular way for unauthorized access and breach. Users need to remember only one password. This also reduces inappropriate practices like writing down password, reusing same or similar password for applications by users.
Users don’t have to switch multiple passwords and sign on for different applications. Log in once and access all associated accounts smoothly.
Assume each user needs to login 10 times per day and each login takes 30 seconds. Basically, each user spends 5 minutes daily just to login into various applications without any productive output. This time seems insignificant but only if we consider that there are thousands of users in an organization and overall, the organization loses tens of thousands of productive minutes every day in to log into multiple applications. SSO reduces this time significantly and enables users to focus on tasks at hand rather than logging in several times.
IT team spends a huge portion of their time to address and resolve password related issues of users. Implementing SSO reduces number of passwords to manage and remember, eventually leading to less password related issues for IT team.
User access and authentication can be managed centrally instead of managing multiple application access individually.
IT team spends a huge portion of their time to address and resolve password related issues of users. Implementing SSO reduces number of passwords to manage and remember, eventually leading to less password related issues for IT team.
Verwendung von Cookies