DEV Community: Cerbos

What Is Runtime Authorization? A Guide to Dynamic Access Control and the Best Runtime Authorization Tools

Anna — Fri, 13 Feb 2026 18:27:11 +0000

In the complex landscape of modern software, ensuring that users, and automated actors, can only access the data and actions they are authorized to use is critical. As systems become more distributed and regulatory requirements tighten, static access control models are no longer sufficient. This is where runtime authorization becomes essential.

This article explores what is runtime authorization, why it is replacing traditional static models, and what you should look for when evaluating the best runtime authorization tools for your stack.

What Is Runtime Authorization?

Runtime authorization (often called dynamic authorization) is the process of making access control decisions on the fly, at the moment of access, using real-time information and policies.
Unlike traditional methods where permissions are assigned in advance and rarely change, runtime authorization evaluates the current context of a request to decide whether to permit or deny it. This decision typically considers:

• Who the user is (identity and roles).
• What they are trying to do (action).
• Which resource they are targeting.
• Contextual factors such as time of day, location, device security posture, or the current state of the resource.

The Core Difference: Static vs. Dynamic

To fully understand what is runtime authorization, it helps to contrast it with admin-time (static) authorization.

Admin-Time Authorization: Permissions are configured in advance by an administrator. A user is assigned a role (e.g., "Manager"), and that role carries a static set of permissions. The system simply checks, "Does this user have the Manager role?" If yes, access is granted. This decision is based on configuration, not current context.

Runtime Authorization: Permissions are checked at execution time. The system asks, "Is this specific action allowed right now?" A policy might say, "Managers can approve invoices, but only if the amount is under $5,000 and the invoice belongs to their department." This logic requires real-time evaluation of the invoice amount and department attributes.

While admin-time authorization is excellent for establishing baseline eligibility (who could do what), runtime authorization ensures that access is appropriate for the specific situation (who should do what now).

Why Static Authorization Is No Longer Enough

For years, Role-Based Access Control (RBAC) was the standard. However, relying solely on static assignments creates significant blind spots.

Risk Accumulates Silently
When permissions are static, they tend to outlive their purpose. A user might be granted broad access for a specific project, but when the project ends, the access remains because no one manually revokes it. This accumulation of privileges creates a "blast radius" that attackers can exploit.
Context Is Ignored
Static roles cannot easily account for context. For example, a "Doctor" role might grant access to all patient records. However, a hospital may want to restrict access to only patients currently under that doctor's care. To enforce this statically, you would need to create unmanageable numbers of roles (e.g., "Doctor-Ward-A", "Doctor-Ward-B"). Runtime authorization handles this elegantly by checking the "department" attribute dynamically.
Lack of Decision-Level Evidence
In static systems, audits often only show intent (i.e., "User X was assigned Role Y"). They rarely show proof of what was actually enforced during a specific transaction. Runtime authorization generates decision-level evidence, allowing you to log exactly why a request was allowed or denied based on the specific policy version and inputs used.

The Benefits of Runtime Authorization

Implementing runtime authorization unlocks several critical capabilities for modern enterprises:

• Zero Trust Architecture: It supports the principle of "never trust, always verify." Every request is evaluated against policy, regardless of whether the user is inside or outside the network.
• Fine-Grained Control: You can enforce specific business rules, such as requiring Multi-Factor Authentication (MFA) for sensitive transactions or restricting access based on geolocation.
• Instant Adaptability: If a user’s attributes change (e.g., they transfer departments), their access rights update immediately without administrative intervention.
• Zero Standing Privileges: Instead of users holding powerful permissions 24/7, runtime authorization allows for ephemeral access.

A developer can be granted access to production servers only when handling an active incident, with the permission automatically revoked afterward.

Best Runtime Authorization Tools: What to Look For

As organizations shift toward dynamic access control, selecting the right tooling is paramount. The best runtime authorization tools share several key architectural characteristics that distinguish them from legacy IAM solutions.

When evaluating solutions, look for these features:

1. Decoupled Policy Decision Points (PDP)

The most effective tools separate the decision logic from the application code. This is often achieved using a Policy Decision Point (PDP).
• How it works: Your application (the Policy Enforcement Point, or PEP) sends a query to the PDP: "Can User X perform Action Y on Resource Z?"
• The Benefit: The PDP evaluates the policy and returns a simple "Allow" or "Deny." This keeps your application code clean and ensures that authorization logic is centralized, not scattered across IF/ELSE statements in your codebase.

2. Policy-as-Code

Top-tier tools treat authorization policies as code. This means policies are defined in human-readable formats (like YAML or JSON), stored in version control systems (like Git), and subject to the same testing and review processes as software code. This approach enables "governance without new runtime risk," ensuring that every change is tracked and reversible.

3. Performance and Scalability

Authorization is in the critical path of every request. The best runtime authorization tools must evaluate decisions in sub-millisecond timeframes. They should run close to the application—often as a sidecar or local service—to avoid network latency. If a policy engine introduces noticeable lag, teams will inevitably bypass it.

4. Auditability and Governance

A robust tool provides more than just a yes/no answer; it provides a paper trail. Look for solutions that offer "decision-level evidence," recording exactly which policy version was used and what inputs led to the decision. This turns authorization from a theoretical control into a fully inspectable compliance asset.

5. Support for Non-Human Identities

Modern architectures rely heavily on automated actors—service accounts, AI agents, and background jobs. The best tools treat these non-human identities with the same rigor as human users, applying context-aware policies to prevent automated systems from becoming security liabilities.

Cerbos: A Leader in Runtime Authorization

Cerbos exemplifies the modern approach to runtime authorization. It is an enterprise authorization solution for applications, APIs, workloads, and AI agents, that integrates seamlessly into Zero Trust environments.

• Contextual and Continuous: Cerbos enforces fine-grained policies across applications, APIs, and even AI agents. It evaluates policies based on identity, workload attributes, and execution context.
• Developer-Centric: By using "policy-as-code," Cerbos allows developers to write policies in structured YAML, making it easy to map business requirements directly to authorization logic.
• Centralized Governance: With Cerbos Hub, organizations can centrally manage, test, and distribute policies to distributed PDPs. This ensures consistent decision-making whether the policy is called from a monolith, a microservice, or a serverless function.

Cerbos solves the "spaghetti code" problem by externalizing authorization. Instead of hard-coding complex logic (e.g., if user.role == manager && invoice.amount < 5000), the application simply asks the Cerbos PDP for a decision. This makes systems simpler, more secure, and easier to audit.

Conclusion

As applications evolve, what is runtime authorization is no longer just a theoretical question—it is a practical necessity. Static role-based models simply cannot keep pace with the dynamic nature of cloud-native infrastructure, AI agents, and evolving compliance demands.

By adopting the best runtime authorization tools—those that offer decoupled PDPs, policy-as-code, and deep auditability—you can ensure your security posture is proactive rather than reactive. Tools like Cerbos allow you to enforce least privilege effectively, turning authorization into a continuously governed control that scales with your business.

Ready to modernize your access control? Explore how Cerbos can help you implement externalized, dynamic authorization. Learn more about Cerbos, the enterprise authorization solution for applications, APIs, workloads, and AI agents.

Importance of Role-Based Access Control (RBAC) in Web Security

Anna — Thu, 17 Jul 2025 13:51:45 +0000

Web security is a blanket term that refers to the practices that protect systems, resources, and data from malicious actors, threats, unauthorized access, and vulnerabilities as they interact on the web.

Role-based access Control, or RBAC, is an authorization approach that defines how users can interact with system resources based on predefined roles and permissions. This blog explores the role of RBAC in enhancing web security.

Why web security is important

Web security is essential to building resilient systems that inspire trust in users and are, by default, harder to breach.

Implementing web security practices prevents unauthorized access to system resources, keeping user information safe from bad actors.

It also makes it easier for organizations to comply with legal requirements like GDPR and HIPAA, avoiding legal problems and further inspiring trust in their systems.

