Identity management is vitally important in cybersecurity. Every time someone tries to access your networks, systems, or resources, it’s critical that you are verifying that these attempts are valid and legitimate, and that they match a real, authenticated user. The way that this tends to be handled in cyber security is through Identity and Access Management (IAM), most commonly by using third-party Identity Providers (IdPs). After all, these IdPs are highly effective at their job of verifying users, and offer robust security defenses against attempted attacks. However, just like all third-party tools, they still carry security risks – and the fact that they are managed by a third party means that these options seem somewhat incompatible with zero trust architecture (given that you’re handing over control of your IAM to an external organization).

In this article, I’ll explore an original and robust method for using third-party IdPs that allows you to maintain a zero trust security posture, thanks to Extra Factor Authentication.  I’ll highlight the benefits of IdPs and explore the severe risks of ‘legitimate’ backdoors they pose, and give you a step-by-step framework that we used to implement an extra layer of control and authentication in our internal SSO (as a bonus, we’ll also share this implementation, which we offer to the community as a snap).

What is Identity and Access Management (IAM)?

IAM is a security framework that ensures that only legitimate and approved users, machines, or individuals can access resources. It verifies users and checks their credentials before allowing access to machines, networks, databases, or systems. Through this process,  IAM prevents unauthorized access and reduces the risk of fraud, leaks, or breaches.

Why is IAM important?

The risks of poor IAM and access control are all too obvious. 

In 2024, companies worldwide lost nearly $4.4 billion in fines for data breaches. Research from Verizon shows that 80% of data breaches stem from attackers guessing or stealing weak passwords; similarly, 61% of all breaches happen because a bad guy was tampering with credentials. In fact, data from CrowdStrike indicates that identity-based breaches account for 80% of cyberattacks. All in all, the numbers show that poor access control is often at the root of breaches.

For most use cases, third-party Identity Providers (IdP) offer an easy-to-implement, hands-free, and generally reliable way to manage your organization’s access control without needing to build it from the ground up yourself. 

What is an IDP?

An Identity Provider (IdP) is a service that manages user authentication and access to applications, networks, or systems within a distributed network. IdPs create and manage all the information used in accessing systems belonging to an organization. Third-party IdPs, (for example Okta, or the Google Identity Platform) allow organizations to outsource and streamline their identity management to a trusted third party, who manages user identities and credentials, and authenticates requests to access organizational resources. 

Typically, these work by:

• Receiving an access request from a user or entity, 
• Checking that user’s credentials against a secure database of verified and authorized entities, 
• Assessing their permissions to access the requested network, system, or resource, 
• And then granting or denying access.

SSOs are a collection of technologies that allows network users to provide a single set of credentials for all network services (rather than having a different log-in for each), and today they’re widely used in IAM: roughly 70% of organizations have either implemented a Single Sign-On (SSO) solution or are planning to. You can read more about how they streamline IAM in our help knowledge base article about SSOs.

The benefits of third-party identity providers

Third-party IdPs are very popular with large organizations for a number of reasons. 

1. IdPs are easy to use
   IdPs can be rolled out at scale to give organizations one single place to manage access to any number of websites, databases, or resources. This has two benefits: first, users no longer need to remember multiple passwords, reuse passwords, or create weak passwords; and second, it makes it easy to secure your systems and resources at scale. 

2. IdPs enhance your security
   IdPs often come with features like multi-factor authentication (MFA), detailed events analysis, adaptive authentication, and powerful heuristics and attack detection capabilities, which makes it much harder for unauthorized users to get access.

3. IdPs free up developer resources
   IAM systems can be incredibly challenging to build by yourself, and time-consuming to manage at all hours of the day. By using these third-party IdPs, you no longer need dedicated internal resources to do it, allowing your developers to focus on mission-critical work.

The risks of third-party identity providers

As with all third-party tools you do not control, there are always risks. 

Beyond the obvious risks of unseen gaps,flaws or attack vectors in these third-party tools, there’s a new and frightening risk of using them: a backdoor into your resources. 

Backdoors into your resources, networks, or systems can happen in several ways. 

1. An unauthorized account is added to your databases
2. An account’s credentials (username, password, access token, machine, etc) are stolen or spoofed
3. A rogue employee or IdP admin creates backdoor access
4. Seemingly “legitimate” users are added to access databases. For example, IdPs might create a backdoor of their own, or be forced by courts of governments to create a “legitimate” backdoor

