Forem: Cerbos

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:

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.

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.

We Are Developers World Congress; an Engineer's Travelogue

Dan — Wed, 07 Aug 2024 14:33:53 +0000

Written by Cerbos engineer Sam Lock (connect on LinkedIn or GitHub)

Thursday

06:50

My alarm shouts in my ear that it’s time to wake up. I sit up and am momentarily confused, but then remember that I’m in Berlin, in a hotel room, and I’m staffing our company booth at a conference today. My body is aching; I wonder why, but then I remember the 50km I scooter’d across the city the day before. The scooters are electric but the Berlin streets are cobbled and unforgiving. The botanical gardens are nice, though.

I fall out of bed, stand up, glance at the coffee machine. It looks confusing to my sleep-addled brain. I glance at the time, it’s 6:52; “oh, I have loads of time”. I sit down again to catch my breath. A few seconds later, I glance at the time again: 7:10, “but how?”. I pick myself up and hurl myself into the bathroom.

The shower is angry and powerful; I desperately swing for the shower curtain as the torrent pushes me backwards with the force of a thousand rivers. Any residual sleepiness is washed away by adrenaline and the desire to live.

I’m clean and awake now. My bag is packed, I have my ticket ready to go. I glance at the coffee machine again; it looks less intimidating. I fill the reservoir, stab in a capsule, and press the button. It rumbles to life and spits coffee downwards in the general direction of the mug. The table is given a healthy dose, too. I stop briefly to admire the Jackson Pollock-esque artwork adorning the wooden top.

07:28

I feel more alert now. The coffee that made it into the mug has further lifted me from my haze and I head downstairs to meet my colleagues. I realise at this point that I forgot to have breakfast. I reason that I could probably do with skipping a meal and push it to the back of my mind. Not today, hunger.

Our team of four piles into a taxi. I’m kindly offered the front seat. The driver scrambles to clear the newspaper and pastry wrappers before I fold myself in. I’ve been on holiday for a little while, so open up Slack to peruse through the backlog of missed messages from the week prior as we head through the busy roads of rush-hour Berlin.

07:51

We arrive at Messe Berlin. Although I’ve been here the year prior, I’m once again impressed by the sheer size of the place. It’s early, but already there are eager crowds forming. We climb out the car and retrieve the various sacks of merch from the boot. We walk down the grand steps towards the entrance to pick up our passes and wristbands. I’m overcome by a feeling of power and belonging.

I follow my colleagues through the various exhibitor spaces towards our own. My fight-or-flight response kicks in as we pass a booth with a carnival hammer game. The attendee scores well; a couple of our team pledge to better the score later on. We discuss optimal swinging techniques but before we can come to a conclusion, we reach our own booth. Game time.

08:04

We pounce into action. One team member volunteers for a hunter-gatherer mission to find coffee. The remaining members start distributing merch around our allotted square of exhibitor space. There are four of us and two chairs. Thankfully, an unused booth behind us presents us with an additional chair. Only one weary stander. Thank you, conference.

We disappear off to have a swing of the hammer. Our CEO tops the leaderboard early on. Myself and another colleague are less pleased with our results. Probably rigged, I think to myself. Back to the booth.

With the distant thuds of the hammer ringing out, we settle in and get ready for the day as the first attendees start to appear.

“Hello! How are you? What’s Cerbos?”

“Well, tell me what you do, and I’ll see how it could apply…”

10:17

The conversations are rich and varied. Some have felt the pain of authorization and eagerly listen as we share the wonders of Cerbos. Others don’t understand authorization, but have seen our Cerbie plushies from afar. “How can I get one of those”, they ask. “You must care about Cerbos, first.” The denials are awkward, but necessary. Cerbies are finite and surprisingly expensive to produce. Some people come up and shout their desire for a Cerbie to my face. I weather the storm and stand my ground. “No”, I say, bravely.

Talking about authorization is thirsty work. I scour the halls for a water fountain, but alas, no water to be found. I ask a volunteer who offers me no clues but wishes me luck on my search. “Surely, it’s somewhere”. I eventually give up, find a coffee stand, and reluctantly pass over the €4.10 for a small bottle. I get a couple extra for my equally dehydrated colleagues. As I walk back to the stand, I debate with myself whether or not I should tell my boss how much I just spent on water.

13:08

Lunch beckons. I step outside and wait for my eyes to adjust to the light. It’s warm in Berlin; almost too warm. I spy my prize, the fabled “hotdog wrap” van from the year prior. Glorious, gravy and mashed potato filled things. I make haste, buy my food, and refuel. Back to the booth.

15:22

I’ve been tasked with a mission for doughnut retrieval. I’m briefed by a colleague; the doughnut deliverer has set off to the famous “Brammibal’s” (the best doughnut makers in Berlin?). I make a mental note, then return to authorization conversations and Cerbie denials.

16:02

The doughnuts are en route.

My hips start to get sore because I’m a delicate desk-sitter by profession. I do some ad-hoc yoga to limber up.

17:09

Call from the driver. Even closer. I suggest a location and set off across Messe, passing the hammer booth. The exhibitors' faces suggest that they regret their noisy choice of attraction. I continue for about 10 minutes in one direction, find a spot, share my location on Whatsapp, then set up camp.

17:27

Call from the driver. They’re nearby. “Did you see my location?”, I ask. “Yes, I’ll see you there soon”, they reply. Excellent.

17:31

Call from the driver: “I can’t see you”, they say. “Share your location?”, I suggest. 500 yards away. “Damn you”, I think to myself, before setting off in the opposite direction to meet with the confused driver.

I eventually find them, state my name, and claim my prize. “Can I go to the toilet?”, they ask. I’m puzzled. I’m not the toilet gatekeeper. “Probably”, I reply.

18:00

We officially transition to the “booth crawl” section of the day. A colleague procures some beers. They’re slightly warm but taste like liquid wheaty gold. The doughnuts are revealed. I eat one. They’re light and fluffy and delicious. More conversations are had. More people ask for Cerbies. We give out a few. I eat another doughnut. Then another.

19:30'ish

I feel some regret for the quantity of doughnuts I’ve consumed. I feel a bit poorly as we pack up the booth and head out to find a taxi to get back to the hotel, then each disappear off for a short, much needed rest in our rooms before dinner.

21:00'ish

I’m tasked with finding a restaurant so I scour Google maps and find the perfect one nearby. Traditional German food, classic wood furnishings; lovely. I brief my boss that they may be cash-only and he heads off to find some cash. We set off and eventually find the restaurant, but they’ve stopped serving food. I feel ashamed, but thankfully we find a burger joint nearby. They accept card payments.

The burgers were very good; we finish them off then return to the hotel. No hotel beers for this tired lot – straight off to bed.

