Deprovisioning: SSOs vs. Zluri

When SSOs came into the market, companies adopted them over the then-existing password-based systems for two reasons.

The first was the ease of use. Users had to remember only one set of usernames & passwords (for signing into the SSO) rather than separate credentials for each application, as was the case with password-based systems.

Once users logged in to an SSO, it allowed them to sign in to all the apps they've access to without any username and password.

The second advantage of SSOs over password-based systems was on the security front. They were more secure than password-based systems.

Let's see how.

Security: Password-based Systems vs. SSO

Password-based systems count on the human ability to remember complex passwords. This is because the makers of these systems expect the passwords to be complex and users to remember them at the same time.

But the problem for users is that if they use complex passwords, then it's difficult to remember them. And if users want to remember many credentials, they need to keep these usernames and passwords simple. These opposing factors make all the password-based systems inherently weak.

In practice, users set the same password for each of their accounts or its slightly modified version. The problem with this is if their password is compromised for any reason, the hacker will have access to all the applications with the same password.

However, an SSO requires users to remember just one complex password. Once users sign in to SSO, they don't need a separate password for signing in to apps. Consequently, an SSO resolves the problem of accounts compromisation as there's no concept of passwords at all.

Reasons for growth of SSO

How do SSOs Work?

Before moving ahead, let's understand two important terms required for understanding how SSOs work—authentication and authorization.

Authentication is the process or action of verifying the identity of a user or process. Authorization is the process of checking if a user has permission to access a specific resource or function.

Now since you understand authentication and authorization, let's discuss the working principle of SSOs.

SSOs can be divided into two parts: Authentication and authorization.

Whenever users try to sign in to an application, SSOs need an identification source to validate them. Often, SSOs offload this part to an identity provider (IDP).

SSOs either have their own IDP, or they connect with external IDP for authentication.

For instance, take Okta. Though it has its own IDP, the companies that use it cannot use the internal IDP of Okta. Instead, they can use a third-party IDP, such as Microsoft Azure or Google Workspace.

The second part of an SSO is called authorization. After the IDP authenticates a user, SSOs check whether users have access to the application or not. And if yes, then what level of permissions does the user have.

When an IT administrator gives users access to an application using SSO, that same access is stored in the application as well.

Hence, when the users try to access the application, say Zoom, the SSO will check in its own database first if the user has access to Zoom. Additionally, the SSO will also check with Zoom whether the user has access to it or not.

The first time the video conferencing app says that the user has access, the SSO will redirect the user to the app, and they can start using the app.

Moreover, when the user tries to access Zoom, he/she will be directly connected to the app—without the need to go through the entire cycle again—until the current session expires.

For the majority of apps, a session duration can range from one hour to infinity.

Depending on the device, there are different types of authorizations.

Sessions on mobile devices are called tokens, and apps can have different refresh cycles for tokens.

SSO Flow

Before reading further, I suggest making sure that you understand the SSO flow because the next set of discussions is based on SSO working.

Problems with SSOs

Though SSOs have been a great step forward from license key and password-based models, there are major problems with SSOs.

I've discussed them below.

Problem #1: SSOs are Not that Prevalent

• Setup requires high effort from the application provider's end. Even though the SSO helps in quick access to apps, it's a huge job to configure SSO for each of them. Ensuring their app is compatible with SSOs requires a good amount of time and effort on the application developers' end. Besides, there are many standards (such as LDAP, CAS, SAML 1.0 and 2.0, and Auth 1.0 and 2.0) and vendors of SSOs. What makes the problem worse is that every vendor is trying to come up with their own standards or supports only a few other standards, leading to compatibility issues.
• SSOs are given in the highest pricing tier by app providers. Most app vendors provide SSO in their highest pricing tier. This is understandable. Since an application provider needs to spend a good amount of time configuring different SSOs, they want to recoup that amount.

Since the app developers have the overhead of configuring different SSOs, only a few app providers are able to integrate with all the SSO systems.

Even if the app provider is able to do it, they offer SSO in their priciest or enterprise plan making this feature out of reach of many users.