Normally, audits and access controls exist in abundance to ensure that the first three attack points do not occur. 

However, the fourth on the list is a growing threat that’s happening more and more frequently. Recently, the FBI demanded a backdoor into iPhones, and the UK government secretly ordered Apple to build a backdoor that would give it access to users’ encrypted iCloud data.

If a court order adds an “employee” to your database, or impersonates a privileged user, then your use of IdP is no longer a defense layer but instead an attack vector, and worse, an attack vector with privileged access, where even traditional additional layers like 2FA or MFA will not provide protection. Given this risk, you can see how many cybersecurity experts see third-party IdPs as incompatible with Zero Trust Security (ZTS).

What is Zero Trust Security

Zero Trust Security is a relatively new approach to cybersecurity. With ZTS, the system by default does not trust any user, application, service, request, or entity; Instead, every request for access is checked and authenticated when it happens, regardless of who made the request or where it came from. For this reason, ZTS is the growing gold standard in cybersecurity, as it offers the most robust security posture at all moments against attack attempts.

However, this onerous scrutiny and readiness comes at a cost: it may preclude the use of third-party tools (as these are outside of the organization’s full control) and may require intensive developer efforts to sustain, as if third-party tools are off the table, then the work is shifted in-house.

This means that ZTS often carries additional burdens in terms of time, cost, efforts, and resource requirements. As a result, a balanced approach that allows simultaneous use of third-party tools and zero trust systems is highly desirable for organizations looking to maximize their security and minimize the costs of doing so. In the next section, I will outline how we at Canonical implemented ZTS into our IdP usage to get the best of both worlds.

How to implement ZTS into your third-party IdP

Your typical IAM flow works like this: 

• Someone tries to log in to your service
• Their request is passed to the IdP
• They do their normal login
• They pass some form of 2FA or MFA
• They get a go/no-go response, and are allowed or blocked 

In Canonical’s implementation of the IdP loop, we implement an extra step:  a passkey stored by your organization (which we are referring to as ‘Extra Factor Authentication’). This happens outside of the IdP loop – and so the third-party provider isn’t even aware that it’s happening. The normal authentication flow happens, but when the go/no-go returns from the IdP,  you prompt for this extra factor. If the user returns an enrolled passkey, we are able to verify that that person is legitimate, and give them access to the system.

You can do this in a number of ways, using multiple potential open source components. With our internal IAM solution, we made use of the following identity management projects:

• Auth0 OpenFGA (for permission management)
• Ory Hydra (as the OAuth server)
• Ory Kratos (for authentication / user management)

This stack allows us to self-host our own SSO, which redirects to a third-party IdP, before coming back to us for the final passkey verification. 

If you’d like to explore this tool for your own use, you can access it on our Charm hub, where we have packaged these tools into a set of Juju charms (Canonical‘s version of Kubernetes operators).

The benefits of Canonical’s hybrid Zero Trust IdP model

Our hybrid implementation of ZTS and IdPs comes with several benefits. 

1. You get the benefits and protections of third-party IdPs. IdPs offer robust protections against the vast majority of attack attempts, and so you can enjoy these protections, combined with the ease-of-use and scalability of IdPs.
   
2. You retain full control over access permission. By retaining full control over the authorization decision, you effectively eliminate the risk of “legitimate” backdoors created by your IdP.
   
3. Extra Factor Authentication offers an additional security layer. Our implementation offers an additional layer of authentication and access control in your IAM, making it much harder for attackers or unauthorized users to access your systems, networks, or resources.

In conclusion, IAM is a tricky and time-consuming process, and modern third-party IdPs offer a powerful and reliable way to outsource this activity securely, for the most part. However, risks still exist with IdPs, meaning that if you want to implement Zero Trust Architecture into your IAM you need to take extra precautions so that you’re protected from both unwanted intruders and the third-party IdPs themselves. With just one simple additional verification step, you get the best of both worlds: all the benefits of third party IdPs, none of the potential black box back doors, and a solid Zero Trust outlook. 

If you’d like to explore our IAM implementation for yourself, then visit the official charm on our Charm Hub.

Further reading

Google Authd broker: authenticate to Ubuntu Desktop/Server with your Google account

Entra ID authentication on Ubuntu at scale with Landscape

Announcing Authd: OIDC authentication for Ubuntu Desktop and Serve

Explore more Canonical blogs about Identity Management