Friday

06:50

My alarm shouts at me again. I’m bleary-eyed, but today I’m better prepared for the hell-shower and the over-excited coffee machine. I go about my morning routine and prepare for the day.

07:28am

I head downstairs for breakfast. Straight to the cereal bar. I add a spoonful from every jar to my bowl to form a single “super-cereal”. No hungry start for me today. I join my colleague and polish it off before getting some fruit to counteract my thus far beige breakfast.

08:00

Into a taxi and off to the conference. We know the drill – a colleague finds us some coffees and we settle down ready for day 2.

Rumours start to circulate of a little software bug that might be impacting some computers somewhere in the world. Meh – don’t think we need to worry about that.

08:07

We definitely do need to worry about that. We all struggle to check in via our airline apps for our various flights home later in the day, and passively watch on different news outlets as a simple (highly privileged) update brings the world to its knees. Oh well, we’ll talk about authorization until then.

10:42

It’s been a hectic couple of days and our t-shirt supplies are nearly depleted. Only a handful of size “S” remain.

I have an in-depth conversation with someone about their authorization needs. We’re both satisfied with the eventual outcome – they will go away and try to implement Cerbos and we will be happy to answer any questions that they might have. Great!

They ask for a t-shirt. “Sure!”, I say. “Are you [a] small?” I ask. “Yes, I am quite small”, they reply. I curse myself for an unfortunate choice of wording.

12:00

It’s raffle time. A crowd gathers around our booth for the chance to win our grand prize: a Super Nintendo System Lego set! My boss throws some Cerbies into the crowd to warm them up, much like a bouquet-toss at a wedding, and people scrap for them with a surprising level of urgency. People really do love our plushies. Thankfully no-one was hurt.

All the entries were placed into a virtual hat, and a name pulled. A delighted looking recipient came forward on the first draw and we handed it over.

14:23

More yoga. I’m no good at standing up it seems.

The exhibition halls have started to quieten down. People are running out of steam. Not us, though – we’ve depleted our merch-reserves, but the conversations are still flowing.

15:48

Time to go. I share a similar timed flight with our CEO, so we pack up together and head off. As we leave, he points out the water fountain just a stone’s throw from our booth. Whoops. We get in our Uber and anxiously make our way to Berlin Brandenburg to see what havoc CrowdStrike has unleashed upon the airport.

PM

None, it seems. Security and passport control is seamless. I and other travellers play a small game of plane Hokey Cokey as they struggle to find us one with working air conditioning. But we eventually lift off, and bid farewell to Berlin and to We Are Developers for another year.

See you all again next time ✌️

—

Cerbos is an open-source, scalable authorization layer for software applications. It simplifies access control by separating authorization logic from business logic, allowing developers to define and enforce complex policies with ease. Cerbos integrates seamlessly with existing applications and supports various environments, ensuring secure and efficient permission management.

If you have any questions or feedback, or to chat to us and other like-minded technologists, please join our Slack community!

Introduction to RBAC in Kubernetes

Dan — Tue, 30 Jul 2024 13:51:52 +0000

Guest article written by Tania Duggal.

In this article, you will learn what RBAC is, the key challenges and approaches to managing RBAC in Kubernetes, and how Cerbos can help you in your application security.

In Kubernetes, when a request comes to the API Server to create resources, it processes the request in different steps. It first checks from where a request is made and whether a user is valid or not. This process is called authentication. There are two categories of users: normal users and service accounts. Service accounts are managed internally by Kubernetes, and are used by applications that access the cluster, such as the Monitoring Application. Normal users are external entities that may include administrators, developers, and other humans.

After authentication, the next process is authorization for the requested action and permissions. While Kubernetes supports multiple authorization methods, the one we’ll concentrate on in this article is called RBAC.

What is RBAC?

RBAC stands for Role Based Access Control. It is a method through which we can control access to resources and actions based on the roles assigned to the users. In Kubernetes, RBAC is how the administrator can control and allow which actions the users can perform on which resources, respectively. RBAC is managed just like everything else in Kubernetes: as objects that can be described via YAML or kubectl. To enable RBAC, the --authorization-mode flag must be set to RBAC when starting the API server.

kube-apiserver --authorization-mode=RBAC

Core Objects of Kubernetes RBAC

The RBAC API declares four core objects. These are:

Role: It is a way of defining what actions users can perform within a namespace. This defines which actions such as get, list, create, delete, etc., can be performed on specific resources like pods, services, and deployments.
Cluster Role: This is similar to the role, but it is used for cluster-wide permissions. It means it is not limited to a specific namespace and can be used in all namespaces of the cluster.
RoleBinding: RoleBinding binds the role with one or more users, groups, and service accounts in a particular namespace. In this way, whatever permissions we have defined in a role get allotted to the users, groups, or service accounts.
ClusterRoleBinding: ClusterRoleBinding binds the ClusterRole to one or more users, groups, and service accounts throughout the cluster. This allows the permissions defined in ClusterRole to be assigned to users in all namespaces of the cluster.

How RBAC is implemented in Kubernetes

It depends on your requirements and what you want to create for your resources, whether it be a Role or a ClusterRole.

Create a Role and assign it with RoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer
  namespace: default
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "list", "update", "delete", "create"]

We have permitted pods to get, list, update, delete, and create the resources.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: devuser-developer-binding
subjects:
- kind: User
  name: dev-user # "name" is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io

RoleBinding binds the developer Role to a user named dev-user in the default namespace.

Create a ClusterRole and assign it with ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-administrator
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["nodes"]
  verbs: ["get", "list", "delete", "create"]

We have permitted nodes to get, list, delete, and create the resources.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-role-binding
subjects:
- kind: User
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-administrator
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding binds the cluster-administrator ClusterRole to a user named cluster-admin in all namespaces.

Challenges in Kubernetes RBAC

Difficulty in Management: It's difficult to manage RBAC in Kubernetes when you have so many roles and permissions. Each user and service requires particular permission, which can be time-consuming and complex. As the number of users, applications, and namespaces grows, it becomes difficult to handle the RBAC configuration.

For example, if you have a team of developers in different namespaces, you must ensure that each developer can only access the resources that they need. Mistakenly, if any developer gets too many permissions, they can unintentionally modify other's resources.
Scalability Issues: As the organization grows, so does the number of users and roles. This growth is asymmetrical, and the challenge of scaling RBAC manually can quickly become overwhelming. It becomes a huge task to manage and define permissions for each employee. A minor error can lead to a security breach or any operational issue.
Manual Process: When you configure and define RBAC roles and permissions manually, it can be quite dangerous. Even a small mistake can lead to a security breach.

