Diving into Zanzibar

Zanzibar is a globally distributed, purpose-built, large-scale modern authorisation system developed by Google presented by Auth0 for YouTube, Drive, Google Cloud and all of Google’s Products.

Zanzibar employs a relationship-based access control (ReBAC) model, where permissions are determined by relationships between users and resources represented in a directed graph. This approach allows for flexible and granular access control, supporting various authorization models like role-based access control (RBAC) and attribute-based access control (ABAC)​.

But before going any further to understand why and how, let us read on to understand a fundamental principle of security — what are access control models and see how they compare with each other.

Access Control Models:

An access control model is a framework that determines how users (people or systems) can interact with resources (files, data, applications) in a system. It defines the rules and policies that specify who can access what, under what conditions, and what actions they are allowed to perform.

Key Concepts in Access Control Models

1. Users: Individuals or systems that request access to resources.
2. Resources: The data, files, applications, or systems that need to be protected.
3. Permissions: The actions that users can perform on resources (e.g., read, write, delete).
4. Policies: Rules that define how permissions are granted or denied.

Understanding Access Control Models:

Role Based Access Control (RBAC): Assigns permissions based on user roles
e.g. An employee assigned to the “Manager” role has access to manage team schedules and approve requests.

Attribute Based Access Control (ABAC): Uses attributes (user, resource, environment) for decisions
e.g. A user can access a document if they are in the “Sales” department and it is within business hours.

Relationship Based Access Control (ReBAC):
Access based on relationships between entities
e.g. A user can edit a document if they are the owner or if the owner has shared it with them.

Policy Based Access Control (PBAC): Centralized policies define access rules
e.g. A user can access the network if they are on a corporate device and within the office network during working hours.

Coming back to Zanzibar, first of all why should we care about Zanzibar?

Because Authorisation is the next big challenge. With that out of the window, I’ll proceed by first clearing a few questions my team-mates had when this topic popped up in our discussions and then understanding how we leverage it.

Q1: Why do we need Zanzibar when we have OAuth2?

OAuth2 and Zanzibar serve different purposes within the realm of authorization and access control, and their use cases and functionalities are distinct.

OAuth2 is primarily an authorization framework that allows third-party applications to obtain limited access to a user’s resources without exposing the user’s credentials. It defines a protocol for token-based authorization.

Zanzibar on the other hand, is a comprehensive, global authorization system designed to manage and enforce complex access control policies across a massive scale.

Use Cases

OAuth2:

• Ideal for scenarios where user consent and delegation are needed, such as social logins, API access for third-party applications, and resource sharing between services.
• Example: A user logging into a third-party application using their Google account.

Zanzibar:

• Suitable for complex internal authorization requirements within an organization, where access control needs to be managed across multiple services and resources with intricate policies.
• Example: Managing access to documents in Google Drive, where permissions can vary at a granular level (e.g., read, write, share).

Zanzibar addresses the need for a scalable, consistent, and flexible access control system for complex, large-scale environments. Organizations with intricate authorization requirements and a need for high-performance access control checks would benefit from using Zanzibar in conjunction with OAuth2 for different layers of their security architecture.

Q2: How do you compare KeyCloak with Zanzibar?

Zanzibar and Keycloak serve different purposes in the access management realm:

• Zanzibar is an authorization system that focuses on determining whether a user has access to a specific resource. It uses a relationship-based model to define access control and offers strong consistency and scalability.
• Keycloak is an open-source identity and access management (IAM) system providing features like single sign-on (SSO), identity brokering, user federation, and social login integration.It handles user authentication (e.g., login) and single sign-on (SSO) across multiple applications. While Keycloak can handle basic authorization through roles, it can also integrate with Zanzibar for more fine-grained access control.

Can an existing IDAM/IAM connect with Zanzibar?

Existing Identity and Access Management (IAM) systems can connect with Zanzibar to leverage its fine-grained authorization capabilities. Here’s a general overview of the connection process:

At a high level, this can be broken down into:

1. Authentication with Existing IAM/IDAM:
   The existing IAM/IDAM system handles user authentication, providing functionalities like single sign-on (SSO), user federation, and managing user identities.
   After successful authentication, the IAM/IDAM system issues an access token (such as a JWT) that includes user information and roles. (i.e. relevant user attributes)
2. Token Verification and Information Extraction:
   Backend services verify the token issued by the IAM/IDAM system to authenticate the user’s identity.
   Extract relevant user information (e.g., user ID, roles, groups) from the token to be used in authorization checks.The IAM system transmits the user’s token or attributes to Zanzibar. This can be achieved through various mechanisms like API calls or standardized protocols like OIDC.
3. Authorization Decision:
   Zanzibar utilizes the received user attributes and its permission graph to determine if the user has access to the requested resource.

a) For each request requiring authorization, the backend service queries Zanzibar to check the user’s permissions.

b) Use the user information from the token to construct the necessary authorization queries to Zanzibar.

c)As a response, Zanzibar signals the application or API gateway to grant or deny access to the resource.

This integration enables IAM systems to handle user authentication while Zanzibar takes over the complex authorization logic, providing a more robust and scalable access control mechanism.

Using OIDC to connect my existing AD Users via Zanzibar:

OIDC (OpenID Connect) provides a standardized way to connect your existing Active Directory (AD) users to Zanzibar for authorization purposes. Here’s a general outline:

• Configure OIDC Provider: Set up your IAM system, likely acting as an OpenID Provider (OP), to issue tokens compliant with the OIDC specification. This involves enabling OIDC features within your IAM system.
• Zanzibar Client Registration: Register your Zanzibar instance as a relying party (RP) with your OIDC provider. This registration creates a trust relationship between Zanzibar and your IAM system.
• User Login: Users will continue to log in via your IAM system’s login interface.
• Token Issuance: Upon successful login, your IAM system issues an OIDC token containing user attributes.
• Attribute Exchange: The OIDC token containing relevant user attributes is transmitted to Zanzibar.
• Authorization Decision: Zanzibar utilizes the received user attributes and its permission graph to determine access rights.
• Access Grant/Deny: Based on the authorization decision, Zanzibar signals the application or API gateway to grant or deny access to the resource.

By implementing OIDC, you can leverage your existing AD users for authentication while Zanzibar handles authorization using its fine-grained access control mechanisms. Remember, the specific steps might vary depending on your IAM system and Zanzibar deployment. Consider consulting the documentation for both systems for a more detailed guide.

When should I not consider using Zanzibar?

While the Zanzibar Authorization System offers many benefits, there are certain scenarios where it might not be the best fit:

1. Simple Authorization Requirements:

If your application has straightforward authorization needs that can be easily managed using traditional access control mechanisms (e.g., role-based access control), implementing Zanzibar might introduce unnecessary complexity. In such cases, simpler solutions might be more appropriate and easier to maintain.

2. Small-scale Applications:

For small-scale applications with limited user bases and resources, the overhead of implementing and managing Zanzibar may outweigh the benefits. If your application does not require the scalability, flexibility, or fine-grained access control capabilities provided by Zanzibar, simpler authorization solutions might be sufficient.

3. Tight Budget or Time Constraints:

Implementing Zanzibar requires time, resources, and expertise. If your project is operating under tight budget or time constraints, it may not be feasible to invest in integrating and customizing Zanzibar. In such cases, opting for simpler, off-the-shelf authorization solutions might be more practical.

4. Legacy Systems:

Retrofitting legacy systems to work with Zanzibar can be challenging, especially if they have deeply embedded authorization logic or rely on outdated technologies. If your application is built on legacy infrastructure that cannot easily integrate with Zanzibar, it may be more practical to stick with existing authorization mechanisms or consider modernizing the system incrementally.

5. Regulatory Compliance:

Depending on your industry and regulatory requirements, Zanzibar may not meet all compliance standards out-of-the-box. Before adopting Zanzibar, you should carefully evaluate whether it aligns with your organization’s compliance needs and consider any additional customization or configuration required to ensure compliance.