These are the main reasons behind the coverage of the SSO being very low.

Problem #2: Issues while Deprovisioning

As I've explained in the working principle of SSO, once authentication and authorization are done, a connection with the app is established, which continues for a particular duration, called a session.

Then the user can perform different tasks on the app without needing to go through the whole process each time until the session expires.

In most cases with general configuration, this session is controlled by the application and not the SSO. In fact, the application can override SSOs in many cases.

SSOs can suggest how long an app should retain the authorization or the session duration, but they cannot dictate.

It leads to the following problems:

• Access to the application even after deprovisioning. Imagine you sign in to HubSpot with Google Workspace. And let's say that HubSpot keeps your session active for 30 days. Now, if you leave the company on Day 10, your session will remain alive for the next 20 days, even after your access to the HubSpot is removed via SSO.

• The session is active even after deprovisioning the userHubSpot won't authenticate the user with the SSO again because the session is valid for the next 20 days. Therefore, while the IT administrators will think that you don't have access to the HubSpot after day 10, in reality, you do have access for another 20 days. This is the case when the session duration is defined to be 30 days by the application. For apps with infinite session duration, you'll have access to the app forever.
• 🛑 Even if a user has been deprovisioned using SSO, there is a chance that the user can continue using the application forever.
• Also, we've been informed earlier that sessions on mobile devices are called tokens. Even if a user session is broken manually by removing licenses, these device sessions can still be retained for mobile devices.
• Data loss during deprovisioning users with SSO. What happens to a user's data after his/her access is revoked to an app? It's the company's data, and hence it must be preserved in some form. The data can be transferred to another user who can keep working on the project, or if the project is completed, a backup must be taken of the data so that it can be stored and retrieved when required. Unfortunately, most of the SSOs don't do this.

How to Deprovision the Right Way

We at Zluri have found that the root cause of these issues is that SSOs don't integrate with applications deeply. Hence, we integrate Zluri with apps at a much deeper level using APIs so that we can communicate with apps directly.

These integrations are called direct integrations, and we've integrated over 300 such applications. In addition, you can reach out to us if you want a custom integration with any other app.

Zluri: The Proper Way of Deprovisioning

Deprovisioning via Zluri can be done with ease with a single click. In the back, the following four steps take place:

1. Remove access to devices: To begin with, we revoke the authentication from all the devices. So, if a user is signed in on three devices, the user can't access the app from any of these devices.
2. Data backup: Then, we transfer the data to another user or take a backup of the data. So, no data loss happens even though revoking the access is so easy from the admin perspective.
3. Revoke the user license: Further, Zluri returns to the application and removes the user because all the data has already been transferred.
4. Remove SSO: Finally, we remove the SSO as well.

During deprovisioning, Zluri doesn't stop at SSO level authorization. It monitors the usage of the SSO system as well. For example, it monitors users for which apps they have access to, what level of permissions they have for the apps, their sign-in logs, audit logs, and access logs.

If a user still has access to any app or has not been removed (in rare cases), Zluri alerts you that the user can still use the application.

Zluri vs. SSOs: Though Zluri takes some inputs from SSO, such as sign-in information, for Zluri, SSOs are not mandatory.

The core value of Zluri comes from the fact that it connects directly with the applications. Thus, we get data directly from the source of truth.

As a result of the direct communication with apps, we can pull information that SSOs can't.

We go a couple of more steps beyond the SSOs. We can do certain things much better, focusing only on what we do. We don't do authentication. We don't do authorization, but we primarily understand how the system is being used.

We understand how to properly deprovision or provision users. Zluri is better than SSO in provisioning and deprovisioning because, with SSO, you just get access to surface-level data while Zluri can go directly to the application.

For example, if an IT admin wants to give you access to Slack, apart from giving access to Slack and the license, he/she can automatically add you to channels, give you roles, and add you to groups.

In short, Zluri helps to secure your apps and data and automate IT tasks better than all the other tools because we have direct connections with SaaS apps.

Book a Demo