What RBAC is and how it can enhance web security

RBAC is an access control method that assigns permission to users' roles and defines what each role can access within the system. It simplifies access management by grouping users under roles rather than assigning direct individual permissions.

It enhances web security by preventing unauthorized access by restricting user interaction to just the resources to which they have explicit access.

Additionally, its design limits the negative impact of user-related errors by containing them to specific resources that the user can access, thus preventing unnecessary system-wide outages.

As applications grow and logic becomes more complex, updating authorization logic to keep it in sync becomes more urgent. Maintaining RBAC will demand more attention, and at this point, external authorization providers like Cerbos will become involved.

How Cerbos simplifies RBAC for enhanced web security

Cerbos is an external authorization provider that enables organizations to separate or decouple their access control layer from the rest of their application logic. This allows organizations to centralize their RBAC policies, making them easier to manage, test, and scale.

Cerbos evaluates whether a user with a specific role and attribute should be allowed access to a resource. It provides a simple ALLOW or DENY response, reducing code complexity and improving the security baseline by leaving authorization logic to the experts. This frees up developers to focus on application functionality instead of building an authorization engine and maintaining it in-house

For example, if an organization is building a blog application where users have roles like Admin, Editor, and Author. Cerbos lets you define policies such as:

Admin: Full access to all resources.
Editor: Can view and manage Author blogs and schedules.
Author: Can only view and manage their blogs.

Implementing RBAC in your application is streamlined Using Cerbos SDKs and policy decision points (PDPs). You can integrate Cerbos with your backend via its SDKs or make a simple API request to the Cerbos service. This enables you to enforce authorization consistently without directly dealing with complex access rules in your system.

RBAC best practices

We must consider and implement the following best practices to get the most security benefits from RBAC.

Do organizational research

Gather information about the organizational hierarchy, data systems, roles, and needs. Verify the findings with major stakeholders and then create RBAC policy.

The policy should cover all necessary use cases, constraints, and rules. It should be treated like documentation and be the single source of truth. It should also be made available to all relevant people in the organization.

The Principle of Least Privilege (PoLP)

The Principle of Least Privilege refers to assigning users the minimum permissions they need to perform their roles and nothing more. This is a central principle of access policies, and the following processes are used to implement it:

Granular Access Control

This refers to breaking down the permissions a user might need into their smallest units. Instead of giving permissions to a section of a system, you give them to the specific part of the section that the user needs to access.

For example, giving a marketing team access to traffic data in an analytics dashboard while blocking access to revenue information.

Just-in-Time Access

If a user needs extra permissions, grant them elevated access for a given time instead of permanently upgrading their permissions. For example, a new developer might need access to sensitive production data only while fixing a particular bug, and the extra permission will auto-expire when it is done.

Create processes for elevated permissions

Have vetted processes in place for when users need more permissions. This keeps things visible and creates a trail that makes auditing more straightforward.

The benefits of carefully implementing this principle include containing any security breaches. Because the user has minimum permission, any damage caused by a compromised system is contained.

Another benefit is that few permissions mean a smaller attack surface, increasing system resilience.

Carrying out deep research before assigning roles and permissions makes this principle simpler to apply and ensures that your roles are appropriately designed.

Review organizational structure periodically

Organizational hierarchies change over time, and monitoring these changes keeps the roles and application logic in sync, preventing leaks and improving security.

Regular reviews of your organization's structure help identify when new roles need to be created or existing ones modified. This includes reviewing department changes, business processes, and operational workflows that might affect access requirements.

Log, audit, and test policies

RBAC policies require regular testing and audits to ensure they work as expected and to be kept updated with organizational changes.

Implementing logging in your RBAC systems makes the auditing part a lot simpler and makes it clear where policies are failing or need to be reviewed.

Leverage automation

Use automation to pick up when people move around the organization and roles no longer fit. Automating this enables you to stay on top of policies and contain role explosion, which is when the roles grow a lot over time and become disorganized and hard to manage.

Have a contingency plan

Develop a way to securely access the system and data in the case of an emergency where the policies backfired or when the policies need to be bypassed.

This should include proper documentation, transparent approval processes, and situation assessment afterward.

Cultivate a security culture

Actively train your team on best web security and RBAC practices. Have your team deeply understand and accept why all the processes and procedures are essential. This will encourage a shared security mindset, where your team proactively monitors and refines RBAC policies.

Conclusion

RBAC is essential for securing web-based systems. It protects user data, ensures system integrity, and encourages user privacy. However, implementing RBAC at scale can be time-consuming and complex. Cerbos simplifies this process by centralizing and streamlining authorization, enabling organizations to focus on building secure, scalable applications.

Notes and resources

Check out these links to learn more on RBAC, Cerbos, and web security best practices:

Cerbos PDP - Open source authorization for RBAC and ABAC. We have updates!

Anna — Tue, 03 Dec 2024 16:56:20 +0000

Our co-founders have seen firsthand how the implementation and management or roles and permissions can turn into a nightmare as your application grows. Tangled access control rules buried deep in your business logic, adding a new role feels like navigating a complex maze of if/else statements…

Which is why 3 years ago, we released Cerbos PDP (and are continuing to work on it actively).

PS. We’re happy to share that this week we surpassed 3333 stars on Github! 🌟 Feel free to support us by giving us a star 🙂

What is Cerbos PDP?

Cerbos PDP (Policy Decision Point) is an open source authorization layer designed to grow with your product. It allows developers to define powerful, context-aware access controls through simple, intuitive, and testable policies. Here’s a video explaining how it works.

Latest updates we’ve introduced:

Improved error reporting with better error descriptions and contextual information to help debug access policies issues faster.
Support for policy versioning and scoping within policy conditions, allowing for more fine-grained control over authorization logic.
Policy inspection via the command line. The cerbosctl inspect command allows investigation of policies, showing what actions each policy covers.
Artifact signing and SBOM generation. All Cerbos release artifacts,binaries and containers, are now signed using Sigstore, making them verifiable.
Development environment linked Playground enables developers to author policies and in real time see their impact in the application they are developing.

Click here for more details

PS. We’re happy to share that this week we surpassed 3333 stars on Github! 🌟 Feel free to support us by giving us a star 🙂

What is an Access Control System?

Anna — Mon, 18 Nov 2024 16:35:14 +0000

Access control systems play a crucial role in modern security, acting as the gatekeepers that determine who can go where and do what, both in the physical and digital realms. Whether it's restricting entry to a secure office space or limiting access to sensitive data on a network, access control systems are essential for protecting assets. You can think of them as high-tech bouncers—making sure only the right people get in.

In this article, we'll explore what access control systems are, how they work, and why they are so important for both physical and network security.

Understanding Access Control Systems

An access control system is a security solution that manages and regulates access to resources, locations, or information. Its primary function is to ensure that only authorized users can gain access to specific areas or data. These systems are critical for safeguarding both physical spaces (like office buildings or data centers) and digital assets (like network resources or confidential files).

There are two main types of access control systems:

Physical Access Control Systems: These systems control access to physical locations, such as doors, gates, or secure areas within a building.
Network Access Control (NAC) Systems: These systems manage access to network resources, ensuring that only authorized users and devices can connect to a network.

An integral part of many access control systems is the Access Control List (ACL), which specifies which users or system processes are granted access to objects, as well as what operations are allowed on given objects. ACLs are crucial for implementing fine-grained access control in both physical and digital environments.

Types of Access Control Systems

1. Physical Access Control Systems

Physical access control systems restrict access to physical locations. This can include anything from a simple lock and key to more advanced systems like keycard readers, biometric scanners, and turnstiles. These systems are commonly used in office buildings, data centers, and other secure facilities to ensure that only authorized personnel can enter restricted areas.

Physical access control systems typically involve an authentication mechanism, such as a keycard or fingerprint scanner, which grants or denies access based on the user's credentials. When a user presents their credentials at a reader, the system checks against its database to verify if the user has permission to access the area.