For example, if an administrator has to permit the developer only to read but mistakenly gives permission to him to write as well, then the developer can modify data, which can lead to vulnerabilities.
Logs Auditing and Compliance: It is necessary to maintain accurate and detailed records for auditing and compliance. To follow standards such as GDPR and HIPAA, you have to maintain detailed logs that show which users performed what actions and when. Kubernetes provides limited tools for RBAC auditing, which makes compliance challenging.

Approaches to Addressing Kubernetes RBAC Challenges

Implementing Principle of Least Privilege: Least Privilege means you have to give minimum permissions to the users they need to do their work. Too many permissions can result in security issues. You should follow the least privilege approach to enhance security.
Policy Management Tools: Managing too many policies can be difficult. You can use policy management tools to reduce the burden of managing policies. These tools can create, update, and manage policies for you and ensure RBAC policies are up-to-date and secure.
Namespaced Roles: You should use namespace roles to limit the scope of your resources. With a namespaced role, you can ensure that a user or service only gets access to the resources in that namespace that are necessary for their function. This isolation helps us prevent accidental access.
Auditing RBAC regularly: You should audit your RBAC configuration regularly. With regular lookups on these configurations, you can timely identify issues and fix them.

It's clear that managing Kubernetes access and permissions is quite complex, but it provides a robust security feature at the infrastructure level, and is well worth considering for your future deployments.

Bring powerful RBAC to your applications

Finally, if you're looking to bring that same infrastructure-level power to the application layer, you should check out Cerbos. The Cerbos Policy Decision Point (PDP) is the scalable, open source authorization layer for implementing roles and permissions at the application layer. It can be deployed easily as a sidecar alongside your Kubernetes-managed applications. Try it today!

Cerbos Hub: A complete authz management system

Dan — Thu, 25 Jul 2024 09:45:02 +0000

Good news everyone: Cerbos Hub is now generally available! In this post, we’re going to explain what Cerbos Hub is, why it's useful, and how it solves some of the hardest challenges with externalizing authorization.

Cerbos: Fine-grained authorization and access control

New to all of this? No problem. Cerbos is a scalable and extensible authorization service for developer, product and security teams. It enables teams to implement fine-grained authorization and access control in their applications, services, and infrastructure in an auditable, programmatic, and scalable way. Maybe you’ve heard of RBAC, ABAC, ReBAC, PBAC and so forth? That’s what Cerbos is all about.

The Cerbos open source Policy Decision Point (PDP) is a popular solution for technical teams who’ve made the decision to separate the authorization process from their core application code, freeing them up to concentrate on their core business. It can be deployed as a binary on metal, in a sidecar, as a service in a VM—anywhere on your infrastructure, any way you want.

Cerbos Hub: manage centrally, deploy anywhere

One of the great things about the PDP is how powerful and extensible it is. Cerbos Hub is designed from the ground up to help you harness that power and control that extensibility. The industry term is Policy Administration Point (PAP), but it can be thought of as a control plane. Cerbos Hub is all about unlocking the full potential of the PDPs by providing an intuitive user interface, collaborative policy management, and a powerful testing and deployment pipeline.

Simplified policy management

Cerbos Hub centralizes policy management no matter where or how your PDPs are deployed. With a managed CI/CD pipeline, you can deploy and test policies seamlessly across development, testing, and production environments. No more juggling tools and processes—Cerbos Hub coordinates the rollout of authorization policies across your apps, APIs, and infrastructure.

Whether your infrastructure is on-premise, cloud-based, or serverless, Cerbos adapts to your needs. It supports edge devices, security hardware, and even in-browser runtimes for frameworks like React and Angular through its Embedded Policy Decision Point capability. This means you can authorize anywhere, keeping your policies in sync regardless of the environment. And with Cerbos Hub, managing that synchronization is easier than ever!

Embedded PDP

As one of our engineers so eloquently put it: “This requires some explanation.” Traditionally, when you’re thinking about service delivery, you’re thinking about a binary running in a container or sitting on a virtual machine somewhere. That’s fine, but it’s not the only model.

If you want to perform authorization checks directly from the end-user device, that would mean both exposing your PDP to the Internet and inviting network latency with every call. Another approach is to run those authorization checks on the device, in the browser, or from the edge—that’s where Embedded PDP comes into play.

The Cerbos Embedded Policy Decision Point is a WebAssembly module that runs right in your application, putting authorization checks as close to the user as possible. This reduces your security footprint, improves latency, and unlocks powerful functionality; for example, you can embed authorization checks in your user interface to only render the buttons they actually need to see!

When you update your policies in Cerbos Hub, Embedded PDPs are automatically compiled and distributed to your end-users via global CDN. This simplifies updates and streamlines management of your policies no matter where your end users are.

Robust policy authoring and testing

Cerbos Hub's web IDE lets you collaboratively build and test policies right in your browser! Create policies in YAML with our useful templates, then use the playground to refine, validate, and test those authorization rules. And since everything is ultimately code, this can be tied into your existing deployment workflow, meaning that the validation and deployment of your policies becomes another step in your application management lifecycle. Git actions, artifact generation, automated build and deployment pipelines—it all fits!

However, authorization is more than just code—it’s a representation of how your business functions. Who can access what, where, when, and how, goes beyond deploying your stack. Cerbos Hub is the best way to get everybody involved; from operations, to HR, to accounts payable (and even your CISO), Hub’s collaborative policy-building tools give everybody the opportunity to speak the same language and concentrate on their requirements and business cases.

Get started today!

Ready to level up your authorization game? Try Cerbos Hub and experience the future of authorization management.

Microsoft Entra External ID & Cerbos ✨

Dan — Wed, 26 Jun 2024 13:18:37 +0000

👋 Looking to level up your authentication (authn) and authorization (authz) game? Here's a great tutorial that dives into integrating Microsoft Entra External ID for seamless external authentication and Cerbos for top-notch, fine-grained authorization. You’ll learn about adding authentication to your external-facing apps, how to write policies, and what a policy decision point is. With clear steps, sample code, and just enough YAML to meet your daily quota, you'll learn to create secure and scalable solutions that are actually usable in the real world. Check out the full guide here!

As an added bonus, this is actually part two of a three-part series. If you’re not entirely sure what authentication and authorization are (or just want a refresher before diving into the tutorial), you should definitely check out the first part, too. 😄

Questions? Comments? Hit us up in our Community Slack—let's get that conversation going!

Building secure applications: Key insights on authentication and authorization from Cerbos and Microsoft Entra

Rohit Ghumare — Thu, 04 Apr 2024 13:51:37 +0000

Published by Martin Gjoshevski & Alex Olivier on April 03, 2024

