‍Do you want your users to access multiple web apps, services, or domains seamlessly without having to engage in repeated login activity? If so, access federation is the solution for you. But what is access federation? In this article, we’ll explore this concept in detail.

Let’s imagine a scenario: You are working on an important project, so practically, to get the work done, you will need to access multiple applications (that are required to complete the project) throughout the day. However, you might come across a real issue while working on your project, i.e., every time you open a new app, you will have to re-enter your credentials.

Now, repeatedly re-authenticating your identity can quickly become frustrating. In fact, it will most likely consume time and disrupt the entire flow of work.

Fortunately, you can get rid of this hassle (escape the loop of re-authentication) simply by implementing the access federation. But how? Before addressing the ‘how’ part, you first need to understand access federation. So, let’s find out what it is.

What Is Access Federation?

Access federation is a framework that allows users to access multiple web apps or domains (both internally developed apps and apps managed by third-party providers) using a single set of credentials, eliminating the need to create and manage separate accounts for each app.

How Does Access Federation Make App Access Experience Seamless for Users? 

Access federation makes a seamless access experience possible by establishing a trusted relationship between the two main parties: service providers (SPs) and identity providers (IdPs).

• It builds this trusted foundation by creating a formal agreement in which both parties commit to following the same federation technical standards—the SAML 2.0 protocol, OAuth, or OpenID Connect—and secure practices for authentication and authorization purposes.

Also Read: What are the Generic Steps to Setup SAML?

• Also, since the service provider completely relies on the identity provider for authenticating user details, it requests IdPs to present a root certificate issued by a trusted certificate authority (this certificate demonstrates that the entity is practicing the right guidelines to share trustworthy details, aka proof of authenticity) – to gain trust.

Note: Access federation maintains users' data privacy and confidence by strictly prohibiting IdPs from sharing users' non-relevant personal or institutional data (i.e., data not required for authentication purposes) with SPs.

Now, let's understand how service providers and identity providers adhere to access federation during user authentication and authorization.

How Service Providers & Identity Providers Authenticate & Authorizes A User?

Below, we’ve outlined the steps involved in how service providers and identity providers perform authentication and authorization.

Step 1: When a user attempts to log in to an application (which is a service provider) using SSO, the SP directly redirects the user's browser to the identity provider's page.

Note: Sometimes, the SP requests the user to fill in a few details, which it then shares with the IdP for verification.

Step 2: The IdP requests the user to fill out a few necessary details (such as – name, email address, or organization name 'XYZ') for verification purposes.

Note: It even directly uses the SSO details to validate the user identity. If it uses SSO details, then step 3 will be eliminated from the process.

Step 3: Once the details are entered, IdP instantly validates the user's information (by checking its database and other sources).

Step 4: Upon successful verification, the IdP redirects the user's browser back to the service provider along with authentication token/SAML assertion (confirming the user is legitimate).

Note: The IdP only confirms that the user is legitimate; it does not disclose any additional data (such as the information the user provided upon the IdP's request or the sources the IdP used for verification).

Step 5: Since there is a trusted relationship between the IdP and SP, the service provider checks the assertion and immediately authorizes the user to access it without requesting the IdP to share further information or details about the authentication process.

Note: Organizations and third parties generally integrate Shibboleth (an open-source single sign-on solution) with their applications to simplify the federation authentication and authorization process.

However, a certain conflict sometimes occurs in the access federation, interrupting the authentication and authorization process. What is this conflict? Let's quickly find out.

How To Handle Synchronization Conflicts in Access Federation?

Sometimes, users tend to change their password multiple times in a short period (an instance of concurrent change). For example, the user updates their password in one region (e.g., Access Server 1)—like at the office using the office network. Before this update is fully synchronized, they update it again in another region (e.g., Access Server 2)—like at the office only but using a different network.

As a result, their information gets saved on two different access servers. This is where the problem/conflict occurs—which updated credentials need to be preferred for synchronization?

Before we understand how the conflict is addressed, you first need to clearly understand what an access server is.

• An access server is a middleman between SPs and IdPs. It helps both parties communicate securely during authentication and authorization.
• For example, the access server ensures that the SP gets confirmation about the user’s identity from the IdP without needing to interact directly with it.

On the other hand, the access server helps IdPs validate user credentials/details they have filled out (IdP relies on certain sources and databases to verify data, and the access server handles and updates those sources and data centers, which simply means that in order to validate user identity, IdPs have to interact with the access server).

Note: Multiple access servers (or nodes) exist in a distributed federation setup, often spread across different regions or data centers. These access servers ensure they are synchronized (that means the user data remains consistent (in sync) among all of them). For example, when a user updates their details (credentials) in one region (access server 1), that server sends the updated information to other access servers to maintain consistent and up-to-date data. This synchronization helps ensure that IdP gets the latest information to validate user identity when interacting with access servers.

Now, let's get back to how the conflict is addressed—when such conflicting updates arrive at an access server (e.g., different password changes from Access Server 1 and Access Server 2), the server uses timestamps to resolve the conflict (to determine which update to apply).

However, server clocks might not always be perfectly synchronized, so along with timestamps, the Access Server uses a time buffer (defined by the maximum-future-time-diff-millis parameter) as well to handle such conflicts. Here's how it works:

• If two updates arrive within the buffer period (e.g., 60 seconds), only the first update is applied, and the second is ignored.
• If an update arrives after the buffer period, it is accepted as the most recent and valid update.

For example:

• At 09:02:00:000, a password is changed to "abc."
• Around the same time, another source syncs the password as "def."
• If the second update arrives before 09:02:59:999, it's ignored, and "abc" remains.
• If the second update arrives after 09:03:00:000, "def" is accepted as the new password.

This approach ensures consistency across SP and IdP databases, avoiding conflicts during authentication.

Implement Access Federation To Support Seamless App Access Experience

If you as an organization want to provide your users with instant, seamless access to web applications, then implementing access federation is essential. It will establish a trusted relationship between service providers and identity providers, allowing your users to access apps effortlessly without having to repeatedly enter passwords or credentials to authenticate themselves.

But, while focusing on streamlining the app access experience for users, don't overlook securing your data and apps from unauthorized users. Because – what's the point of providing seamless access if it introduces vulnerabilities or opens the door to security incidents (that can compromise data security)?

Implementing an access management solution like Zluri, which will take care of the security aspect, can help you strike a balance between convenience and security.

Zluri's access management solution will help ensure that after authentication, your users are only granted precise access permissions (be it read-only, write-only, or full edit/delete access) suitable for their job role and nothing beyond.

This way, even if a malicious actor manages to steal a user's identity and log into an app, they will be granted only limited permissions. As a result, they will be unable to compromise sensitive data stored in other apps, omit data, or further perform any unauthorized actions.

How does it do that? It implements access control (you can add more policies as needed) like role-based, least privilege, and just-in-time access control and grants users the bare minimum access permission necessary for their role. At times, it even grants user access for a specific duration. This creates a secure environment for your sensitive data.

Also Read: Zluri's Comprehensive Approach to Sensitive Data Security

‍