Installing a physical access control system involves setting up hardware components like card readers, biometric scanners, and electronic locks. It also requires configuring the software that manages access rights and tracks user activity.

2. Network Access Control (NAC) Systems

Network access control systems are designed to secure digital environments by managing access to network resources. NAC systems ensure that only authorized users and devices can connect to a network, thereby preventing unauthorized access and potential security breaches.

NAC systems operate by authenticating users and devices before granting network access. They may use various authentication methods, such as usernames and passwords, digital certificates, or device health checks, to verify that a user or device meets the network's security requirements. Once authenticated, the system enforces network policies that determine what resources the user or device can access.

NAC systems are vital for protecting sensitive data and maintaining network integrity. They are especially important in environments where multiple devices and users need to connect to the network, such as corporate offices, educational institutions, and healthcare facilities.

3. Role-Based Access Control (RBAC) and Access Control Lists (ACLs)

RBAC is a method of managing access to resources based on the roles assigned to users. Instead of granting permissions to individual users, permissions are associated with roles, and users are assigned to these roles. This approach simplifies permission management, especially in large organizations where users may have similar access needs. For example, an "Administrator" role may have full access to system settings, while a "User" role may have limited access to only certain areas.

ACLs provide a more granular level of control by specifying exactly which users or system processes have access to specific objects and what actions they are allowed to perform. In network security, ACLs are often used to control access to routers, firewalls, and other network devices, specifying which IP addresses or networks are allowed or denied access to specific resources.

RBAC and ACLs are used in various scenarios, such as controlling access to files and directories in an operating system, managing user permissions in applications, and securing network resources. For a deeper understanding of RBAC and ACLs, you can refer to this guide.

How Access Control Systems Work

Access control systems operate on the fundamental principles of authentication and authorization.

Authentication: This is the process of verifying the identity of a user or device. In physical access control systems, authentication might involve a keycard swipe, a fingerprint scan, or facial recognition. In digital access control systems, it might involve entering a username and password, providing a digital certificate, or using multi-factor authentication (MFA).

Authorization: Once a user's identity has been authenticated, the system then determines whether the user has the necessary permissions to access the requested resource. This decision is made based on the user's role, the access control list (ACL), or network access policies.

Logging and Monitoring: Most access control systems also include logging and monitoring features, which record access events and track user activity. This is crucial for auditing purposes and for detecting any unauthorized access attempts.

For a more detailed look at how authentication and authorization work together in access control systems, you can visit this comprehensive guide.

Benefits of Implementing an Access Control System

Implementing an access control system offers numerous benefits, such as:

Enhanced Security: Access control systems provide a robust layer of security for both physical and digital assets. By restricting access to only authorized users, they reduce the risk of unauthorized access, theft, or data breaches. This is particularly important for organizations that handle sensitive information or operate in regulated industries.

Streamlined Access Management: With an access control system in place, managing user access becomes more straightforward. Role-based access control (RBAC) and access control lists (ACLs) allow administrators to easily define and modify permissions based on user roles or specific needs, reducing the complexity of access management.

Improved Compliance: Many industries are subject to regulatory requirements that mandate strict access controls to protect sensitive data. Implementing an access control system can help organizations comply with regulations like GDPR, HIPAA, and PCI-DSS by ensuring that only authorized users have access to sensitive information.

Audit and Monitoring Capabilities: Access control systems typically include logging and monitoring features, which provide detailed records of who accessed what and when. This information is invaluable for auditing purposes and for investigating any potential security incidents.

Conclusion

Access control systems are essential tools for securing both physical and digital assets. Whether you're implementing a physical system to control entry to a building or a network access control (NAC) system to protect sensitive data, these systems play a crucial role in maintaining security and ensuring that only authorized users can access critical resources. By leveraging role-based access control (RBAC) and access control lists (ACLs), organizations can efficiently manage user permissions and enhance their overall security posture.

If you're considering implementing or upgrading an access control system, it's worth evaluating your current security measures and exploring the latest technologies available.

Access Controls for Users and Roles in SQL

Anna — Thu, 14 Nov 2024 13:32:54 +0000

In the world of databases, having the right access controls in place is like having a security team for your most valuable assets. SQL access control allows you to manage who can do what with your data, ensuring that only authorized users have the necessary permissions to interact with your database. Think of it as having a bouncer for your tables, keeping the riff-raff out and letting the right folks in. In this article, we'll explore the different types of access controls available in SQL, how to implement them, and best practices to keep your database secure. If you're new to database security, start with this beginner’s guide to get an overview.

Understanding Access Control in SQL

Access control in SQL refers to the process of managing permissions for users and roles within a database. This involves defining who can access specific data and what actions they can perform on that data. Access controls are crucial for database security, as they help protect sensitive information from unauthorized access or modification.

Users: Individual accounts that interact with the database. Each user can have specific permissions that define what operations they can perform, such as querying data, modifying tables, or managing database settings.
Roles: A collection of permissions that can be assigned to users. Roles simplify access management by allowing you to group permissions together and assign them to multiple users at once.
Permissions: Specific actions that a user or role is allowed to perform, such as SELECT, INSERT, UPDATE, or DELETE.

By implementing access controls, you can ensure that users have the appropriate level of access to the data they need while minimizing the risk of unauthorized actions.

Types of Access Controls in SQL

User-Based Access Control

What It Is: User-based access control involves assigning permissions directly to individual users. This method is useful when you need to grant specific access rights to certain users based on their unique requirements.
How It Works: In SQL, you can create new users and assign them permissions using commands like CREATE USER, GRANT, and REVOKE. For example, you can create a user and grant them permission to select data from a specific table:

CREATE USER 'john_doe'@'localhost' IDENTIFIED BY 'password'; GRANT SELECT ON database_name.table_name TO 'john_doe'@'localhost';

When to Use It: User-based access control is ideal for scenarios where you need to assign unique permissions to individual users. However, it can become cumbersome to manage as the number of users increases.
Further Reading: For more on user-based access control in SQL, visit this guide.

Role-Based Access Control (RBAC) in SQL

What It Is: Role-based access control involves creating roles with specific permissions and then assigning these roles to users. This approach simplifies permission management by allowing you to group permissions together and assign them to multiple users at once.
How It Works: You can create roles in SQL and grant permissions to these roles using the CREATE ROLE and GRANT commands. For example, you can create an editor role and grant it the ability to insert and update data:

CREATE ROLE editor; GRANT INSERT, UPDATE ON database_name.table_name TO editor; GRANT editor TO 'john_doe'@'localhost';

In this example, the editor role is created with INSERT and UPDATE permissions, and then assigned to the user john_doe.

Benefits of Using Roles: RBAC makes it easier to manage permissions, especially in environments with many users. By defining roles for different job functions (e.g., admin, editor, viewer), you can quickly assign the appropriate permissions to users without having to specify individual permissions for each user.

Access Control Lists (ACLs) in SQL

What They Are: Access Control Lists (ACLs) provide fine-grained control over who can access specific database objects and what actions they can perform. ACLs are essentially lists that specify which users or roles have access to certain resources and what operations they are allowed to perform.
How They Work: ACLs can be applied to various database objects, such as tables, views, and stored procedures. For example, you can use ACLs to grant a user permission to execute a stored procedure:

GRANT EXECUTE ON PROCEDURE database_name.procedure_name TO 'john_doe'@'localhost';

This command adds an entry to the ACL for the specified procedure, allowing the user john_doe to execute it.

Use Cases: ACLs are useful for scenarios that require granular control over database access. They allow you to define precise permissions for different users or roles, enhancing the security and flexibility of your access control strategy.

Implementing Access Controls in SQL

1. Creating and Managing Users

Creating Users: In SQL, you can create new users using the CREATE USER command. Once a user is created, you can assign them specific permissions to interact with the database. Here's an example:

CREATE USER 'jane_doe'@'localhost' IDENTIFIED BY 'securePassword!';

Assigning Permissions: After creating a user, you can grant them permissions using the GRANT command. For instance, to allow the user to select and insert data into a table:

GRANT SELECT, INSERT ON database_name.table_name TO 'jane_doe'@'localhost';

Modifying Permissions: If you need to change a user's permissions, you can revoke existing permissions and grant new ones as necessary. For example:

REVOKE INSERT ON database_name.table_name FROM 'jane_doe'@'localhost'; GRANT UPDATE ON database_name.table_name TO 'jane_doe'@'localhost';

2. Creating and Managing Roles

Creating Roles: Roles in SQL are created using the CREATE ROLE command. You can then grant specific permissions to these roles and assign them to users. For example, to create a report_viewer role:

CREATE ROLE report_viewer; GRANT SELECT ON database_name.report_table TO report_viewer;

Assigning Roles to Users: Once a role is created and has the necessary permissions, you can assign it to users:

GRANT report_viewer TO 'jane_doe'@'localhost';

Now, jane_doe inherits the permissions granted to the report_viewer role.

Best Practices: When defining roles, group permissions based on job functions and responsibilities to simplify access management. This approach not only streamlines the assignment of permissions but also enhances security by ensuring that users have the appropriate level of access.

3. Granting and Revoking Permissions

Granting Permissions: Permissions in SQL can be granted at various levels, such as on a database, table, or specific columns. Here’s how you can grant different types of permissions:

GRANT SELECT ON database_name.table_name TO 'jane_doe'@'localhost'; GRANT INSERT, UPDATE ON database_name.table_name TO 'editor';

The first command grants the SELECT permission on a table to a user, while the second grants INSERT and UPDATE permissions to a role.

Revoking Permissions: It's important to regularly review and update permissions. If a user or role no longer needs access to a resource, you should revoke the permissions:

REVOKE SELECT ON database_name.table_name FROM 'jane_doe'@'localhost';

Importance of Revocation: Revoking unnecessary permissions is a key part of maintaining database security. It ensures that users do not have access to data they no longer need, reducing the risk of unauthorized access or data breaches.

Best Practices for SQL Access Control

Start with the Principle of Least Privilege: Always grant the minimum permissions necessary for users and roles to perform their tasks. This reduces the risk of unauthorized access and potential security breaches.
Regularly Audit Permissions: Periodically review user and role permissions to ensure they are still appropriate. Remove any permissions that are no longer needed to maintain a secure environment.
Use Roles to Simplify Management: Define roles for different job functions and group permissions accordingly. Assign users to these roles instead of granting permissions directly to simplify access control and ensure consistency.
Monitor and Log Access: Implement logging and monitoring to track access to sensitive data. This helps detect any unauthorized access attempts and assists in audits and compliance reporting.

Conclusion

Implementing access controls for users and roles in SQL is essential for maintaining a secure and well-managed database environment. By understanding and using user-based access control, role-based access control (RBAC), and access control lists (ACLs), you can effectively manage permissions and protect sensitive data. Remember, even your database tables need a bouncer to keep things in check. Regularly reviewing and updating access controls is key to ensuring that your database remains secure and that users have the appropriate level of access for their roles. If you're looking to dive deeper into SQL access control, there are plenty of resources and guides available to help you along the way.

Keeping your AI on a tight leash

Anna — Wed, 13 Nov 2024 12:39:34 +0000

Picture this - your new AI system ends up spilling sensitive data. Nightmare scenario. As AI gets more complex, the risks of leaks and unauthorized access keep piling up.

Fine-graind authorization can be a game-changer. It lets you enforce strict permissions tailored to your needs.

In this piece, we'll look at how companies can protect their data in AI systems, especially when using retrieval-augmented generation (RAG) and large language models (LLMs).

Securing data in a centralized world

A lot of companies are turning to RAG architectures for their AI apps. They let LLMs tap into internal data to improve outputs. But the tricky part is giving an LLM enough context without breaching privacy.

The issue is making sure AI agents can't spill sensitive data. Most RAG setups centralize everything in a vector store, making it a pain to control what AI can access. The easy fix is loading all your data in one spot and using that with an LLM. But then you're giving anyone who touches that agent full access - recipe for privacy issues, compliance problems, and losing customer trust.

Access controls to the rescue

To stay safe, organizations need a fine-grained permission model for their RAG architecture. This ensures AI systems provide the right context while keeping sensitive data locked down.

But there are challenges. Building custom permissions for RAG is complicated. Without the right controls, you risk major data exposure. Plus, you need to set permissions before feeding data to models to stop leaks.

That's where Cerbos comes in - the complete authorization solution. It makes sure AI only accesses authorized data, guarding your privacy and compliance. And it prevents leaks through real-time, permission-aware filtering. Here's the documentation.

The path forward

RAG and LLMs pack potential, but without watertight access controls, they can turn into a liability. Fine-grained authorization is the key to letting your AI systems deliver value without compromising security, privacy, or compliance.

Cerbos provides a scalable solution. So if you’re looking for ways to install guardrails around your AI applications - you can learn more here.

Authorization needs to be dynamic, declarative, and decoupled

Dan — Tue, 12 Nov 2024 10:00:00 +0000

Guest article written by Fatuma Abdullahi. Thanks! For more great community content and discussions, join our Slack today!

Authorization mechanisms have traditionally been closely tied to the main application logic, and while this works in traditional monolithic systems, maintaining this coupling becomes harder as application complexity grows.

As authorization is a significant aspect of creating and maintaining secure systems, it is better to have it decoupled (or "externalized"); that is, to reduce the dependence between authorization and core application logic. Decoupling simultaneously increases the reliability of the authorization functionality whilst decreasing the complexity of the core system itself.

It is also advantageous to have authorization logic expressed in declarative terms to describe the rules and expected outcomes. This allows the system to make decisions rather than explicitly stating how decisions should be made, making the authorization system accessible to less technical members of an organization. This leads to a dynamic authorization system, or one that makes real-time decisions as requests come in.

Decoupled, or externalized, authorization

Using an authorization system that is external to your primary system offers some hard-to-beat advantages, including:

Enhanced Security

External authorization providers are more secure because they are specialized, and are designed from the ground-up with domain-specific experience. They are more aware of the landscape and know what to look out for better than any team whose focus is pulled in many different directions.

Simpler Policy Management

External authorization providers offer a standard way of writing policies and rules, making policy management predictable and allowing the team to move faster.

Straightforward Scaling

External authorization systems have the concept of scale built in. They can be adapted at any size, and when the application grows or its authorization needs change, the external system grows with it seamlessly.

Advantages of externalizing authorization

Decoupling authorization shares advantages with using an external system because both rely on the separation of authorization and business logic as a central pillar. However, additional advantages appear when using an internally-decoupled system. These include:

Increased System Resilience

Separating authorization logic and rules from your main application increases your systems' resilience as the interdependence between them reduces. This allows your system to withstand outages without affecting all your functions.

Simplified Workflows

Keeping authorization external to your primary system simplifies setting up authorization logic and rules. It keeps the teams' focus on how authorization should look independent of any core logic, reducing chances of blind spots and increasing clarity.

Easier Maintenance

Using separate authorization systems makes maintaining the authorization engine more straightforward because of the decoupling that occurs. This makes it simpler to debug and increases the team's developer experience.

RBAC and decoupled authorization

Role-based access Control (RBAC) is an authorization technique that uses a user's role in a system to determine what resources they can access. It is a common way to enforce authorization across systems by assigning permissions to roles rather than to individual users and then assigning roles to users. When enforcing decoupled authorization, RBAC is implemented by centralizing all roles and their related permissions across the system.

There are some trade-offs when using RBAC to manage authorization, including:

Role Explosion

As a system grows, the number of roles and permissions might rapidly multiply leading to too many role definitions overall. This makes it harder to manage and reason about the authorization policies.