Understanding the critical roles of authentication and authorization is essential in safeguarding data and ensuring system security across various software applications. Our latest collaborative effort between Cerbos and Microsoft sheds light on these critical components, focusing on the powerful synergy between Microsoft Entra External ID and Cerbos for securing applications. This blog post, authored by Martin Gjoshevski, Senior Customer Engineer at Microsoft, and Alex Olivier, Chief Product Officer from Cerbos, a Microsoft Partner, serves as a primer to the indispensable roles played by authentication (AuthN) and authorization (AuthZ), offering insights into their distinct functions and the necessity for a comprehensive security strategy.

-> Read full article on Microsoft's blog

-> Try Cerbos Hub

At the heart of this piece is the differentiation between authentication and authorization - two terms often intertwined but fundamentally different in their roles within cybersecurity. Authentication verifies user identity, acting as the first line of defense against unauthorized access. Authorization, on the other hand, determines what an authenticated user is allowed to do, thereby controlling access to resources and data. This blog post, the first in a series of three, delves into the intricacies of choosing the right authorization approach, exploring both coupled and decoupled AuthN and AuthZ models. It provides a foundational understanding for developers and IT professionals on structuring their security protocols effectively.

Importance of navigating authentication and authorization

Understanding the nuances of authentication and authorization is paramount for anyone involved in software development and cybersecurity. The collaboration between Cerbos and Microsoft illustrates not only the theoretical underpinnings but also practical considerations in selecting and implementing these security measures. The blog offers a comprehensive guide to navigating the complexities of AuthN and AuthZ, making it an essential read for developers looking to bolster their applications' security.

To dive deeper into the intricacies of authentication and authorization and to understand how Microsoft Entra External ID and Cerbos can be leveraged to secure your applications, we highly encourage reading the full article on Microsoft's blog. This will equip you with a thorough understanding and practical insights into integrating these solutions into your security framework.

Key takeaways

Authentication and authorization, while often used interchangeably, serve distinct and critical roles in cybersecurity.
Choosing the right authorization approach, whether it's RBAC, ABAC, or a policy-based model, depends on the specific needs and structure of your application.
Selecting between coupled or decoupled AuthN and AuthZ for your application depends on various factors, such as size, complexity, and nature of the application, security requirements, and so on.
The synergy between Microsoft Entra External ID and Cerbos offers a robust framework for implementing both authentication and authorization, providing flexibility, scalability, and enhanced security for applications.

Stay connected

For those eager to explore Cerbos and its capabilities further, we invite you to try out Cerbos Hub and book a meeting for a more detailed discussion by clicking the buttons below. For a comprehensive exploration of the topics discussed and more insights into authentication and authorization, make sure to read the full article on Microsoft's blog.

-> Try Cerbos Hub

-> Speak to an engineer

Keep an eye out for part 2 of our series, where we'll guide you through the process of integrating Microsoft Entra External ID with Cerbos. We'll delve into how External ID empowers SaaS applications to seamlessly federate identities from a multitude of identity providers, and how Cerbos enhances this ecosystem by facilitating the definition and enforcement of fine-grained authorization policies within applications.

What is an authorization API?

Rohit Ghumare — Wed, 27 Mar 2024 14:27:05 +0000

Published by Furqan Butt on Cerbos Website March 26, 2024

Authorization is not to be confused with authentication, which involves verifying the identity of the user making a request.

Authentication is the first step of application security. A user's identity is verified using credentials like a username and password, security questions, or two-factor authentication. Users are aware that authentication is happening, and they can change their credentials as they see fit.

Authorization, conversely, happens after authentication, ie when a user has already been identified. The organization grants, manages, monitors, and enforces the access a user has to data and services. It usually happens behind the scenes, without a user's knowledge. They also can't change their authorization level but only request it.

Some common scenarios requiring authorization include the following:

Any application that has multiple users with different roles accessing the application needs authorization to ensure users can only access the functionality relevant to their role. Think of an ecommerce platform with sellers, purchasers, and system admins, for example.

Consider this use case, an E-commerce platform has different users that can perform various activities. The authorization API must ensure ensures that each type of user only gets access to the service, functionality, or data relevant to their role and nothing else.

Another example is an HR system with system admins, HR staff, and employees as users. Employees should only be able to access their own profile and see details regarding their leave, incentives, and other performance feedback. System admins must be able to create new users and grant or revoke their access, but they must not be able to access employees' personal information or approve leave requests. And HR staff might have different levels of access to information based on their role or seniority.

Similar scenarios apply to social media platforms and well as banking, healthcare, and government systems.

The role of an authorization API

As mentioned, the best way to implement authorization in modern systems is with the help of an authorization service. An authorization API is an internal system API designed to evaluate and enforce an authenticated user's level of access to system functionalities or application data.

Using an authorization API allows you to decouple the application code and authorization logic and maintain them independently, which serves as a safeguard against any accidental or malicious unauthorized access to client data. Because the authorization logic can be centralized, you are also spared from writing custom logic for each API endpoint. And for organizations serving multiple clients, decoupled authorization architecture makes it easy to achieve data isolation for tenants.

How an authorization API works

A general authorization flow generally looks as follows:

A user's digital identity is stored and managed by an identity provider (IdP). When a user has been authenticated, the IdP issues ID and access tokens (usually a JWT) for further authorization. The authorization API validates the access token, which serves as proof that the user is verified and the data provided with the access token can be trusted.

The next step is to perform scope checks, which includes evaluating the different types of access the user has to system resources or functionality. For example, a user may have read access but no write access to resources or data.

Scope checks are an optional step in the authorization process as a user with admin role has access to the entire system while a regular user may only have access to certain parts of the system. Depending upon the type of user accessing the system, the Authorization API may or may not carry out this step.

Key components of authorization APIs

An authorization API consists of four key components: an access control model, a policy engine, permission management, and audit logging.

Behind the scenes, the authorization API uses an access control model to implement access control for each user. The two most popular access control models widely adopted are role-based access control (RBAC) and attribute-based access control (ABAC).

RBAC authorizes a user to access services or data based on their role within the organization. It's fairly simple to implement, especially when user functions within the organization are clearly defined and permission to various functions is associated with the role. A finance role, for example, would allow a user to perform all activities related to finance.

ABAC authorizes a user to access services or data based on specific attributes. ABAC is more flexible than RBAC because it allows dynamic and more granular authorization decisions. However, it is more complex to implement as it has finer control over what the user can and cannot do. It's best suited to when users in an organization span multiple domains and perform various activities.

The policy engine—also known as the policy decision point (PDP)—is what allows or denies a user access to data or services. This component evaluates the compliance rules and policies and makes the decision whether to grant or deny access to the user.