Granular Permissions

Sometimes, RBAC is used even in situations better served by more granular access controls. Scenarios requiring dynamic or context-specific permissions might be better served using other techniques like ABAC (Attribute-Based Access Control), which offer more control and flexibility.

Reduced Flexibility

Making changes to RBAC-based policies can be difficult in a growing system, and changes may cause system-wide repercussions. This can lead to a system being slower in adapting to changing authorization needs.

It is important to consider these trade-offs when designing RBAC-based authorization policies and to consider whether other access control techniques might be a better fit.

Authorization and microservices architecture

Microservice architecture refers to organizing application logic into services that typically carry out one thing and can be deployed independently while loosely coupled. For example, edge functions are microservices.

In a system where the backend isn’t distributed in this way (i.e. monolithic architecture), managing authorization queries is reasonably straightforward, as all the data is available in a central location. The challenge with authorization in a microservice architecture is that the services are separated by definition, and often may not talk to each other, making consistent access control and synchronization hard.

There are several ways to handle authorization in a microservices architecture, including implementing a gateway API (Application Programming Interface) service. Cerbos can be integrated into a microservices architecture as a mechanism deployed alongside microservices (e.g. a sidecar in Kubernetes), such that every service has consistent access to the authorization endpoint.

This flexible approach ensures that policies stay consistent across the entire system, regardless of the many services involved. This further simplifies policy management while enhancing security.

Authorization best practices

There are several principles to keep in mind to help make your authorization system robust and to follow best practices, including:

Principle of Least Privilege

This principle emphasizes that users should only ever have the minimum access to perform the required role and no more. This reduces the risk of unauthorized access and the chances of a breach.

Continuous Monitoring and Logging

Logging authorization requests is good practice. This makes it easier to monitor and detect any anti-patterns. Implementing this makes your authorization system more robust and secure, and it also simplifies compliance and audit procedures.

Separation of Concerns

Keeping authorization logic and policies decoupled increases your system's resilience, as any issues in parts of the application will not bring down the entire system. Additionally, decoupling authorization increases flexibility, extensibility, and maintainability at a system level.

Learn more!

You can learn more about decoupled / externalized authorization using the resources below:

Best Practices for Managing Users, Roles, and Permissions

Anna — Wed, 06 Nov 2024 16:02:20 +0000

Managing users, roles, and permissions is like being the gatekeeper of a medieval castle. You have to decide who gets in, who stays out, and which keys each person carries. A well-thought-out system for managing user roles and permissions is crucial for keeping your organization's data secure and ensuring that teams have the right access to perform their jobs efficiently. But as much as we trust our colleagues, we wouldn't want "Bob from Accounting" wandering into the server room, right?

Striking the right balance between security and functionality is key. In this article, we’ll explore best practices for managing users, roles, and permissions, so you can keep things running smoothly without compromising on security.

Understanding Users, Roles, and Permissions

Managing access control within an organization starts with understanding the basics: users, roles, and permissions.

Users: These are the individuals who need access to your system. Each user should have a unique account to ensure that their actions can be tracked. This uniqueness is crucial for accountability and helps in auditing user activity.
Roles: A role is essentially a group of permissions bundled together to match a specific job function. For instance, an "Administrator" role might include permissions to manage users, configure settings, and access all data, while a "Viewer" role might only include permissions to view certain data without making changes. Roles simplify the management of permissions by allowing administrators to assign a predefined set of permissions to users based on their role in the organization.
Permissions: These are specific access rights granted to users or roles. Permissions define what actions a user can perform, such as reading data, modifying records, or deleting files. In a more granular system, permissions can be defined at different levels, such as database level, table level, or even column level.

A roles and permissions matrix is a tool that helps you visualize and define the relationships between these elements. It provides a clear overview of what each role is allowed to do, making it easier to manage and audit access controls. For more on creating a roles and permissions matrix, visit this detailed guide.

Best Practices for Managing Users, Roles, and Permissions

1.Define Clear User Roles

Start with a Plan: Begin by identifying the various job functions within your organization and outline the responsibilities of each role. This planning phase is crucial for ensuring that each role has the appropriate level of access. It's helpful to involve stakeholders from different departments to make sure all functions are adequately covered.
Use a Roles and Permissions Matrix: A roles and permissions matrix is an essential tool in this process. It allows you to map out each role and the permissions associated with it. This not only streamlines the process of assigning permissions but also provides a clear documentation trail. You can find a useful template for creating your matrix at this source.

2.Implement the Principle of Least Privilege

Minimize Access: The principle of least privilege (PoLP) dictates that users should be given the minimum level of access necessary to perform their duties. By applying PoLP, you reduce the risk of unauthorized access and potential data breaches. For instance, a marketing analyst might only need read access to customer data, while an IT administrator might need write access to system configurations.
Apply to All Roles: This principle should be applied across the board. Even users with elevated roles, like administrators, should only have access to systems and data that are essential for their responsibilities. A well-defined roles and permissions matrix can help enforce this principle by clearly outlining the permissions associated with each role. For more on PoLP, you can read this article.

3.Regularly Review and Update Permissions

Conduct Periodic Audits: Permissions need to be reviewed regularly to ensure that they remain appropriate. Over time, users' roles within an organization can change, and permissions that were once necessary may no longer be needed. Conducting regular audits helps identify these discrepancies and mitigate security risks. During an audit, compare the current permissions against the roles and permissions matrix to identify and resolve any inconsistencies.
Adapt to Organizational Changes: Organizations are dynamic, and so are user roles. As teams evolve or take on new projects, their access needs may change. It's important to adjust permissions accordingly to avoid "permission creep," where users accumulate more access than necessary over time. The matrix you created can be a helpful reference point during these updates.

4.Automate Where Possible

Leverage Automation Tools: Managing user roles and permissions manually can be time-consuming and prone to errors. Automated tools can streamline this process by assigning, modifying, and revoking access based on predefined rules. Tools like IAM (Identity and Access Management) systems can automatically assign roles to new users based on their job titles or departments. This not only speeds up the onboarding process but also ensures consistency in permission assignments. To explore popular IAM tools, visit this list of IAM software.
Monitor Access Automatically: Automation tools can also monitor user activities, generating alerts for any unusual access patterns or potential security threats. This real-time monitoring is crucial for quickly identifying and responding to potential security incidents.

5.Establish a Robust Onboarding and Offboarding Process

Set Up Roles During Onboarding: Onboarding is the perfect time to set up user roles and permissions. During this process, assign roles based on the new team member's responsibilities and ensure they receive only the necessary access. Automation tools can assist by assigning roles automatically based on job titles or departments. A well-defined onboarding checklist can help streamline this process and ensure nothing is overlooked.
Prompt Offboarding: When a team member leaves the organization or changes roles, it's essential to revoke or adjust their permissions immediately. This practice helps prevent unauthorized access from former employees and maintains system security. Automating the offboarding process can ensure that no permissions are left unchecked. You can find more on secure offboarding processes here.

6.Document and Communicate Roles and Permissions

Create Clear Documentation: Proper documentation is vital for maintaining an organized and secure system. Your documentation should include detailed descriptions of each role, the permissions associated with each role, and the rationale behind these assignments. This level of detail is not only helpful for current administrators but also essential for audits and training new administrators.
Communicate Policies to the Team: It’s important that all users understand the roles and permissions policies in place. Clear communication can help set expectations and foster a culture of security awareness. Regular training sessions can be beneficial in educating users about the importance of following these policies. For tips on effective communication of security policies, check out this article.

Conclusion

Effective management of users, roles, and permissions is essential for maintaining a secure and efficient system within any organization. By defining clear roles, adhering to the principle of least privilege, and regularly reviewing and updating permissions, you can safeguard your data while enabling your team to work effectively. Remember, it's not just about keeping unauthorized users out—it's about making sure that everyone has the right level of access to do their job well.

And, of course, let’s keep the server room safe from Bob and his snacks! By adopting these best practices, you’ll be well on your way to a more secure and organized access management system.

New tools for effortless policy creation and testing in Cerbos Hub

Anna — Wed, 09 Oct 2024 09:10:06 +0000

We are introducing new features in the Cerbos Hub Playground that aim to simplify how developers write, test, and iterate on authorization policies.

This release includes three additions:

The RBAC Policy Generator
The API Request Simulator
Connect a local PDP

These new features were introduced to reduce the time and effort involved in writing and testing policies, addressing common frustrations developers face in their workflow. The goal is to streamline the entire process, allowing for more efficient and realistic policy testing without the need for repetitive manual tasks.

With these enhancements, developers can spend less time on setup and more time on meaningful experimentation and testing, leading to a more productive workflow.

Let’s explore each new feature individually.

RBAC Policy Generator

The RBAC Policy Generator, (or the RPG if you enjoy playing with acronyms) which was released to the public playground last year, is now part of Cerbos Hub. This feature allows users to create role-based access control (RBAC) policies using a simple, no-code wizard. Once you’re done defining your roles and permissions in the RPG it will populate your playground with the YAML code corresponding to your defined RBAC policies, and a test dataset you can use for troubleshooting and further experimentation.

This feature makes setting up and testing RBAC policies faster and more straightforward and frees developers from the curse of the blank page.

To use the R(BAC)PG, click New Playground in the Hub Playground’s main page and then click the RBAC Policy Generator option when prompted to choose a set up method.

You’ll then be prompted to define your users, resource types, and actions, which will populate a checkbox grid you can use to assign permissions to roles.

Then click Generate Policy and you’ll see that the Playground automatically populates with policies written in YAML that reflect your selections in the wizard. It also comes ready with test data. You can then continue to manipulate and test your policies in the playground using the normal interface.

API Request Simulator

The API Request Simulator, (APIRS? ARSim? This one’s not as fun, unfortunately) also previously released in the public playground, is now integrated into Cerbos Hub. This feature allows users to simulate API requests without running a local policy decision point (PDP) and view the output of the Check Resources and Query Plan Resources APIs for any combination of user and resource.

This feature bridges the gap between written documentation and practical use by showing actual responses from the PDP, helping developers understand and verify how their policies behave in different scenarios. You can see the details of how the PDP evaluates policies, including the structure and data in the response. It’s useful for both understanding how Cerbos works and debugging policies based on real API outputs.

To use the API simulator, find the *Implement * tab in the Hub Playground's right sidebar. Select from test fixtures already defined in your playground, (principal, resource, actions, etc.). You’ll be able to see exactly how the request and response are structured and observe the expected allow/deny response based on your policies.

Connect a PDP to your Playground

The Playground PDP (PG PDP?) feature allows developers to establish a live connection between their development environment and the Hub Playground, eliminating the need to download files and reconfigure a Policy Decision Point (PDP) for each change. This setup lets developers test authorization policies in real-time, significantly reducing the manual steps previously required for policy testing and iteration.

Any changes you make in the playground are immediately reflected in your local PDP, providing a real-time feedback loop for integration testing.

To connect a PDP to your playground, go to the Implement tab in your right hand sidebar, and click Connect a PDP. You will be guided with detailed instructions within the UI. And you can view our demo to see how it’s done.

Important note:
The live-connected PDP is intended for development and testing purposes only. For production environments, you should use Cerbos Hub's managed CI/CD pipeline by setting up a workspace connected to your policy repository. In production, you can also leverage Cerbos Hub's audit logs feature to store and analyze all authorization decisions made by your PDPs, offering greater visibility and control over policy enforcement.

We invite you to explore these new features and share your feedback with us on Slack!

Authentication and authorization in Node.js applications

Dan — Tue, 08 Oct 2024 13:00:00 +0000

Thanks to our friendly Cerbos community member—who wishes to remain anonymous—for this tutorial. For more great community content and discussions, join our Slack today!

In this article, we will discuss authentication and authorization, and how to implement both JWT authentication and Cerbos authorization in a Node.js application.

Understanding authentication

Authentication is the process of verifying the identity of a user. In a Node.js application, we typically authenticate a user based on a set of credentials, such as a username and password, to gain access to the application.

Some common authentication methods are:

Username and password
Token-based authentication
Single Sign-On (SSO)

The authentication process works like this:

The user provides their credentials.
The server verifies the provided credentials.
If the credentials are valid, the server generates an authentication token or session ID for the user.
The newly generated token/session ID is sent back to the client and stored for future use.
To prove their authenticity, the user includes the token/session ID in each request.

Understanding authorization

Authorization is the process of giving access to users to do specific work/actions. It decides what an authenticated user is allowed to do within the application. After authentication, authorization makes sure that the user only does what they're allowed to do, following specific rules and permissions.

Some common authentication models are:

How does authorization work?

The authorization process works like this:

The authenticated user makes a request to the server.
The server verifies the user and gets their assigned roles and permissions.
The server evaluates if the user has permission for the requested actions.
If the user is authorized, the server allows the user to perform the requested actions.
Otherwise, it denies access and returns an appropriate error response.

What is RBAC?

Role Based Access Control, or RBAC, is an access control method that gives permissions to the user based on their assigned roles within our applications. In simple words, it controls what users can do within the application.

Instead of assigning permissions to individual users, RBAC groups users into roles, and then assigns permissions to those roles. This makes it easier to manage access control, as we only need to update permissions for a role, rather than for each individual user.

Key components of RBAC are:

Role: Defines a set of responsibilities, tasks, or functions within the application.
Permissions: Represents specific actions that users can perform.
Role Assignments: Users are assigned to one or more roles, and each role is associated with a set of permissions.
Access control policies: Dictate which roles can access particular resources and what actions they can take.

{Role} -- has --> {Permission} -- grants access to --> {Resource}" width="632" height="624">

RBAC is powerful, but implementing and managing it yourself is not easy. The open-source Cerbos PDP (or Policy Decision Point), acts as a stand-alone service, streamlining access control by centralizing both policy decisions and audit log collection, and decoupling authorization logic from your application.

Cerbos can function effectively within diverse software environments, from monoliths to fully decentralized architectures. It’s stateless and can be deployed via a Kubernetes sidecar, in a Docker container, or even as a single binary on a virtual machine. Cerbos exposes a rich HTTP API, which makes it language-agnostic, and allows it to interact and scale seamlessly with other services.

Implementing authentication and authorization in Node.js

Now that we have an understanding of authentication and authorization, let’s explore how to implement them in our Node.js application. In this section, we’ll build a simple Node.js app and integrate authentication and authorization functionalities.

Prerequisites

Before starting the project, make sure you have:

Node.js and npm installed on your system.
Docker installed on your machine (for running the Cerbos container).
Postman or a similar tool for testing API endpoints.

Set up a Node.js project

Create the project

To start with, we need to set up a Node.js project. Run the following command in the terminal:

npm init -y

This will initialize a new Node.js project.

Install the dependencies

Next, install the required dependencies for our project:

npm install express jsonwebtoken dotenv bcryptjs nodemon

This will install the following packages:

express: A popular web framework for Node.js.
jsonwebtoken: For generating and verifying JSON Web Tokens (JWT) for authentication.
dotenv: loads environment variables from a .env file.
bcryptjs: to hash the password.
nodemon: nodemon helps Node.js-based application restarts automatically when there is a change in the code.

Environment variables

Next, create a .env file to securely store our sensitive information, such as API credentials.

JWT_SECRET= "Your_Secret_Key_Here"
PORT=3000

Create the Express server

Now, we'll create an index.js file in the base directory and set up a simple Express server.

const express = require("express");
const dotenv = require("dotenv");
require('dotenv').config(); 

const app = express();
const port = process.env.PORT;

//middleware provided by Express to parse incoming JSON requests.
app.use(express.json()); 