The permission management component allows administrators to add, modify, configure, and delete policies. The policy engine refers to the permission management component to get the required policies to enforce. When dealing with multiple clients, the permission management component allows centralized policy administration, management, and monitoring of the policies.

Lastly, the audit logging component documents all the activity in the authorization API. Any additions or modifications to policies and access to resources are logged, which can be used for internal and external audits and showing compliance with industry standards. This component is also critical when you need to generate a trail of events for troubleshooting issues.

Use cases for an authorization API

Authorization APIs can help you improve API management, microservices architecture, cloud security, and compliance.

You can use an authorization API to enable secure access to APIs based on user and role permissions. It can also help implement rate limiting and throttling to prevent the overuse and abuse of APIs.

Authorization APIs can provide secure access to microservices based on user role and identity. It can also be used to authenticate and authorize other internal and external microservices and enforce policies for service-to-service communication to maintain security.

Authorization APIs enable secure access to cloud resources based on user role permissions associated with the user. It can be used to enforce multifactor authentication for cloud accounts and for implementing network security policies to protect cloud resources from cyber threats.

Lastly, authorization APIs can help facilitate compliance with regulatory standards such as GDPR, HIPAA, and PCI DSS. It helps provide auditing and logging capabilities to track access to sensitive data and enforce data retention policies to ensure data is stored and deleted appropriately.

Best practices for using an authorization API

Here are some best practices of how to use an authorization API to prevent security incidents.

Limit access to sensitive resources

The less information an authorization API shares with external parties, the less likely it is for exploiters to gain illegitimate access. It is always better to be overly cautious.

Whitelist and blacklist IP addresses to ensure limited access to resources.
Provide basic information in error messages.
Hide all sensitive information from all types of interfaces.
Limit the number of admins and separate access to resources across roles.

Use the principle of least privilege

Overprivileging users or services can increase the potential of breaches. Limiting an entity's access to data, resources, or application functions to only what is required to complete a task helps reduce the attack surface and mitigates the risk of exploitation.

Regularly audit access control policies

Having an additional set of eyes checking your access control policies helps improve your resource access strategy. Regular audits from third-party auditing firms will ensure that any vulnerabilities related to designs are maintained at the highest level.

Conclusion

An authorization API lets you implement access control policies and authorization independent of your core solution to improve flexibility, scalability, and maintainability. It forms part of bigger trends towards centralized authorization strategies and zero trust models to prevent security incidents.

This article explained what an authorization API is, how it works, and how you can use it to protect your software and infrastructure so that you can implement it in your software and infrastructure.

The importance of stateless architecture in authorization systems

Rohit Ghumare — Thu, 14 Mar 2024 15:37:06 +0000

This Blog was originally published on the Cerbos website by James Walker

Stateless is a software architecture where the application holds no information about its operating state or the conditions in which it exists. This contrasts with stateful applications, which do maintain a persistent state throughout their lifetime.

Going stateless might sound complicated, but it can actually simplify system deployment, maintenance, and integration. This article explores what stateless is, how it’s implemented, and why it’s so beneficial to real-world systems such as authorization services.

Understanding stateless architecture

The state of a software system refers to the information available when a function is performed, such as the identity of the logged-in user. A stateful service persists this information, while stateless services reestablish the state each time they’re used.

The paradigm shifts the responsibility for maintaining state onto the client. For example, in a stateless authorization context, the client should provide the authorization layer with the context describing the user issuing the request and the resource they’re trying to access. The service can then use this information to deliver an authorization outcome without having to fetch any further data itself. As a result, each request is completely independent of any other, and the authorization layer has no external dependencies.

The benefits of stateless architecture

Stateless systems have several advantages over their stateful counterparts such as better scalability, improved fault tolerance, and simplicity in implementation.

Their characteristics make them easy to understand and reason about. Each session takes the form of a self-contained transaction where the client issues a request and receives a response. The interaction is handled in the same way each time it occurs because the service holds no state that could affect its outputs.

The following are a few other benefits of going stateless:

Scalability: Stateless services don’t require access to persistent storage, nor do they depend on replicas of a deployment that need to successfully synchronize with each other. This improves scalability — you can launch an unlimited number of instances across a fleet of physical hosts, providing great operating flexibility.
Fault tolerance: Stateless reduces the number of dependencies in your system. The service is naturally more fault tolerant as there’s fewer places where errors can occur. If an issue is encountered, the client can simply repeat its request without having to wait for a state correction to apply on the server.
Simpler debugging and troubleshooting: No server-side state makes it easier to find and fix issues with your services. When a problem occurs in production, you can repeat the client’s request against one of your service’s development instances to observe the sequence of events involved. Errors experienced by stateful services can be difficult to reproduce if they’re caused by the exact server state that prevailed at the time, which isn’t always possible to replicate.

Stateless Architecture Examples

Stateless architecture has received more attention in recent years due to the rising interest in microservices and serverless computing.

However, stateless is a well-established strategy that underpins some of the software systems we take for granted:

HTTP: The ubiquitous HTTP protocol is arguably the best-known example of a stateless system. A new connection between the server and client is created for each request and then destroyed once the response is received. Stateful sessions are only possible when the client identifies itself in each request.
RESTful APIs: REST APIs are stateless services provided over HTTP. Each request that the client makes must provide all the information that the server needs to issue a useful response. The server shouldn’t be assumed to understand a request just because the same client has previously connected.
Serverless computing: Serverless is an increasingly popular model for quickly building and launching apps without having to maintain your own infrastructure. Serverless systems are implemented as stateless functions that run on demand, dynamically creating their operating environment each time they’re called.

The role of stateless in authorization

Stateless architecture is particularly beneficial to authorization layers. Authorization, the act of checking what a user can do within a system — as opposed to authentication, which verifies a user is who they claim to be — is traditionally implemented as a stateful server-side process, requiring complex dependencies to fetch the user’s details and the permissions they hold. This impedes scalability: database performance will reduce with load, and any synchronization problems could cause different instances of the service to return conflicting authorization outcomes.

By contrast, stateless authorization facilitates straightforward decisions with predictable results. The application can fetch the state it requires upfront then present it to the authorization layer as a signed token. The token provides the service with all the data it needs to produce an authorization decision, eliminating external dependencies.

The stateless authorization layer is therefore simpler, more scalable, and easier to implement, especially when multiple clients need to interact with the system. It removes the need to persist and synchronize state across the authorization layer’s instances. Although fetching the state within the application can appear to be an overhead, in reality, most systems will already be holding the required information on the client.

Implementing stateless authorization

Stateless authorization services use the following high-level architecture:

The application calls the authorization layer when it needs to check whether the active user can perform a particular action.
The data sent to the authorization layer includes everything that the service needs to produce an authorization outcome, such as the user’s identity, any permissions or special capabilities they hold, and the identity of the resource that’s been requested.
The authorization layer evaluates the provided data and delivers an authorization result (either allow or deny) back to the application.
If an “allow” result was issued, the application permits the user to perform the requested action against the resource. Otherwise, the user is deemed unauthorized and is blocked from continuing.

Crucially, all the information required to produce the authorization result is provided by the application. The authorization layer isn’t responsible for fetching any details about the user or the resource.

Best practices for stateless authorization

As we’ve seen above, implementing a basic stateless authorization system is relatively straightforward. Once you’ve issued a signed token to a client, it should be able to present it to any instance of your service to access protected resources.

Nonetheless, the difference between a simple and a production-ready authorization layer depends on the details. Here are some best practices to keep in mind.

Ensure proper token management

The integrity of stateless auth depends on proper token management. Fortunately, standards such as JWT have solved most of the challenges in this space. It’s safest to issue and consume them using established community libraries such as jwt-go for Go or jsonwebtoken for Node.js. Rolling your own code for these functions can make you vulnerable to security issues if your signature verification proves to be incorrect.

It’s also important to plan how you’ll handle token expiration and revocation. Ensure that each token carries an expiration time that your service checks during its authorization procedure. If you need to immediately expire a set of tokens, you can rotate the private key that the server used to generate their signatures.

Note that stateless does not mean no persistence at all — stateless in this context refers to not holding the state that’s relevant to a particular client. For more precise expiration controls, you can maintain a central index of issued tokens. When a client presents a token, retrieve the token ID from its payload and check there’s still a match in your index. This allows you to revoke tokens by deleting them from the index.

Use HTTPS for Everything

Any authorization data should be communicated over a TLS-protected connection. This helps prevent leaking of sensitive values such as passwords, authorization grants, and access tokens.

Tokens such as JWTs aren’t encrypted by default — anyone can retrieve a payload by Base64 decoding the token. HTTPS mitigates the risk by preventing bad actors from eavesdropping on authorization activity, but in especially demanding situations, you might also want to encrypt sensitive payload fields for an additional layer of protection.

Select a centralized authorization server

Use a centralized authorization server to store authorization data such as users, roles, role assignments, and details of issued tokens. This permits you to make changes in one place and then immediately apply them across all your services.

Choosing a decentralized approach can be attractive at first, but it tends to become less manageable over the life of your service. It forces you to maintain several authorization server instances and ensure stable synchronization between them. Problems can cause errors and discrepancies to occur.

Centralized authorization eliminates these problems. Although it creates a single point of failure, you can mitigate against this by running multiple replicas of the authorization server to achieve high availability. The overall experience will be more reliable and easier to configure than decentralized systems.

Build upon an established standard

Frameworks such as OAuth and SAML are purposely designed to simplify and standardize authorization procedures. Using them as the basis of your stateless authorization implementation will reduce the risk of security oversights and improve interoperability with other services, such as identity providers.

When you build your own authorization protocol from scratch, you’re responsible for defining how services and clients interact, the ways in which tokens are used, and how authorization is requested, validated, and granted. OAuth and SAML provide a reference for these high-level characteristics, allowing you to focus on building the app-specific authorization policies relevant to your users and resources.

Conclusion

Stateless services don’t persist any information between client sessions. They restore their state for each new session, using information provided by the client.

Stateless architecture is particularly ideal for authorization systems. The ease of scalability and absence of server-side synchronization logic allow you to develop decoupled authorization systems that are both reliable and simple to maintain. The resulting systems can be easily deployed to distributed environments, ready for use by multiple independent microservices.

The next time you’re implementing authorization in your software projects, consider exploring stateless authorization. Using established stateless-compatible protocols such as OAuth 2.0 allows you to easily integrate with identity platforms and reduce the complexity in your apps.

Cerbos Hub: Simplifying Authorization for Developers

Rohit Ghumare — Thu, 25 Jan 2024 19:08:13 +0000

Author, test & deploy

Extend Policy Decision Point (PDP) with centralized authorization

We are excited to announce our public beta launch for Cerbos Hub as well as two new features to make the life of developers and teams simpler when it comes to managing their authorizations!

💥 New feature #1

Embeddable authorization policies via WebAssembly

Cerbos Hub also provides an embeddable version of the policies that allow for taking authorization decisions on-device, at edge, and in environments where it is not possible to run a service.

The Cerbos Hub CI/CD pipeline will produce bundles, keeping them in sync with your policies on every change.

The access to be facilitated in applications will be via the Cerbos SDKs. And they handle auth checks without needing a roundtrip to the backend service.

Check out the documentation for more

💥 New feature #2

Write and test policies in the Cerbos Hub’s IDE Collaborative Playground

For those who are familiar with Cerbos’ open source product, Cerbos PDP, the Cerbos Playground is going to be a familiar concept.

It is the interactive space where users are able to write, test and simulate Cerbos policies in real-time.

Cerbos Hub now has a full-featured collaborative IDE - Cerbos Hub Playground, to develop, iterate and test policy.

It comes with instant feedback on changes, It comes with an automated test runner, it integrates into your git-based workflow, Play with the capabilities of Cerbos without any setup or installation with included sample policies.

Read the documentation for more

Resources

Cerbos Hub - Start for free
Cerbos Hub documentation
Join our Slack Community to be in the know of latest developments
Let us help build or review either your first policy. Book a 30-minute free workshop
Cerbos PDP is open source, feel free to browse or contribute and don't forget to drop a star ⭐️

Nuxt authorization: How to implement fine-grained access control

aldin — Mon, 15 Jan 2024 10:12:26 +0000

In this tutorial you will learn how to use Cerbos to add fine-grained access control to any Nuxt web application, simplifying authorization as a result.

Check out a working example of a Cerbos integration in a Nuxt application on GitHub.

Prerequisites

A working Nuxt web application
Docker installed in your working environment

Steps

Having met the prerequisites, the steps are as follows:

Set up the Cerbos policy repository
Set up the Cerbos PDP
Add the Cerbos client to your Nuxt application
Create an API route
Make permission checks across your Nuxt pages and components

Set up the Cerbos policy repository

A Cerbos policy repository is a collection of YAML files that define access control rules for your application. It's essential for specifying who can do what within your app. These policies dictate the actions different user roles can perform on various resources.

A resource is an application-specific concept that applies to anything that requires access rules. For example, a document is a resource that can be altered, viewed, deleted, etc. by different users depending on the access control rules. Read more about the best practices for structuring your policy repository in our documentation.

Your Cerbos policy repository can be stored on your disk, on git, or any S3-compatible storage system. To set up a Cerbos policy repository on the disk, within the Nuxt application, do the following:

In your project's root, create a cerbos folder, then a policies sub-folder within it.
Within the policies folder, create a YAML file which will contain the rules for performing permission checks in your Nuxt application. For example, create a documents.yaml resource policy file.
Populate the documents.yaml file with rules for actions that can be performed on a document, check the example below. Learn more in Cerbos resource policies documentation.

---
apiVersion: api.cerbos.dev/v1
resourcePolicy:
  version: default
  resource: document
  rules:
    - actions: ['view', 'change', 'destroy']
      effect: EFFECT_ALLOW
      roles:
        - admin
    - actions: ['view', 'change']
      effect: EFFECT_ALLOW
      roles:
        - user
      condition:
        match:
          expr: request.resource.attr.author == request.principal.id

Now we’ve defined a simple resource policy file documents.yaml which allows admin users to view, change, and destroy any document resource within the system. Non-admin users are allowed to view and change the document resource if the condition is matched that the given user is also the document author.

Note that a separate policy file is expected for different types of resources and principals we want to create policies about. To showcase this, in the linked demo GitHub example there is a contacts.yaml resource policy file alongside the documents.yaml one.

Cerbos policy repository can be further enriched with defining context-aware roles, schemas, scopes, tests, and various other features explained in comprehensive Cerbos documentation.

Set up the Cerbos PDP

Cerbos PDP is the Policy Decision Point, a component that evaluates application requests against authZ policies to make access decisions; determining whether a user action on a resource is allowed.

In this demo, we’ll set a Cerbos PDP within your repository, as a separate module, using the previously created cerbos directory. To run Cerbos PDP locally, do the following:

Create a Cerbos PDP server configuration file within cerbos directory. You can name it conf.yaml.
For simplest configuration, within the conf.yaml file define the port exposed for listening to HTTP (and/or gRPC) requests and the location of the Cerbos policy repository. The simplest conf.yaml file would look like the one shown below:

---
server:
  httpListenAddr: ":3592"
storage:
  driver: "disk"
  disk:
    directory: /policies

For more robust configuration, make sure to check our Cerbos PDP configuration documentation.

Your file Cerbos-related file structure now might look like the following:

.
├── cerbos
│   └── policies
│       ├── documents.yaml
│       └── contacts.yaml
└── conf.yaml

Position your terminal within the cerbos directory. If you have Docker installed, you can simply run the following command to start Cerbos PDP locally in a Docker container.

docker run --rm --name cerbos -t \
  -v $(pwd)/policies:/policies \
  -p 3592:3592 \
  ghcr.io/cerbos/cerbos:latest server
  --config=conf.yaml

Cerbos PDP runs as a separate process from your Nuxt application. Here, we ran it as a standalone service within a docker container, but this is not a requirement. Cerbos is designed to be adaptable to your infrastructure. So if you want to run Cerbos PDP as a service, a sidecar, or a lambda function, for instance, check the Cerbos deployment documentation to learn more about Cerbos deployment patterns.

Add the Cerbos client to your Nuxt application

Adding a Cerbos client is essential for simplifying the communication between your Nuxt application and the Cerbos PDP. The Client will allow you to make user permission checks from your Nuxt application in an elegant manner.

To add the Cerbos client to your Nuxt application, follow these steps:

Select the Cerbos client you want to use.
- Choose between @cerbos/http for HTTP interactions or @cerbos/grpc for gRPC in server-side applications.
Install the chosen client package using the npm install command
In your Nuxt project, within the utils folder, create a utility file cerbos.ts to instantiate the Cerbos client.
Export the instance for reuse across your Nuxt application.

The above mentioned cerbos.ts file would look like this:

import { HTTP as Cerbos} from "@cerbos/http";

export const cerbos = new Cerbos("localhost:3592");

Create an API route

A Nuxt API route is a feature in Nuxt.js used to define server-side logic and handle HTTP requests within the Nuxt application. These routes allow developers to create various back-end functionalities in the Nuxt project, such as data fetching, form submissions, or in this case authorization.

To create an API route in Nuxt for Cerbos permission checks:

Create an isAllowed.ts file within the server/api folder of your Nuxt application.
Define and export the event handler
- In isAllowed.ts file, use defineEventHandler from nuxt-helpers to export your API handling function.
- Within this function, call the Cerbos .isAllowed(...) method to check user permissions based on the request's user and resource details.

import { cerbos } from "../utils/cerbos";
// Pull the user info from the session in your Nuxt applications

const user = {
    id: "000012345",
    roles: ["user"]
  }

export default defineEventHandler(async (event) => {
    const query = getQuery(event)

    const document = {
        id: query.documentId as string
    }

    const requestBody = {
        principal: user,
        resource: { // Pull the resource info from the data storage in your Nuxt applications. Pass Resource ID within the event as a query param, like we did here.
          kind: "document",
          id: document.id,
          attributes: {
            author: "000012347"
          }
        },
        action: "approve"
      }    

    const isAllowed = await cerbos.isAllowed(requestBody)
    .catch( (error)=> {
      console.log( error );
      return false;
    })
})

That’s it! You can now universally call this API as /api/isAllowed across your Nuxt application pages and components.

Make permission checks across your Nuxt pages and components

Let’s see the usage of Cerbos permission checks across your Nuxt application pages in action. Let’s say we’ve created a page for each of our documents on the path /documents/[id]. To do that:

Create a documents folder under the pages folder of your application.
Within the documents folder, create an [id].vue file.

Nuxt offers route validation via the validate property in definePageMeta() in each page you wish to validate. The validate property accepts the route as an argument.

To use the /api/isAllowed route defined in the previous step you can add the following snippet to the bottom of your recently created [id].vue (or any other vue) file.

definePageMeta({
  validate: async (route) => {
    const { data: isAllowed } = await useFetch('/api/isAllowed', 
    {
      headers: useRequestHeaders(),
      query: { documentId: route.params.id }
    })
    return isAllowed.value;
  }
})

It’s that simple!

To sum up

All you have to do to use Cerbos authorization in your Nuxt application is to:

create Cerbos policies you will be using to make decisions over who should be able to do what within your application,
run a Cerbos PDP which upon being called will be checking those policies,
install the Cerbos client within your Nuxt application,
create an API route to enable its usage across your Nuxt application,
start invoking the exported API route to perform Cerbos .isAllowed(...) checks and determine whether your application user should be allowed to make a certain action on a certain resource.

Further steps

In this tutorial you saw how to add fine-grained access control with Cerbos to your Nuxt applications. If you liked it make sure to check out Cerbos Hub.

Cerbos Hub saves time managing and synchronizing every Cerbos PDP and policy repository across all your applications and services. It helps connect your Cerbos policy repository and your Cerbos PDP instances and manage them collaboratively and smoothly from a single place.