app.get("/", (req, res) => {
  res.send("Hello World");
});

app.listen(process.env.PORT, () => { console.log(`Server is running on port ${process.env.PORT}`); });

At the top of the project, we're loading environment variables using dotenv.config() to make them accessible throughout the file. This way, we can use the dotenv package to access the PORT number from the .env file, instead of hardcoding it directly.

Run the project

In this step, we'll add a start script to the package.json file to easily run our project.

By default we'd have to restart our server each time we make changes to a file. To avoid this, we can use nodemon, which will scan for changes and restart automatically.

Add the following item to package.json:

"scripts": {
  "start": "nodemon index.js"
}

And now, we test!

npm run start

Finally, open http://localhost:3000/ in a browser, and if everything went to plan, you'll see the default "Hello World" page.

Implementing authentication with JWT

Our basic project setup is done! Next, we’ll implement authentication using JWT tokens.

Create routes for authentication

The authentication route will allow users to sign up and log in. Commonly, routes go in routes/, and since this is an authentication mechanism, we'll name it authentication.js. I've split this into multiple sections to make it easier to read, but it's the same file.

require('dotenv').config(); 
const express = require('express'); 
const jwt = require('jsonwebtoken'); 
const bcrypt = require('bcryptjs');

const app = express(); 
app.use(express.json());

const users = [ ]; // in-memory database to keep things basic for this tutorial

// Register route

app.post('/signup, (req, res) = >{

  const { username, password, role } = req.body;

  if (!Array.isArray(role)) {
    return res.status(400).json({ message: "Role must be an array" });
  }

  const userExists = users.find(user = >user.username === username);
  if (userExists) {
    return res.status(400).json({
      message: 'User already exists'
    });
  }

  const hashedPassword = bcrypt.hashSync(password, 8);

  users.push({
    username,
    password: hashedPassword,
    role
  });

  res.status(201).json({
    message: 'User registered successfully'
  });
});

// Login route 

app.post('/login', (req, res) = >{
  const {
    username,
    password
  } = req.body;

  const user = users.find(user = >user.username === username);
  if (!user) {
    return res.status(404).json({
      message: 'User not found'
    });
  }

  const isPasswordValid = bcrypt.compareSync(password, user.password);
  if (!isPasswordValid) {
    return res.status(401).json({
      message: 'Invalid credentials'
    });
  }

  const token = jwt.sign({
    username: user.username,
    role: user.role
  },
  process.env.JWT_SECRET, {
    expiresIn: '1h',
  });

  res.status(200).json({
    token
  });
});

The signup route allows users to register by providing a username and password. Upon receiving the data, it creates a new user instance and saves it to the in-memory database.

And, the login route verifies the user's credentials against the in-memory database. If the username and password match, it generates a JWT token and returns it to the client.

Middleware for JWT verification

Now, we’ll add one middleware function called verifyJWT that verifies the JWT token sent by the client, and which authenticates the user.

const jwt = require('jsonwebtoken');

function authenticateToken(allowedRoles) {
  return (req, res, next) = >{
    const authHeader = req.headers['authorization'];
    const token = authHeader && authHeader.split(' ')[1];

    if (!token) {
      return res.status(401).json({
        message: ‘No token provided'
      });
    }

    jwt.verify(token, process.env.JWT_SECRET, (err, user) = >{
      if (err) {
        return res.status(403).json({
          message: 'Invalid token'
        });
      }

      if (!allowedRoles.includes(user.role)) {
        return res.status(403).json({
          message: ‘You do not have the correct role'
        });
      }

      req.user = user;
      next();
    });
  };
}

module.exports = authenticateToken;

Protected route

Finally, we'll integrate these authentication routes with our express application in the index.js file.

app.get("/protected", authenticateToken(["admin"]), (req, res) => {
  res.status(200).json({ message: `Welcome Admin ${req.user.username}!` });
});

Here we have created a /protected route that uses authenticateToken to check if the user is authenticated.

If the user is authenticated, the server sends back a response saying "This is a Protected Route. Welcome [username]".

Here, [username] is replaced with the username of the authenticated user.

Test the endpoints

Sign-up

To validate the sign-up endpoint, we'll make a POST request to this route:

http://localhost:3000/auth/signup

With this header:

Content-Type : application/json

And the following JSON body:

{
    "username": "Arindam Majumder",
    "password": "071227",
    "roles":["admin"]
}

We got the token back as a response. We will copy the token as we'll need it in the next section.

Protected route

Now that we have obtained a JWT token from the login endpoint, we will test the protected route by including this token in the request headers.

For that, we'll make a GET request to the protected route URL http://localhost:3000/protected. In the request headers, we'll include the JWT token obtained from the login endpoint:

With this, we have successfully implemented JWT authentication in Node.js!

Implementing authorization with Cerbos

Now that we have added authentication to our project, we can now proceed authorization using the Cerbos PDP.

Launch the Cerbos container

We will begin by launching the Cerbos container via Docker.

In the base directory, use the following command to run the Docker container:

docker run --rm --name cerbos -d -v $(pwd)/cerbos/policies:/policies -p 3592:3592 -p 3593:3593 ghcr.io/cerbos/cerbos:0.34.0

And a quick docker ps to verify that the container persists.

For more information about the Cerbos container, see the official documentation.

Initialize the Cerbos client

Next, we set up the Cerbos client using the @cerbos/grpc library, which we first need to install:

npm install @cerbos/grpc

And we initialize the client with a few lines of code:

const { GRPC } = require("@cerbos/grpc");
const cerbos = new GRPC("localhost:3593", { tls: false });

Define a CRUD policy

After initializing the Cerbos client, we’ll define a simple CRUD policy in place for our application. Add this basic policy into the policies folder at cerbos/policies/contact.yaml.

---
apiVersion: api.cerbos.dev/v1
resourcePolicy:
  version: default
  resource: contact
  rules:
  - actions: ["read"]
    roles:
      - admin
      - user
    effect: EFFECT_ALLOW

  - actions: ["create"]
    roles:
      - admin
    effect: EFFECT_ALLOW

Access control middleware

Next, we'll create some middleware to check access for requests. In middleware/access.js:

const { GRPC } = require("@cerbos/grpc");
const cerbos = new GRPC("localhost:3593", { tls: false });

const jwtToPrincipal = ({ id, iat, roles = [], ...rest }) => {
  return {
    id: id,
    roles,
    attributes: rest,
  };
};

async function readAccess(req, res, next) {
  const decision = await cerbos.checkResource({
    principal: jwtToPrincipal(req.user),
    resource: {
      kind: "contact",
      id: req.user.id,
      attributes: req.user,
    },
    actions: ["read"],
  });

  if (decision.isAllowed("read")) {
      next();
    } else {
      return res.status(403).json({ error: "Unauthorized" });
    }

  }

  async function writeAccess(req, res, next) {
    const decision = await cerbos.checkResource({
      principal: jwtToPrincipal(req.user),
      resource: {
        kind: "contact",
        id: req.user.id,
        attributes: req.user,
      },
      actions: ["create"],
    });

    if (decision.isAllowed("create")) {
      next();
    } else {
      return res.status(403).json({ error: "Unauthorized" });
    }
  }

module.exports = {readAccess, writeAccess};

Here, the jwtToPrincipal function is a utility function that converts a JSON Web Token (JWT) payload into a Cerbos principal object. It extracts the sub (subject), iat (issued at), and roles properties from the JWT payload and assigns them to the corresponding properties of the principal object

The readAccess function is an asynchronous middleware function that checks if the current user has permission to read a contact resource. It uses the cerbos.checkResource method to make an authorization decision.

The writeAccess function is similar to the readAccess function, but it checks for permission to write to the contact resource instead of reading. It uses the "write" action in the cerbos.checkResource method.

Implement authorized routes

Finally, let's implement routes to check user access using Cerbos.

Import the required middleware functions for read and write access checks:

const {readAccess,writeAccess} = require("./middleware/access");

Update index.js file to include the following routes:

app.get("/read", userMiddleware, readAccess, (req, res) => {
  res.send("Read Access Granted");
});

app.post("/write", userMiddleware, writeAccess, (req, res) => {
  res.send("Write Access Granted");
});

And that’s it! By following these steps, we have successfully implemented authorization and RBAC in our Node.js application using Cerbos.

Test the authorized route

Now, we’ll test to see if the user has permission to do specific tasks.

To check if the user has write access, we'll make a POST request to http://localhost:3000/write with the following headers:

Content-Type: application/json
Authorization: JWT_TOKEN

The user with the admin role has access to this route.

Next, to check if the user has read access, we'll make a GET request to http://localhost:3000/read with the following headers:

Content-Type: application/json
Authorization: JWT_TOKEN

If successful, that will return as Read Access Granted as well.

Finally, let's check a user with the user role to see if it has write access or not. Make a POST request to http://localhost:3000/write with the following headers

Content-Type: application/json
`Authorization: JWT_TOKEN

As expected, we got an unauthorized response. That means the user doesn’t have access to that route.

Conclusion

In this article, we covered the basics of authentication and authorization, and how to integrate JWT authentication and Cerbos authorization into a Node.js application.

How to implement authorization in a React application

Anna — Fri, 06 Sep 2024 12:24:20 +0000

React is a JavaScript-based framework and UI development library as opposed to a programming language. React offers a variety of extensions that make it useful beyond its best-known role as a UI development tool that handles CSS file prefixes. Implementing authorization in a React application using Cerbos produces a slew of benefits we'll get into shortly. But first, here is a simplified step-by-step guide covering how to implement Cerbos authorization into your React app.

Implement Cerbos authorization in a React application

Step 1: Install the Cerbos client library in your React project.
Step 2: Create a Cerbos client instance in a central location within the React app. Typically where you would initialize the application.
Step 3: Be certain that you replace 'http://your-cerbos-server-endpoint' with the endpoint of your Cerbos server.
Step 4: Use Cerbos to check permissions prior to rendering various components or enabling certain actions.
Step 5: Handle unauthorized access by creating custom responses to users who do not demonstrate the necessary permissions.
Step 6: Integrate Cerbos with your React router to control access to specific routes using the Cerbos hook in concert with the useHistory hook from the React router. (Note this step is optional since your React app may not use the React router for navigation.)
Step 7: Don’t forget to adjust the relevant code snippets in accordance with your specific needs.

For more details covering implementation of Cerbos in React applications, please refer here.

Benefits of implementing Cerbos authorization in a React application

Implementing Cerbos into your React app will provide a variety of benefits including:

Fine-grained access control: Cerbos enables you to enforce precise control based on attributes like user roles, actions, resource types and more.
Centralized policy management: Cerbos centralizes and simplifies policy management making it easy to define, manage and update all your access control policies on the fly.
More effective audit and compliance capabilities: Cerbos allows you to monitor all access control decisions thereby enhancing your ability to enforce compliance.
Policy as code: With Cerbos, authorization policies are defined using declarative language making it easy to understand and audit access control policies.
React component level authorization: The Cerbos React library enables you to implement React component level authorization which can produce a more responsive and personalized experience for the user.

Conclusion

In summary, when you integrate Cerbos into your React app you improve application security, flexibility and overall manageability.

Relevant links
Are you looking to improve your application's authorization logic and security? Look no further than Cerbos! Discover how Cerbos works and explore its powerful features:

Detailed React + Cerbos guide
Cerbos playground, where you can easily build and test policies in an online editor
Cerbos ecosystem and its seamless integrations with various SDKs, modern frameworks, and authentication providers
Learn more about Cerbos Hub here

Get started building your first policies with ease and join the companies that trust Cerbos in production for their authorization needs.

PBAC vs. Zanzibar For User Authorization

Anna — Wed, 04 Sep 2024 12:26:10 +0000

Originally published on the Cerbos blog.

When selecting an authorization solution, it’s important to consider your application’s needs. Both Policy-Based Access Control (PBAC) and Zanzibar-based authorization offer unique advantages.

Remember, authorization is not a one-time setup – it's an ongoing process that requires continuous attention and refinement. So choose wisely, but also be prepared to adapt as your application evolves.

Here's a breakdown of approaches.

What Makes PBAC Effective?

PBAC makes access control decisions based on defined policies, providing flexibility and adaptability.

PBAC supports multiple access control models such as ABAC, RBAC, and ReBAC.

With PBAC, policies are evaluated in real time, which is crucial for applications that need to respond quickly to changes in user roles or data.

Advantages of PBAC

Real-Time Decision Making: Ensures access decisions are based on up-to-date data, reducing the risk of unauthorized access.
Flexibility: Adapts to various access control models and can handle complex scenarios.
Ease of Management: Policies are written in a straightforward, human-readable format, making them easy to create, test, and modify.

Why Cerbos’s stateless approach enhances PBAC

Scalability and Performance: Cerbos’s stateless architecture allows for horizontal scaling without the overhead of maintaining state. This enables handling a large number of authorization requests quickly and efficiently.
Simplicity in Deployment: Stateless systems are easier to deploy and manage because they don’t require complex state synchronization across different servers. This makes your authorization infrastructure more resilient and easier to maintain.
Reduced Latency: Without the need to manage state, Cerbos reduces latency in processing authorization requests, making it ideal for applications that demand high performance and low response times.

To learn more about how PBAC and Cerbos’s stateless architecture can optimize your authorization processes, check out how Cerbos implements PBAC.

Where Zanzibar-Based Authorization Fits Best

Zanzibar-based authorization uses a centralized system to manage access control lists (ACLs) for each resource, providing fine-grained control over who can access what. It is well-suited for applications with very large numbers of individual resources requiring individual permissions. Zanzibar offers consistency with a centralized access control logic system.

Benefits of Zanzibar-based Authorization

Fine-grained control: Ideal for managing access to a large number of distinct resources with specific, individualized permissions.
Centralized Management: Provides a single point of control, which can simplify auditing and policy enforcement for large-scale applications.

However, Zanzibar’s centralized nature requires constant synchronization between your application and the authorization system, which can introduce complexity and latency. This approach might be less suitable for applications that need to adapt quickly to changing data and user roles.

PBAC vs. Zanzibar: Choosing the Right Approach

Choosing between PBAC and Zanzibar depends on your application’s specific needs and constraints. Here’s a balanced look at what each approach offers:

Data synchronization:

PBAC with Cerbos: Operates without the need for external state synchronization, eliminating delays and reducing complexity.
Zanzibar: Relies on syncing data with a centralized system, which can add overhead and latency, especially in rapidly changing environments.

Flexibility and adaptability:

PBAC with Cerbos: Supports multiple access control models and can easily adapt to changing requirements, making it suitable for most applications.
Zanzibar: Offers fine-grained control but may not provide the same level of flexibility for applications with dynamic or complex access rules.

Simplicity and ease of use:

PBAC with Cerbos: Easy to implement and manage, with a stateless design that simplifies deployment and enhances scalability.
Zanzibar: Centralized management can be beneficial for consistency and auditing but requires more setup and ongoing maintenance.

If your application deals with dynamic data, frequently changing access requirements, or simply needs a flexible, easy-to-manage solution, PBAC with Cerbos is likely your best bet. It offers adaptability, real-time responsiveness, and the added benefits of Cerbos’s stateless architecture, making it ideal for most modern applications without synchronizing the application state or replicating database records to your authorization layer.

However, if your application manages a static collection of resources with highly specific access controls, Zanzibar could be a strong candidate. Its centralized approach ensures consistent and precise control, which can be advantageous in certain contexts.

Still not sure which approach is right for you? Learn more about how Cerbos can help you implement the best authorization strategy by booking some time to chat with an engineer.