We also published a series of articles with step-by-step instructions on how to Get started with Cerbos Hub. Take a look if you’re interested in seeing how it works!

Managing Access Control Policies and PDPs with Cerbos Hub

aldin — Thu, 21 Dec 2023 15:58:04 +0000

Previously we published the Get started with Cerbos Hub article where we covered the basics of setting up Cerbos Hub with your policy repository and Cerbos PDP. Then we published the article Authorize on the edge with Cerbos Hub and Embedded PDP bundles where we explored how Embedded PDPs can be utilized within Cerbos Hub to streamline and optimize authorization at the edge. Expanding on that, this post focuses on how to manage your access rules efficiently with Cerbos Hub.

Cerbos Hub streamlines the process of synchronizing access control rules across your apps and services. The tool facilitates collaboration and quick adaptation to changes in app requirements, making the management of access control simpler and more efficient.

In this piece, we’ll walk through a common use case; a simple SaaS application, CerbFinance, with multiple user roles and permissions. And you’ll see how Cerbos Hub manages the changes in policy definitions, making the changes available in the application in real-time.

Tutorial Setup

To follow this tutorial, make sure to set up the Cerbos Hub and connect the Cerbos PDP to the Hub. Fork the demo repository https://github.com/cerbos/cerbos-hub-showcase, check the README, then follow the instructions in the Introduction to Cerbos Hub, with a single exception:

Instead of pasting the workspace and client credentials in the configuration yaml file, there is a .env.example file under the infra/docker/ path of the forked project.

Copy that file and rename it to .env on the same path and paste the values of client ID, client secret, and workspace secret fields.

To get the WASM bundle URL, go to the Decision points page in the sidebar, and select the Embedded tab.

Copy the Bundle URL and paste it to your .env file.

To start the application run the make start command in your terminal.

For full instructions on how to deal with Embedded PDPs, read the Authorize on the edge with Cerbos Hub and Embedded PDP bundles article.

How policies are defined

Our example application is an expense tracking system, in which a user named Frank, a member of the finance team, can view certain sections of the application and perform specific actions, while Finance Managers, and admins have broader access. For this use case, we’ll showcase a dynamic RBAC (role-based-access control) model, where levels of access for users (such as restricting approval rights for expenses) vary depending on the expense status and amount, as well as the user placement in the company hierarchy.

The given SaaS application example shows how Cerbos Hub manages the policy update orchestration for an "expense" resource. The policy defines that:

Finance managers can approve any open expense unless they own the expense.
Team members have a monetary cap on what they can approve.

In our CerbFinance demo application, there is a “View as” dropdown in the top right corner where we can switch between users. We’ll go back and forth between the Finance Manager and the team member roles as we go through this tutorial.

To understand who should be able to do what, we print the roles, departments, and region of the selected user just to the left of the dropdown itself. We have currently selected Derek. Derek is a Finance Manager of the EMEA region, and he is Frank’s supervisor.

The policies definitions we set for this demo dictate that Finance team members are not allowed to do certain things that Finance Managers can do, such as: approve any expenses with an amount higher than $10,000.

Here is a snippet extracted from the policy definitions stating exactly that.

That means that Frank, our finance team member, can only approve expenses less than $10,000. For anything higher than that, a finance manager would need to be involved.

On the front end, what we see on the screenshot below is a list of expenses, alongside basic information such as who submitted the expense, when, the expense amount, the vendor, and the status.

The far right column shows a Details button, which when opened shows us a modal with information on the expense. Actions that can be made against the expense appear as buttons at the bottom, which are colored if they are enabled and gray if they are not. This expense report was submitted by Sally, a sales manager at CerbFinance.

For Derek, all the actions except for ‘Edit’ are enabled. The second we switch to Frank, things change.

Because this expense is higher than $10,000, Frank does not have any of the action buttons enabled for him. Within our demo application, Frank (as anyone else) has specific permissions - he can enter certain areas and do particular tasks. But what if we decide to change these permissions?

Making changes to Policies

Take an instance where the company raises the limit for expense approvals by team members from $10,000 to $20,000. We start by making that change in the policy repository. Go to line 85 of resource_expense.yaml file located on /cerbos/policies/path, and replace the amount value 10000 with 20000. Save and push the change to the policy repository.

The second the update is made, Cerbos Hub starts an automated sequence of actions.

It kicks off the CI/CD pipeline to update the policies, runs tests to check for errors, and once it's all clear, sends out the updated policy across the system.

If any of the tests fail, the build will fail as well, and Cerbos Hub doesn’t send any changes to our Cerbos PDP instances. And we can see the failed tests on the Builds page of our Cerbos Hub workspace.

Click on the commit hash in the far left column. A new page will open, showing the exact test that failed and the details of the failure. In this case it failed because even though we made a policy change to enable finance team members to approve expenses up to the amount of $20,000, the test data is unchanged and still expects a failure.

As it was an intended change, let’s update our tests so they reflect the newly expected behavior, and allow finance team members to approve expenses up to $20,000.

Cerbos Hub also lets us directly edit either the github commit or the commit file that caused the build to fail.

The quickest way to go around it is to go to the expenses_test.yaml file, and find line 240, where it defines the expected results for a finance_team principal approving an expense over $10,000. Replace EFFECT_DENY with EFFECT_ALLOW and push the changes.

Cerbos Hub again starts the CI/CD pipeline to update the policies. And with tests successfully passing this time, it notifies all Cerbos PDP instances of the changes.

On the Decision points page, we can see that the PDP instance is running with the newly built bundle. We confirm this by noting that the latest successfully built commit hash is identical to the bundle hash.

Going back to the front end, you can see that Frank’s view shows the approve/reject actions enabled for Sally’s expense report.

That’s it!

We’ve updated policies in real time. All we had to do is change the policy in our policy repository and make sure that the tests are passing. Cerbos Hub, upon successful build, notifies the Cerbos PDP instances of the change, now allowing Frank to approve the expenses with an amount set to up to $20,000.

This system-wide update happens smoothly, without stopping services or manual updates, ensuring the CerbFinance application keeps running without a hitch.

Join the Beta

Cerbos has launched Cerbos Hub to provide a robust, dynamic, and automated authorization management system. In the provided demo, we witness how effortlessly policies can be updated and enforced in a SaaS application, reflecting changes in real-time without any downtime or deployment hassle.

The Cerbos PDP ensures that authorization logic is transparent, version-controlled, and easy to manage. Cerbos Hub's managed service extends this power, seamlessly integrating with development workflows, providing real-time updates, and ensuring that authorization decisions are made efficiently everywhere, even at the edge.

If you haven't already, join the beta now and save months of developing access control in-house.