DEV Community: Gabriel L. Manor

Building a Secure Flight Booking System with LLM Agent in Langflow

Gabriel L. Manor — Mon, 10 Mar 2025 18:00:00 +0000

LangFlow allows developers and non-developers alike to build AI applications through a visual, drag-and-drop interface. It makes it easier to work with LLMs in workflows and, therefore, serves as the primary tool for developing AI applications.

When these applications handle sensitive data such as financial details, security becomes a top priority. Without proper safeguards, there’s a risk of unauthorized access to personal information or critical operations, which could erode user trust and compromise the system.

There are four key perimeters to implement this type of protection in LangFlow applications. Those are:

Prompt Filtering : Ensures user inputs align with predefined access policies.
RAG Protection : Controls who can access retrieved data based on their permissions.
Secure External Access : Limits interactions with external APIs to authorized users only.
Response Enforcement : Guarantees that users only see the information they’re permitted to view.

In this guide, we’ll use these perimeters to build a secure flight booking system from the ground up. To do that, we’ll use Permit.io, an authorization service, to enforce access controls at every stage. The tutorial will cover creating AI-based workflows for searching flights, checking travel policies, and booking trips, all while keeping sensitive data safe.

Tool Overview

Before we get our hands dirty, let’s examine the tools we will use to build this application.

Langflow is a low-code framework that enables developers to visually design and deploy AI apps with LLMs. It simplifies the integration of AI components by allowing you to create complex workflows via a drag-and-drop interface. In our project, we’ll use Langflow to build three workflows: flight search, information queries, and booking operations, connecting our LLM components with security layers.
Permit.io is an authorization-as-a-service that helps developers implement fine-grained access control in their application. In our system, it will handle access control by protecting sensitive flight data and implementing rules like “only verified users can book flights” or “premium members can access special rates.”

Together, these two tools help us create a secure flight booking pipeline: managing workflows and ensuring every operation follows security rules from search to booking.

Prerequisites

This tutorial assumes you have:

Basic knowledge of Attribute Based Access Control
An OpenAI API key
An Astra DB vector database with:
- An Astra DB application token
- A collection in Astra

Configuring Attribute-Based Access Control Policies

Before we start building our AI agent flow, let’s configure our authorization model in Permit.io.

Here’s what we want our policy to restrict:

Regular users should be able to search for flights but not see sensitive details like seat availability or pricing.
Premium members should get extra privileges, like booking, modifying, and accessing detailed flight data.
Regional users should only be able to search for flights in their allowed area.
Unverified users should have very limited access—they’ll see basic flight info but can’t book or modify anything.

To enforce these rules, we’ll need to create the following resources , actions , attributes , and condition sets :

Resources:

Flight
- Available Actions: search, info , viewprice, viewavailability
- Attributes:
- type (String) – Specifies the type of operation (info, search, booking).
- sensitivity (String) – Defines data sensitivity (public, protected, private).
Booking
- Available Actions: create, modify, cancel, view
- Attributes:
- type (String) – Defines booking operation types.
- sensitivity (String) – Controls access to booking data based on its sensitivity.

User Attributes

User access is determined by three key attributes:

membership_tier (Array) – Defines a user's access level (e.g., basic, premium).
region (String) – Specifies the user’s geographical location (domestic, international).
verified (Boolean) – Indicates if the user’s identity has been confirmed (true/false).

Condition Sets

These condition sets define who can access what, controlling how users interact with resources:

Membership Tier Access: user.membership_tier includes resource.class AND user.verified == true
Regional Restrictions: user.region == "domestic"
Sensitive Data Access: user.membership_tier includes "premium"

Let’s set up attribute-based (ABAC) policies using the Permit.io dashboard.

Setup a New Project and Credentials

To get started, let’s set up a new project and get credentials to connect Permit SDK to our project. To do that, follow the steps:

Create a Permit.io account if you haven’t already
Create a new project named flight-booking in the dashboard
Select your preferred environment (Development/Production) and copy your API Key

Define Resources

Navigate to Policy → Resources in your Permit.io dashboard.
First, let’s create a flight resource. This will handle everything related to flight information and searches:

  {
    "actions": [
      "search", // Search for available flights
      "info", // Get flight details
      "viewprice", // Access pricing information
      "viewavailability" // Check seat availability
    ],
    "attributes": {
      "type": "String", // Controls the type of operation ("info", "search", "booking")
      "sensitivity": "String" // Defines data sensitivity ("public", "protected", "private")
    }
  }

Next, create a booking resource for managing actual flight bookings:

  {
    "actions": [
    "create", // Create new bookings
    "modify", // Change existing bookings
    "cancel", // Cancel bookings
    "view" // View booking details
  ],
  "attributes": {
    "type": "String", // Defines booking operation types
    "sensitivity": "String" // Controls booking data sensitivity
    }
  }

User Attributes

Now, let’s define user attributes to enable fine-grained access control based on user properties like membership tier, region, and verification status.

In Directory → Users → Settings page, define the following user attributes:

{ "membership_tier": "Array", "region": "String", "verified": "Boolean"}

Creating Condition Sets

Now let’s configure the condition sets for our flight booking system:

Navigate to Policy → ABAC Rules
Click ABAC User Sets
Create the following sets:

For membership tier access:

  user.membership_tier includes resource.class AND
user.verified == true

For regional restrictions:

user.region == "domestic"

For sensitive data access:

user.membership_tier includes "premium"

Enforcing Policies

Now we’ll use the policy editor to enforce our access control rules. In the policy matrix, you’ll see our resources and actions with checkboxes for each condition set at the top:

For the booking resource:

  cancel:
  - ✓ members □ regional □ sensitive

  create:
  - ✓ members ✓ regional ✓ sensitive

  modify:
  - ✓ members □ regional ✓ sensitive

  view:
  - ✓ members □ regional □ sensitive

For the flight resource:

  info:
  - □ members □ regional □ sensitive (public access)

  search:
  - □ members ✓ regional □ sensitive

  viewavailability:
  - ✓ members □ regional □ sensitive

  viewprice:
  - ✓ members □ regional ✓ sensitive

These checkboxes enforce our conditions, when multiple boxes are checked for an action, all conditions must be satisfied for the action to be allowed.

Now our access control infrastructure is properly configured, let’s start building our flows.

Building the Flows

Now that we’ve set up our access control infrastructure, let’s build our Flight Booking Agent! We’ll create three flows that demonstrate how to implement security while providing a great user experience.

Setting up local PDP container

First, you’ll need to run your local PDP container for Permit’s ABAC policies:

docker pull permitio/pdp-v2:latest

docker run -it -p 7766:7000 \\
    --env PDP_DEBUG=True \\
    --env PDP_API_KEY=<YOUR_API_KEY> \\
    permitio/pdp-v2:latest

Replace <YOUR_API_KEY> with your Permit API Key. If you don’t have Docker, install it from here.

Flight Search Flow

Let’s build our first and most fundamental flow the flight search. This flow will help users find available flights while ensuring they only see what they’re authorized to access.

First, we’ll gather all the components we need. Open your Langflow canvas and from the components panel, drag over a Text Input (we’ll use this for the JWT token), a Chat Input (for the actual search queries), and a JWT Validator. You’ll also need a Permission Check component. This is important for our security layer. Add an If-Else Router , City Selection Agent, Astra DB , Parse Data , and two Chat Output components.

Now, let’s set up each component carefully. Start with the Text Input , this is where you enter your JWT token. Next, configure your JWT Validator with your JWKS URL:

JWKS URL: "<https://test.com/.well-known/jwks.json>"  
// Replace with your actual JWKS URL

For the Permission Check component, you’ll need to input your Permit.io credentials and specify what resource we’re protecting:

PDP URL: "<http://localhost:7766>" // Your local PDP endpoint
API Key: "your-permit-api-key" // Your Permit.io API key
Resource: "flight"
Action: "search"

The City Selection Agent is where things get interesting. This is our intelligent assistant that will parse user queries and format them properly. Configure it like this:

Model: gpt-4o-mini
Agent Instructions: "You are a flight search assistant. Your job is to:
1. Extract departure and arrival cities from user queries
2. Validate that these are real cities with airports
3. Format the search request for our database
4. Handle cases where cities are unclear or invalid"

For the database interaction, set up your Astra DB component with your database details:

Collection Name: "flights"
Database: "flight_db" // Your database name

Finally, the Parse Data component will format our results nicely for users:

Template: 
"""
Flight {row_number}: {departure_city} to {arrival_city}
Departure: {departure_time}
Airline: {airline}
Flight Number: {flight_number}
Price: ${price}
Available Seats: {seats}
"""

Now comes the important part - connecting everything together. Start by connecting your Text Input’s Message output to the JWT Validator’s JWT Token input. The Chat Input’s “Message” output should go to the If-Else Router’s True Input input.

Now click the Playground and try some realistic search queries like “Find flights from New York to London next week” or “Show me flights from SFO to JFK tomorrow morning”. If everything is working correctly, you’ll either see a nicely formatted list of flights (for authorized users) or an access denied message (for unauthorized users).

Flight Information Flow

Next, let’s create a flow that handles flight policy and information queries. This flow is a bit different from our search flow, instead of searching flight schedules, it helps users understand policies, baggage rules, and other travel information.

Start by gathering your components. Like before, you’ll need some familiar components:

Text Input for the JWT token
Chat Input for questions
JWT Validator
Permission Check.

Now we’re also adding a Local Expert Agent who will be our knowledge base expert, along with a URL Component to fetch policy information. Don’t forget the Parse Data component and two Chat Outputs for handling both successful and denied requests.

The JWT Validator setup remains the same as our search flow, no need to change that configuration. For the Permission Check, we’ll adjust it slightly for information access:

PDP URL: "<http://localhost:7766>"
API Key: "your-permit-api-key"
Resource: "flight"
Action: "info"

Here’s where it gets interesting, our Local Expert Agent. This is the brain of our information flow, so let’s configure it carefully:

Mode: gpt-4o-mini
Instructions: "You are a knowledgeable Local Expert that provides accurate flight policy and service information. You should:
1. Answer questions about baggage policies
2. Explain flight rules and restrictions
3. Provide information about services and amenities
4. Always maintain privacy by not revealing sensitive pricing or route details without authorization"

To give our Expert Agent access to accurate information, set up the URL Component with our policy endpoints:

URLs: ["<https://api.flightpolicies.com/baggage>", "<https://api.flightpolicies.com/services>"]
Output Format: "Text"

To present the information clearly, configure the Parse Data component with this template:

Template: 
"""
Policy Information:
------------------
{policy_title}

Details:
{policy_details}

Additional Information:
{additional_info}
------------------
"""

The connections here create a flow of information from user query to expert response. Connect your Text Input to the JWT Validator and then the Chat Input to the If-Else Router ’s True Input. The JWT Validator feeds into the Permission Check, which determines if the user can access the information.

When testing this flow, try asking natural questions like “What’s the baggage allowance for international flights?” or “Tell me about your pet travel policy.” The Expert Agent will provide detailed, accurate responses while respecting security boundaries.

Flight Booking Flow

Let’s build our most secure flow - the booking system. Looking at the components in the screenshot, we’ll need both standard security components and some specialized ones for handling bookings.

Add these components to your canvas:
- Text Input & Chat Input (for token and booking requests)
- JWT Validator (for authentication)
- Data Protection (for securing resources)
- Permission Check (for booking authorization)
- If-Else Router (for routing based on permissions)
- API Request (for making bookings)
- OpenAI & Data to Message (for handling responses)
- Filter Data (for processing results)
- Astro Assistant Agent (for managing booking interactions)
- Chat Output (for user responses)
Let’s configure the components:
JWT Validator settings:

  JWKS URL: "<https://test.com/.well-known/jwks.json>"

Data Protection and Permission Check settings:

  PDP URL: "<http://localhost:7766>"
  API Key: "your-permit-api-key"
  Resource Type/Resource: "booking"
  Action: "create"

API Request settings:

  URL: "<https://api.flights.com/v1/bookings>"
  Method: "POST"

OpenAI settings:

  Model Name: gpt-4o-mini
  Temperature: 0.15
  Stream: off

If-Else Router settings:

  Match Text: "True"
  Operator: "equals"
  Case Sensitive: off

Assistant Agent settings:

  Model: gpt-4o-mini
  Agent Instructions: "You are a booking assistant that helps  process flight booking requests..."

Looking at the screenshot, connect the components this way:
- Text Input connects to the JWT Validator
- Chat Input splits to OpenAI and Permission Check
- JWT Validator links to both Permission Check and Data Protection
- Permission Check’s “Allowed” output goes to the API Request
- Data Protection connects to Filter Data
- API Request feeds into the Assistant Agent
- Everything routes to appropriate Chat Outputs

When testing, try some booking requests and watch how each security layer validates the request before allowing the booking to proceed.

Conclusion

We’ve built a secure flight booking system that demonstrates all four Langflow security perimeters. The JWT Validator handles Prompt Filtering by validating JWTs and extracting user IDs, ensuring only authorized inputs like flight searches or booking requests move forward. RAG Protection is powered by the Data Protection component, which restricts retrieved data to allowed resource IDs, keeping sensitive flight and booking details safe. The Permissions Check component enforces Secure External Access , checking if users can perform actions like accessing APIs for bookings, with distinct outputs for allowed or denied requests. Finally, Response Enforcement is achieved through the combined efforts of Permissions Check and Data Protection , shaping what users see, such as tailored flight lists or policy info based on their permissions and authorized data.

By integrating Langflow’s AI prowess with Permit.io’s access control, we’ve created a system that:

Protects sensitive travel data
Enforces appropriate access levels
Maintains security across all operations
Provides a smooth user experience

Security in AI applications goes beyond data protection—it’s about building trust while delivering what users need. As you craft your own projects, consider adapting these perimeters to your goals.

Happy building! Got questions? Need help? Join our Slack community!

DeepSeek Completely Changed How We Use Google Zanzibar

Gabriel L. Manor — Thu, 06 Mar 2025 11:00:00 +0000

Google Zanzibar is one of the most well-known fine-grained authorization systems, enabling large-scale applications to define and enforce access control through Policy-as-Graph structures. While powerful, Zanzibar requires a lot of data to sync, yet its implementations lack built-in automation tools. This requires manual management of relationship-based access control (ReBAC) tuples, a process that can easily become tedious and error-prone.

With the rise in popularity and functionality of AI agents, we decided to test an experimental approach: using DeepSeek R1 to automate Zanzibar tuple generation.

Combining Permit.io and DeepSeek R1, we attempted to streamline Zanzibar management by:

Using Permit.io as a user-friendly policy management layer.
Using DeepSeek R1 to generate ReBAC tuples from natural language descriptions.

While not yet production-ready, we think the idea of using AI agents to assist humans in automating access control might not be too far away - and we’d love to hear your feedback on how this model can be further refined and optimized for real-world production deployments.

In this article, we’ll explore:

What Google Zanzibar is and how it works
The challenges of maintaining a Policy-as-Graph system
How Permit.io and DeepSeek R1 can work together
A step-by-step guide to building an AI-assisted Zanzibar deployment

What is Google Zanzibar?

Google Zanzibar is an authorization system developed to manage fine-grained access control across Google's services (e.g., Drive, YouTube, Maps). Instead of using traditional role-based access control (RBAC) or access control lists (ACLs), Zanzibar defines permissions as relationships in a graph , allowing for hierarchical and highly granular access control. By handling millions of authorization requests per second, Zanzibar ensures that even at massive scales, access control remains fast, consistent, and secure.

Why Policy-as-Graph?

Policy-as-Graph structures define entities (users, groups, resources) as nodes and relationships as edges. Instead of listing static permissions, Zanzibar allows access control decisions to be traversed dynamically through relationships.

For example, if:

Alice owns a folder
That folder contains multiple files

Then Alice automatically has access to all the files without explicitly assigning permissions to each one.

Why Relationships?

Google Zanzibar’s Policy-as-Graph enables the creation of Relationship-Based Access Control (ReBAC) policies. ReBAC is an authorization model in which access permissions are determined by the relationships between users and resources rather than static roles or attributes.

As we’ve seen in the previous section, instead of explicitly granting permissions, ReBAC derives access from relationships. This approach is ideal for hierarchical, social, and organization-based systems where permissions naturally follow structured relationships.

What Are Relationship Tuples?

A relationship tuple is a structured way to represent a user-resource relationship in a ReBAC system. Each tuple typically follows this format:

resource_type:resource_id#relation@subject

For example, the tuple:

document:report123#editor@alice

Means that Alice has an editor relationship with the document report123, granting her access based on the policy. Tuples act as building blocks of ReBAC policies, allowing the system to determine who can access what based on predefined relationships.

The Challenge of Maintaining Policy-as-Graph

Understanding ReBAC policies and tuples, we need to discuss the limitations of Zanzibar’s architecture. While extremely powerful, it’s quite difficult to manage at scale.

As you probably guessed, the biggest pain point in this endeavor is manually defining and updating ReBAC tuples.

For instance, if an organization changes its team structure, it must manually update thousands of tuples to reflect new permissions. This is quite time-consuming, error-prone, and difficult to audit and maintain. Without automation, managing Zanzibar at scale quickly becomes unmanageable.

The Solution: Management Layer + AI Tuple Generator

To simplify Zanzibar deployments, we propose a hybrid approach in which:

Permit.io : Provides a policy management layer to simplify Zanzibar-based authorization.
DeepSeek R1 : An AI-powered ReBAC tuple generator capable of translating natural language into structured authorization rules.

How Does This Help?

Automates tuple generation: Instead of manually defining relationships, DeepSeek R1 converts English sentences into structured ReBAC tuples.
Reduces human effort: Developers focus on defining access rules instead of manually writing JSON policies.
Improves accuracy: AI-generated policies reduce the risk of manual errors and inconsistencies.

Is This Production-Ready?

No. AI-generated data extraction for access control still requires human supervision to ensure correctness and security. However, we think this approach is a promising step toward automated fine-grained authorization management.

What Are We Going to Build?

To demonstrate this approach, we’ll build a Zanzibar-powered authorization system where:

A user inputs a natural-language relationship rule (e.g., "The enterprise sales team manages all enterprise-level accounts.").
A Node.js script sends this text to DeepSeek R1, which processes it into a structured ReBAC tuple.
Permit.io syncs the tuple with its access control graph, making it immediately enforceable.

Let’s dive into the tutorial!

Project set-up

To get started, let’s create a new Node.js project.

I assume you have Node.js installed and can understand JavaScript (don’t worry; the basics are all you need).

Create a directory where you want to house the project and open it in a terminal.
Use the following code to create a Node.js app:

npm init -y

Due to DeepSeek’s popularity and increased demand, they’ve had to close their API (At least for now), which is only open for paid and existing customers.

For this tutorial, we’ll use the DepSeek model from Nebius AI Studio using OpenAI SDK. It’s the same full-weight DeepSeek model but hosted on EU servers. Nebius AI Studio is a full-stack AI inference platform that provides seamless access to multiple open-source models for anyone to use.

The OpenAI SDK makes using DeepSeek easy due to its compatibility and zero configuration requirements. We just need to change the baseURL and our API key.

These are the packages that we’ll be using:

nodemon, dotenv, cors, express, openai, and permitio

Install them using the following command:

npm install nodemon dotenv cors express openai permitio

Now we’re done with the installations, we need to get our API keys.

We need two API keys: our Permit API key and our Nebius API key.

Get your Permit API key from your Permit.io dashboard. If you don’t have an account yet, you can create one for free here.
Get your Nebius API key from the Nebius AI Studio.

Put these API keys into your .env file.

Setting Up the ReBAC Schema

As mentioned previously, we are going to set up Relationship-Based Access Control (ReBAC) policies in the Permit.io dashboard.

In your Permit dashboard, click on the “Policy” tab on the left panel and add in your resources by clicking “Add Resource”.

Suppose we are building this DeepSeek R1 relationship tuple generator for a product organization. This organization has different teams and accounts, and teams can only manage the accounts associated with them.

We’ll create two resources: team and account. The team resource will have a manages relationship with the account resource.

The account resource will have a level attribute:

After creating your resources, click on the “Directory” tab on the left panel and add your resource instances.

In our case, we want to create resource instances of:

A team will represent the users that handle enterprise sales
An account will represent the enterprise account where proceeds from enterprise sales are deposited

Add the resource instances: team:enterprise_sales and account:enterprise.

With all of the different elements that comprise our relationship-based policy, in the next section, we’re going to build out the relationship tuple generator.

Building the Node.js + DeepSeek Parser

Configuring our Node.js application

Create an index.js file and add the following configuration:

const { Permit } = require("permitio");
const express = require("express");
const dotenv = require("dotenv");
const { OpenAI } = require("openai");
const cors = require("cors");

dotenv.config();

const permit = new Permit({
  pdp: "<http://localhost:7766>",
  token: process.env.PERMIT_API_KEY_PROD,
});

const openai = new OpenAI({
  baseURL: "<https://api.studio.nebius.ai/v1/>",
  apiKey: process.env.MY_OWN_NEBIUS_API_KEY,
});

const app = express();
const PORT = process.env.PORT || 3000;

app.use(express.json());
app.use(cors());

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

In the code above, we’re setting up the configurations of our app, including OpenAI and Permit.

Prompt engineering

In this section, we’ll create two functions for generating a prompt and parsing the AI response into an object.

In the index.js file, add the following code:

function generatePrompt(userInput) {
    return `Parse the following sentence into a REBAC relationship tuple for use in Permit.io:

      Sentence: "${userInput}"

      Identify the following:
      - **Subject:** Include type and instance if available (e.g., "team:enterprise_sales").
      - **Relation:** Extract the main action verb (e.g., "manages").
      - **Object:** Include type and instance if available (e.g., "account:enterprise").
  - **Attributes:** Extract any metadata or qualifiers relevant to the object (e.g., {"level": "enterprise"}). If no attributes exist, return an empty object.

  Return the result in this JSON format:
  \\`\\`\\`json
  {
    "subject": "type:id",
    "relation": "verb",
    "object": "type:id",
    "attributes": {
        "key": "value"
        }
  }
  \\`\\`\\`

  Ensure that the response remains consistent in format, with exact JSON keys as shown, even if some fields are empty.`;
  }

function transformJson(jsonString) {
    const jsonMatch = jsonString.match(/```
{% endraw %}
json\\n({[\\s\\S]*?})\\n
{% raw %}
```/);
    const extractedJson = jsonMatch ? jsonMatch[1] : null;
    try {
      const data = JSON.parse(extractedJson);

      // Return the JSON string with correct formatting
      return data;
    } catch (error) {
      console.error("Invalid JSON input:", error);
      return null;
    }
  }

The generatePrompt function returns the prompt we will use to prompt the DeepSeek R1 model. We are using a function to get the response to ensure a fairly consistent result for the same input.

The transformJson function parses the AI response for the generated relationship tuple and returns it as an object.

Creating ReBAC Relationships

In this section, we will create a relationship tuple in Permit using the Permit SDK and the object returned by transformJson function.

Use the following code to create a ReBAC relationship tuple in Permit:

/* example structure:

"rawRebacTuple": {
     "subject": "team:enterprise_sales",
   "relation": "manages",
   "object": "account:enterprise",
   "attributes": {
           "level": "enterprise"
    }
}
*/
const result = await permit.api.relationshipTuples.create({
    subject: `${rebacTuple?.subject}`,
    relation: `${rebacTuple?.relation}`,
    object: `${rebacTuple?.object}`,
});

Our final index.js should look like this:

const { Permit } = require("permitio");
const express = require("express");
const dotenv = require("dotenv");
const { OpenAI } = require("openai");
const cors = require("cors");

dotenv.config();

const permit = new Permit({
  pdp: "<http://localhost:7766>",
  token: process.env.PERMIT_API_KEY_PROD,
});

const openai = new OpenAI({
  baseURL: "<https://api.studio.nebius.ai/v1/>",
  apiKey: process.env.MY_OWN_NEBIUS_API_KEY,
});

const app = express();
const PORT = process.env.PORT || 3000;

app.use(express.json());
app.use(cors());

app.post("/generate-rebac", async (req, res) => {
  const { text } = req.body;

  function generatePrompt(userInput) {
    return `Parse the following sentence into a REBAC relationship tuple for use in Permit.io:

      Sentence: "${userInput}"

      Identify the following:
      - **Subject:** Include type and instance if available (e.g., "team:enterprise_sales").
      - **Relation:** Extract the main action verb (e.g., "manages").
      - **Object:** Include type and instance if available (e.g., "account:enterprise").
  - **Attributes:** Extract any metadata or qualifiers relevant to the object (e.g., {"level": "enterprise"}). If no attributes exist, return an empty object.

  Return the result in this JSON format:
  \\`\\`\\`json
  {
    "subject": "type:id",
    "relation": "verb",
    "object": "type:id",
    "attributes": {
        "key": "value"
        }
  }
  \\`\\`\\`

  Ensure that the response remains consistent in format, with exact JSON keys as shown, even if some fields are empty.`;
  }

  const prompt = generatePrompt(text);

  function transformJson(jsonString) {
    const jsonMatch = jsonString.match(/```
{% endraw %}
json\\n({[\\s\\S]*?})\\n
{% raw %}
```/);
    const extractedJson = jsonMatch ? jsonMatch[1] : null;
    try {
      const data = JSON.parse(extractedJson);

      // Return the JSON string with correct formatting
      return data;
    } catch (error) {
      console.error("Invalid JSON input:", error);
      return null;
    }
  }

  try {
    const response = await openai.chat.completions.create({
      temperature: 0.6,
      messages: [
        {
          role: "system",
          content: prompt,
        },
      ],
      model: "deepseek-ai/DeepSeek-R1",
    });

    const responseText = response.choices[0].message.content;
    const rawRebacTuple = transformJson(responseText);

    const result = await permit.api.relationshipTuples.create({
      subject: `${rebacTuple?.subject}`,
      relation: `${rebacTuple?.relation}`,
      object: `${rebacTuple?.object}`,
    });

    console.log(result);
    return res.status(200).json({
      success: true,
      responseText,
      rawRebacTuple,
      rebacTuple,
      relationTupleCreated: true,
    });
  } catch (error) {
    console.error(error);
    return res.status(500).json({
      success: false,
      error: error.message,
      relationTupleCreated: false,
    });
  }
});

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

Testing and Validation

Now it’s time to test our application. I’ll use the following text: "The enterprise sales team manages all enterprise-level accounts."

Since our interface is a Node.js application, we’ll use Postman to test our integration.

Go to the Postman website or use the desktop application (if you have it installed). Add the URL and the prompt (mark it as raw), and send the request.

You should get something like this:

If you check the team:enterprise_sales and account:enterprise resources in your dashboard, you’ll see that the relationship has been added automatically.

Real-world usage

To truly function in a real-world environment, an AI-enhanced access control system must integrate with several additional event-driven workflows, automated access request systems, and AI-driven permission management tools. Below are key integrations that would be required for such a system to operate efficiently in production.

Event-driven system for syncing relationships

Real-world applications require real-time updates to keep access control policies synchronized with changes in user activity, resource creation, and system events. An event-driven architecture ensures that access control remains up to date without manual intervention.

How Would it Work?

An event listener detects an event (e.g., a new transaction, resource creation, or user action) when it occurs.
The system interprets the event and determines whether it requires an update in access control policies.
A Graph API call is made to Permit.io (or another access control platform) to update relationships dynamically.

This type of integration eliminates manual updates, ensuring that access control scales efficiently in dynamic environments.

AI-Powered Permission Bots for Automated Access Requests

A Permission Bot would act as an intelligent assistant that automates access requests and approvals, reducing dependency on IT teams while maintaining security policies.

How Would it Work?

A user requests access using a conversational interface (e.g., Slack, Teams, or a chatbot).
- Example: “Can I get editor access to the sales dashboard?”
Natural Language Processing (NLP) interprets the request and verifies the user's current permissions.
If the user is eligible , the bot grants access automatically through the access control system.
If approval is required, the bot notifies an admin , providing them with a simple way to approve or deny the request.

AI Agents for Proactive Permission Management

Rather than waiting for users to request access, AI Agents can anticipate permissions needed and proactively request them on the user's behalf.

How Would it Work?

The AI agent monitors user activity and detects when a permission issue is likely to occur.
If a user attempts to access a restricted resource, the AI automatically initiates a permission request.
The AI agent can also predict access needs based on behavior, preemptively requesting access before users even realize they need it.

Example Use Cases

Scenario 1: Proactive Permission Requests

Alice tries to access a restricted bug report but lacks the necessary permissions.
Instead of Alice manually requesting access, the AI agent immediately notifies the admin:
- “User Alice needs read access to a bug report. Should I grant permission?”.

Scenario 2: Predictive Access Based on Behavior

A content writer is working on an article and needs access to supporting research files.
The AI agent detects this activity and automatically grants temporary access to the relevant documents.
Once the task is completed, access is revoked, ensuring the principle of least privilege compliance.

The Future of AI-Driven Access Control

This “experiment” demonstrates how AI can assist in automating fine-grained authorization within Google Zanzibar by leveraging DeepSeek R1 and Permit.io. By using natural language processing to generate ReBAC tuples, we eliminate much of the manual overhead typically associated with managing relationship-based access control.

However, for this approach to be real-world ready, it requires further integrations with:

Event-driven systems to ensure real-time synchronization of permissions.
AI-powered permission bots to automate access requests and approvals.
Proactive AI agents to predict and preemptively manage permissions.

While this solution is not yet production-ready, it signals a shift towards AI-assisted access control, reducing complexity while maintaining security and compliance. As organizations scale, automated, intelligent permission management will become essential to handle the growing complexity of fine-grained authorization at scale.

We’d love to hear your thoughts on how you would refine this model. What other AI-driven enhancements would make authorization even more seamless?

Let us know your thoughts in our Slack community!

Building AI Applications with Enterprise-Grade Security Using RAG and FGA

Gabriel L. Manor — Fri, 08 Nov 2024 07:30:00 +0000

This post is written by Bartosz Pietrucha

Introduction

Building enterprise-grade LLM applications is a necessity in today's business environment. While the accessibility of models and APIs is improving, one significant challenge remains: ensuring their security and effectively managing their permissions.

To address this, Fine-Grained Authorization (FGA) and Retrieval Augmented Generation (RAG) are effective strategies for building secure, context-aware AI applications that maintain strict access control. In this article, we’ll explore how FGA and RAG can be applied in a healthcare setting while safeguarding sensitive data.

We’ll do this by guiding you through implementing a Relationship-Based Access Control (ReBAC)authorization system that supports real-time updates with three tools: AstraDB, Langflow, and Permit.io.

Use Case Example: Healthcare Applications

To better understand the complexity of authorization in LLM applications, and the solutions offered by FGA and RAG, we can look at the digital healthcare space - as it presents a perfect example where both AI capabilities and stringent security are essential. Healthcare providers increasingly want to leverage LLMs to streamline workflows, improve decision-making, and provide better patient care. Doctors and patients alike want easy access to medical records through intuitive AI interfaces such as chatbots.

However, medical data is highly sensitive and should be carefully regulated. While LLMs can provide intelligent insights, we must ensure that they only access and reveal information that users are authorized to see. Doctors, for example, should only see diagnoses from their assigned medical centers, and patients should only be able to access their own records.

Security Through Fine-Grained Authorization

Proceeding with the digital healthcare example, let’s look at an example of a medical application.

This application is comprised of several resources, a couple of roles, and a few relationships between these entities:

Resource Types :
- Medical Centers (e.g., London, Warsaw)
- Visits (e.g., Morning Visit, Afternoon Visit)
- Diagnoses (e.g., Diabetes, Headache, Virus)
Roles :
- Doctors (e.g., Dr Bartosz)
- Patients (e.g., Gabriel, Olga)
Relationships :
- Doctors are assigned to Medical Centers
- Visits belong to Medical Centers
- Diagnoses are part of Visits
- Patients are connected to their Visits

As you can see, the hierarchal relationships of our resources mean implementing traditional role-based access control, where permissions are assigned directly, will be insufficient.

The complexity of this applications authorization will require us to use more fine-grained authorization (FGA) solutions - in this case, Relationship-Based Access Control (ReBAC).

ReBAC, an authorization model inspired by Google's Zanzibar paper, derives permissions from relationships between entities in the system - unlike traditional role-based access control (RBAC), where permissions are assigned directly.

The power of ReBAC lies in how permissions are derived through these relationships. Let’s look at a visual representation of our example:

In the above example, Dr Bartosz has access to the Virus diagnosis not because of a directly granted permission but rather because he is assigned to Warsaw Medical Center, which contains the Afternoon Visit, which contains the diagnosis. Thus, the relationships between these resources form a chain that allows us to derive access permissions.

There are clear benefits to using this approach:

It models real-world organizational structures naturally
Permissions adapt automatically as relationships change
It provides fine-grained control while remaining scalable

But the challenge doesn’t end there - as we are building a system that needs to work with LLMs, it needs to have the ability to evaluate these relationship chains in real-time. In the next section, we will learn how to create an implementation that allows that.

Before we continue, let's quickly review the authorization rules we want to ensure are in place:

Only doctors with valid relationships to a medical center can see its visits
Access to diagnoses is automatically derived from these relationships
Changes in relationships (e.g., doctor reassignment) immediately affect access rights

These requirements can be achieved through the use of Retrieval Augmented Generation (RAG).

Retrieval Augmented Generation (RAG)

RAG (Retrieval Augmented Generation) is a technique that enhances LLM outputs by combining two key steps: first, retrieving relevant information from a knowledge base, and then using that information to augment the LLM's context for more accurate generation. While RAG can work with traditional databases or document stores, vector databases are particularly powerful for this purpose because they can perform semantic similarity search, finding conceptually related information even when exact keywords don't match.

In practice, this means that when a user asks about "heart problems," the system can retrieve relevant documents about "cardiac issues" or "cardiovascular disease," making the LLM's responses both more accurate and comprehensive. The "generation" part then involves the LLM synthesizing this retrieved context with its pre-trained knowledge to produce relevant, factual responses that are grounded in your specific data.

For our implementation, we will use AstraDB as our vector database. AstraDB offers the following benefits:

It efficiently stores and searches through embeddings
It scales well with growing data
It integrates well with LLM chains like Langflow (which we will cover later in the article)

To implement our RAG pipeline, we'll also use LangFlow, an open-source framework that makes building these systems intuitive through its visual interface. LangFlow systems can be developed with a Python environment running locally or in the cloud-hosted DataStax platform. In our case, we are choosing the second option by creating a serverless (vector) AstraDB database under: https://astra.datastax.com

In our implementation, authorization checks should happen at a crucial moment - after retrieving data from the vector database but before providing it to the LLM as context. This way, we maintain search efficiency by first finding all relevant information and later filtering out unauthorized data before it ever reaches the LLM. The LLM can only use and reveal information the user is authorized to see.

These security checks are implemented using Permit.io, which provides the infrastructure for evaluating complex relationship chains in real time. As your data grows and relationships become more complex, the system continues to ensure that each piece of information is only accessible to those with proper authorization.

To get started with Permit, you can easily create a free account by visiting the website at https://app.permit.io. Once your free account is created, you'll have access to Permit's dashboard, where you can set up your authorization policies, manage users and roles, and integrate Permit into your applications. The free tier offers all the necessary features to create a digital healthcare example with relationship-based access control (ReBAC).

Both LangFlow and Permit offer free accounts to start work, so you don’t have to pay anything to build such a system and see how it works for yourself.

Implementation Guide

Before we dive into the implementation details, it's important to understand the tool we'll be using - Langflow. Built on top of LangChain, Langflow is an open-source framework that simplifies the creation of complex LLM applications through a visual interface. LangChain provides a robust foundation by offering standardized components for common LLM operations like text splitting, embedding generation, and chain-of-thought prompting. These components can be assembled into powerful pipelines that handle everything from data ingestion to response generation.

What makes Langflow particularly valuable for our use case is its visual builder interface, which allows us to construct these pipelines by connecting components graphically - similar to how you might draw a flowchart. This visual approach makes it easier to understand and modify the flow of data through our application, from initial user input to the final authorized response. Additionally, Langflow's open-source nature means it's both free to use and can be extended with custom components, which is crucial for implementing our authorization checks.

Our Langflow solution leverages two distinct yet interconnected flows to provide secure access to medical information:

1. Ingestion Flow

The ingestion flow is responsible for loading diagnoses into AstraDB along with their respective embeddings. We use MistralAI to generate embeddings for each diagnosis, making it possible to perform semantic searches on the diagnosis data later. The key components involved in this flow are:

Create List: This component is used to create a list of diagnoses to ingest into AstraDB.
MistralAI Embeddings : This component generates embeddings for each diagnosis, which are stored in AstraDB.
AstraDB : AstraDB serves as the vector store where the diagnoses and their embeddings are stored for further retrieval.

2. Chat Flow

The chat flow is responsible for interacting with users and serving them the required diagnosis data. The images below are supposed to be read from left to right (the right side of the first one continues as the left side of the second one):

💡 Note: There is an additional “_ Pip Install” _ component that is executed only once to install permit module. This is because we are implementing LangFlow on DataStax low-code platform. This step is equivalent to executing pip install permit locally.

The sequence of operations in the Chat Flow is as follows:

User Input : The user initiates the interaction by typing a query.

Example: "Do we have any patients with diabetes diagnosis?"

Retrieve Diagnoses : AstraDB is queried for relevant diagnoses based on the user's input.

Example search result (marked with 1 on the flow image above):

Filter Data Based on Permissions : Before sending the response to the next processing component, creating the context for LLM responding to the initial query, we filter the retrieved diagnoses using a custom PermitFilter component to ensure the user has the right to view each diagnosis.

Example filtered results (marked with 2 on the flow image above):

Generate Response : Once filtered, the permitted diagnoses are used as the context to generate a response for the user prompt using MistralAI.

Example prompt with context filtered with authorization step:

Seasonal Migraine
Flu virus with high fever

---
You are a doctor's assistant and help to retrieve information about patients' diagnoses.
Given the patients' diagnoses above, answer the question as best as possible.
The retrieved diagnoses may belong to multiple patients.

Question: list all the recent diagnoses

Answer:

PermitFilter Component

To run the PermitFilter component, which plays a crucial role in our implementation, we need a running instance of Permit's Policy Decision Point (PDP). The PDP is responsible for evaluating policies and making decisions on whether a given action is permitted for a specific user and resource. By enforcing this permission check before the context reaches the language model, we prevent the leakage of sensitive information and ensure the enforcement of access control policies.

See It In Action

The complete implementation is available in our GitHub Repository, where you'll find:

Custom LangFlow components
Permit.io integration code
Detailed setup instructions
Example queries and responses

To start interacting with our AI assistant with authorization checks implemented we can simply start the LangFlow playground. In the example below, I am authenticated as bartosz@health.app which means I have access to only Afternoon-Visit and Evening-Visit without Morning-Visit with Diabetes. This means that the LLM does not have the information about diabetes in its context.

Conclusion

Securing access to sensitive healthcare data while leveraging LLM capabilities is both a priority and a challenge. By combining RAG and fine-grained authorization, we can build AI applications that are both intelligent and secure. The key benefits are:

Context-aware responses through RAG
Precise access control through ReBAC
Natural modeling of organizational relationships
Scalable security that adapts to changing relationships

Using tools like LangFlow and Permit.io, healthcare providers can implement relationship-based access control systems that respond dynamically to role and relationship changes, ensuring data is accessible only to authorized individuals. By integrating these solutions, healthcare organizations can effectively harness AI to improve patient care without compromising on security.

How Custom GitHub Actions Enabled Us to Streamline Thousands of CI/CD Pipelines

Gabriel L. Manor — Wed, 18 Sep 2024 18:50:00 +0000

Introduction

Since the early days of Permit.io, we have understood that building a secure and reliable Authorization service depends on how it integrates with the software development lifecycle. For this reason, besides providing our users with comprehensive authorization as a service product, we invest heavily in solving the challenge of automating CI/CD pipelines while maintaining consistent permission management across various environments.

Our main goal with this holistic Authorization approach is to ensure these processes are not only seamless but also accessible and efficient for any development team.

By integrating GitHub Actions with our APIs, we've created a model that supports development organizations at scale. This blog will walk you through how we leveraged these tools to automate environment management in our workspace, making it accessible to CI/CD pipelines.

Understanding Your Architecture for the CI/CD

The first and (maybe the most important) step in creating a GitHub action is to examine your system’s architecture and understand the structure you aim to streamline in your CI/CD.

When building Permit.io, we’ve built a system that allows developers to externalize their authorization to our hybrid cloud service. While the core of the product is, of course, letting the application code decide what users are allowed or not allowed to do, it was also built to support the common hierarchies of software development organizations.

This is evident in Permit’s workspace hierarchy:

Workspace - comparable the the whole development organization. You can think of it as a GitHub organization.
Project - a single application that your organization manages. It can be thought of as a code repository, but it is also flexible enough to support either multi- or mono-repo architectures. A workspace can include multiple projects.
Environment - the silo of policies and configurations inside each project. The environment allows every organization to manage their CI/CD process in the same way they are managing it in their SDLC. It is comparable to a Git branch. Each project has a default of Production and Development branches, but a user can create as many as they want.

The Advantages of a CI/CD Structure

Understanding the structure of your CI/CD process is halfway to solving the streamlining process. The environment-project model is built to provide flexibility and control across multiple stages of development. At its core, it allows our users to:

Create Isolated Environments: Each environment is independent yet can replicate production settings, making it ideal for testing and development.
Manage Permissions Seamlessly: Permission management is consistent across environments, ensuring that your CI/CD process is both secure and reliable.
Automate Workflows: Permit integrates smoothly with CI/CD tools like GitHub Actions, enabling automated environment creation, testing, merging, and cleanup.

As mentioned, this model is especially useful in scenarios where environments need to be dynamically created, tested, and merged—making it perfect for PR-based workflows.

With this model in mind, let’s identify the automation and streamlining challenges.

Workflow Friction: Identifying the Challenges

To fully support the seamless integration of an authorization service to existing users' environments and architecture, we need to identify the events and connection points of our permissions system with the software development system.

At the basic level, a new environment needs to be created in Permit for every pull request (PR). This allows isolating configuration from the production and staging environments, running tests to ensure branch and environment protection, and merging changes into production, all with minimal manual intervention.

This process involves the following steps:

Environment Creation: We want to let our users automate the process of creating a new Permit environment for each PR. We also understand that not every PR should have an authorization configuration change, so we want to ensure that we are opening new environments only for relevant PRs.
Environment Testing: For each PR, we want to run integration and product tests against the relevant environment to ensure the accuracy of permissions and settings.
Merging and Cleanup: After a PR is approved, we want to merge the Permit environment with the production environment. This will allow us to ensure streamlined deployment and delivery.

Manually managing these tasks can be error-prone and time-consuming, compelling us to find a reliable way to automate them. With CI/CD in mind, we want to streamline the continuous integration of the first two steps and the continuous deployment and delivery of the last.

Now that we understand the requirements let’s create our GitHub action:

Creating a Custom GitHub Action

As described, our GitHub Action incorporates three workflows that fully automate the environment management process:

new-env.yaml : Creates a new environment when a PR is opened or updated.
run-pdp.yaml : Runs tests in the newly created environment.
merging.yaml : Merges the environment changes into production and then deletes the PR-specific environment.

These workflows utilize Permit’s API to dynamically manage environments, providing a streamlined and error-free process. You can see this workflow in action in the following code repository: https://github.com/permitio/pink-mobile-demo-app/tree/main/.github/workflows

Let’s take a look at the code and understand its steps -

Workflow Breakdown

1. Creating a New Environment (`new-env.yaml`)

When a new PR is opened or updated, we trigger a workflow responsible for creating a new environment within Permit. We will create this environment using Permit’s copy environment API to replicate the production settings, ensuring consistency across all environments.

Trigger the Workflow:

The first step of running our workflow is to trigger it as a result of events in our code. We can do this by using the following command:

name: demo-new-env
on:
  pull_request:
    types: [opened, reopened]

This will ensure our workflow is triggered. In the next step, we’ll set it up with some variables.

Set up the environment:

Define the project ID as an environment variable. This will be used in subsequent API calls.

This project is the one the environment will be created in. In production, you can get it from a GitHub variable.

env:
  PROJECT_ID: 1238e459351a8470

Check Creation Relevancy

To ensure we are not opening a redundant environment in Permit for PRs that are not relevant for permissions changes, you’ll need to label PRs with a Permissions tag. This will serve as a condition for creating an environment:

jobs:
  demo-new-env:
    if: contains( github.event.pull_request.labels.*.name, 'permissions')

Extract the Branch Name:

Next, extract the branch name. We will need it to name our new environment:

- name: Extract branch name
  run: echo "branch=${GITHUB_HEAD_REF:-${GITHUB_REF#refs/heads/}}" >> $GITHUB_OUTPUT
  id: extract_branch

Create the New Environment:

Create a new environment in Permit. This is done by posting the environment details, including a unique key derived from the branch name:

- name: Create new environment
  run: |
    response=$(curl -X POST \\
      <https://api.permit.io/v2/projects/$>{{ env.PROJECT_ID }}/envs \\
      -H 'Authorization: Bearer ${{ secrets.PROJECT_API_KEY }}' \\
      -H 'Content-Type: application/json' \\
      -d '{
        "key": "pr-${{ steps.extract_branch.outputs.branch }}",
        "name": "pr-${{ steps.extract_branch.outputs.branch }}"
      }')

    echo "ENV_ID=$(echo "$response" | jq -r '.id')" >> $GITHUB_ENV
    echo "New env ID: $(echo "$response" | jq -r '.id')"

Fetch the Environment API Key:

The workflow will retrieve the API key for the newly created environment, which will be used in subsequent workflows:

- name: Fetch API Key of the new environment
  run: |
    response=$(curl -X GET \\
      <https://api.permit.io/v2/api-key/$>{{ env.PROJECT_ID }}/${{ env.ENV_ID }} \\
      -H 'Authorization: Bearer ${{ secrets.PROJECT_API_KEY }}')

    ENV_API_KEY=$(echo "$response" | jq -r '.secret')
    echo "ENV_API_KEY=$ENV_API_KEY" >> $GITHUB_ENV
    echo "New env API key: $ENV_API_KEY"

2. Running Tests in the New Environment (`run-pdp.yaml`)

For our next step in continuous integration, we would like to let our pipeline test the code against the newly created environment. One key aspect of Permit’s architecture is using a local policy decision point (PDP) that runs together with the application.

In this workflow, we want to run the PDP in the GitHub action. This way, the tests can call it. We’ll also use this step to set up some mock data in the Permit system:

Triggering the Workflow:

This workflow will run whenever a PR is synchronized, ensuring that any updates are tested:

name: demo-run-pdp-and-tests

on:
  pull_request:
    types: [synchronize]

Fetching the Environment ID and API Key:

Next, we’ll fetch the existing environment ID created in the previous workflow:

- name: Fetch environment ID and API key
  run: |
    response=$(curl -s -X GET <https://api.permit.io/v2/projects/$>{{ env.PROJECT_ID }}/envs \\
      -H 'Authorization: Bearer ${{ secrets.PROJECT_API_KEY }}' \\
      -H 'Content-Type: application/json')
    EXISTING_ID=$(echo "$response" | jq -r '.[] | select(.key == "pr-${{ steps.extract_branch.outputs.branch }}") | .id')
    echo "EXISTING_ID=$EXISTING_ID" >> $GITHUB_ENV

Running the Local PDP Instance:

Then, a local instance of the PDP needs to be spun up using Docker, allowing tests to be run against the newly created environment:

- name: local PDP running
  run: docker run -d -p 7766:7000 --env PDP_API_KEY=${{ env.ENV_API_KEY }} --env PDP_DEBUG=true permitio/pdp-v2:latest

Executing the Tests:

Finally, we can execute tests against the local PDP instance using the environment’s API key:

- name: Run tests
  run: PERMIT_TOKEN=${{ env.ENV_API_KEY }} PDP_URL=localhost:7766 npm run test

3. Merging Changes and Cleanup (`merging.yaml`)

The last step of our custom GitHub Action is to ensure an efficient and streamlined deployment and delivery process. This is where we will trigger the merge workflow, which will ensure we are safely integrating the created environment into our production environment in Permit.

Triggering the Workflow:

This workflow is triggered when a PR is closed, signaling that it’s time to merge and clean up:

name: demo-merging
on:
  pull_request:
    types: [closed]

Fetching Production and PR Environment IDs:

Next, fetch the IDs of the production environment and the PR-specific environment:

- name: Fetch production and PR environment IDs
  run: |
    response=$(curl -s -X GET <https://api.permit.io/v2/projects/$>{{ env.PROJECT_ID }}/envs \\
      -H 'Authorization: Bearer ${{ secrets.PROJECT_API_KEY }}' \\
      -H 'Content-Type: application/json')
    PROD_ID=$(echo "$response" | jq -r '.[] | select(.key == "production") | .id')
    echo "PROD_ID=$PROD_ID" >> $GITHUB_ENV

Merging and Deleting the PR Environment:

Finally, merge the PR-specific environment into production and then delete the PR environment, ensuring no residual environments remain:

- name: Merge and delete PR environment
  run: |
    curl -X POST <https://api.permit.io/v2/projects/$>{{ env.PROJECT_ID }}/envs/${{ env.EXISTING_ID }}/copy \\
      -H 'Authorization: Bearer ${{ secrets.PROJECT_API_KEY }}' \\
      -H 'Content-Type: application/json' \\
      -d '{
        "target_env": {
            "existing": "${{ env.PROD_ID }}"
        }
    }'

    curl -X DELETE \\
      <https://api.permit.io/v2/projects/$>{{ env.PROJECT_ID }}/envs/${{ env.EXISTING_ID }} \\
      -H 'Authorization: Bearer ${{ secrets.PROJECT_API_KEY }}'

Our Custom GitHub Action

Looking at the three steps we just created, we can easily see how this action is streamlined the whole process of our authorization service into our users’ architecture. Here's how we tackled them using our custom GitHub Actions:

Environment Creation: The process of creating new environments for every pull request (PR) was automated through the new-env.yaml workflow. This action triggers when a relevant PR is opened or updated, automating the creation of a new environment in Permit. By using Permit’s API, we replicate production settings in the new environment, ensuring consistency across the different stages. A condition was also added to avoid unnecessary environment creation for PRs unrelated to permission changes, using a label system to filter relevant PRs.
Environment Testing: The run-pdp.yaml workflow addresses the need to run tests on the newly created environment. Once a new environment is set up, the workflow spins up a local Policy Decision Point (PDP) instance via Docker. This allows integration and product tests to run against the environment, ensuring that permission settings are accurate before merging changes into production. This automated testing prevents errors and guarantees that only well-tested changes move forward.
Merging and Cleanup: After a PR is approved and closed, the merging.yaml workflow merges the PR-specific environment into the production environment, streamlining the deployment process. Following the merge, the workflow deletes the PR-specific environment, ensuring that no unnecessary environments linger, thereby reducing clutter and maintaining a clean development setup.

By automating these steps—environment creation, testing, merging, and cleanup—we significantly reduced manual intervention, minimized errors, and sped up the entire CI/CD process.

Conclusion

By integrating GitHub Actions with Permit.io APIs, we were able to streamline our CI/CD process and make our environment model accessible and efficient for development teams. This approach not only reduced manual effort but also minimized the risk of errors, providing a smoother and more reliable deployment process.

For any team looking to optimize their CI/CD pipeline, Permit.io’s flexible environment model combined with GitHub Actions offers a powerful solution to automate and secure your development workflows.

You can read more in our docs about how we handle Projects & Environments, or try out Permit.io for yourself!

If you have any questions, join our Slack community, where there are thousands of devs building and implementing authorization.

7 Developer Tools to Prepare Your Stack for the GenAI Era

Gabriel L. Manor — Wed, 24 Jul 2024 13:01:54 +0000

GenAI has completely changed the face of software development, and integrating it into your application is becoming essential rather than optional. Integrating GenAI into your application is not an easy task, but there are some powerful tools that can make the integration of GenAI features into your application easier and, even more importantly, more secure.

Instead of focusing on the usual AI tools like OpenAI or Cloud APIs, we'll look at traditional developer tools that make adopting GenAI into your application a seamless experience.

Here are seven powerful developer tools that can streamline the integration of GenAI features into your applications, ensuring they remain secure, efficient, and competitive:

Before we dive into the list - Permit.io just launched a new feature on ProductHunt. It’s a set of embeddable access-sharing components for your application. I’d appreciate if you could support it by giving us an upvote or comment ❤️

Permit Share-If - Embeddable access sharing components | Product Hunt

“Permit Share-If” is a suite of prebuilt, embeddable UI components that make access sharing in applications a breeze. Designed to provide fully functional access control, they make delegating permission management to your users simple and safe.

producthunt.com

1. Arcjet

One of the most challenging aspects of integrating GenAI is managing non-human identities. Traditional methods to block bots, such as using Cloudflare or firewalls, are becoming less and less effective. Arcjet’s advanced security tools are specifically designed to handle this issue. Their bot prevention system ranks bots based on quality, behavior, and availability, allowing for smarter, more nuanced protection.

This allows you to create a smart layer of security that differentiates between harmful bots and GenAI agents that need access to your application - an approach that ensures malicious bots are blocked, and GenAI can access necessary public data to perform its functions.

Additionally, Arcjet’s tools are designed to integrate seamlessly into your existing security infrastructure, making them easier to implement without significant system overhauls.

2. GitButler

With AI agents like GitHub Copilot, we can develop applications faster and experiment more with our code. GitButler, developed by one of GitHub's co-founders, is a new Git client designed to increase development velocity. It offers features like virtual branches and auto-commit messages, making local experimentation with your code and data more efficient.

Using GitButler as your Git client enhances your development process by leveraging AI agents. It simplifies the management of your codebase, allowing for quicker iterations and more productive coding sessions. This efficiency is particularly beneficial when integrating GenAI, as it allows for rapid prototyping and testing.

Additionally, GitButler’s features support a smoother workflow, enabling you to take full advantage of AI agents in your development environment. This tool helps you streamline your coding process, making it easier to incorporate GenAI capabilities into your applications.

3. DataStax AstraDB and Langflow

Integrating your existing data with large language models and AI agents is essential to truly enable GenAI in your application. DataStax AstraDB, combined with Langflow, actually makes this possible. DataStax’s vector database, based on Apache Cassandra, allows for efficient storage and retrieval of vector data - crucial for AI applications.

Langflow, a recent acquisition by DataStax, enhances this offering with a low-code UI, making it easy to build GenAI applications. This tool simplifies the process of connecting your data with AI models, enabling even those with limited AI expertise to create sophisticated AI-driven features.

The combination of AstraDB and Langflow ensures that your application can leverage GenAI to provide advanced user experiences, such as answering user queries with AI-driven responses or offering personalized recommendations.

4. Lunar.dev

The implementation of GenAI comes with a surge of API calls for GenAI services, like those to OpenAI. This requires a new layer in our applications. Traditionally, API gateways have focused on inbound calls, but with GenAI, managing outbound calls efficiently is equally important. Lunar.dev introduces the concept of an egress API Gateway, or AI Gateway, to handle this new requirement.

Lunar.dev acts as an intermediary for outbound API calls, streamlining permissions, limiting calls, and caching responses. This ensures that your GenAI integration is efficient and cost-effective, preventing unnecessary expenditure on excessive API calls.

Furthermore, by using Lunar.dev, you can ensure that your API usage remains controlled and efficient. This tool provides a way to manage the increased API traffic that comes with integrating GenAI, making it an essential part of a modern developer’s toolkit.

5. Fern

Creating GenAI applications requires state-of-the-art documentation. Writing comprehensive API documentation can be challenging, but it is crucial for enabling users to create programmatic applications based on your APIs. Fern offers an innovative solution to this problem with a CLI tool that helps you generate thorough documentation.

Fern’s approach to API documentation helps users understand what they can do with your application, enhancing the integration of GenAI features. By providing clear and detailed documentation, Fern ensures that developers can fully utilize your APIs, enabling better GenAI integration.

6. Permit.io

As our applications grow, it’s crucial to decide what users—both human and GenAI—can access once they log-in. Traditional role-based access control often falls short, especially as GenAI introduces numerous bots and unpredictable amount of unstructured data into the system.

Permit.io offers a comprehensive solution for fine-grained authorization, allowing you to set precise access controls based on various conditions and relationships between data.

Permit.io provides a simple SDK that makes enforcing these fine-grained models straightforward. With just a small check function, you can determine what a user can or cannot do at any given moment. This capability is crucial in a world where not only humans but also AI agents interact with your application, ensuring secure and efficient access management.

It also supports multiple access control models, including Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), and Relationship-Based Access Control (ReBAC). This flexibility ensures that your application can adapt to various access control requirements, making it a vital tool for integrating GenAI securely into your application.

7. Neon

PostgreSQL with vector support is an excellent way to use vector databases in your application infrastructure. Neon provides a robust infrastructure for PostgreSQL, offering features like versioning, branching, and autoscaling. This enables faster investigation and research on integrating your applications and data with GenAI agents.

Neon’s seamless integration with PostgreSQL ensures that your application can leverage vector databases to provide advanced AI-driven features. By supporting vector data, Neon makes it easier to use GenAI to deliver accurate and relevant responses to user queries.

Their features simplify database management, allowing for efficient scaling and maintenance. This makes it a valuable tool for developers looking to integrate GenAI and provides a solid foundation for building sophisticated AI-driven experiences.

Conclusion

By leveraging these seven tools, you can integrate GenAI features into your applications with enhanced security and efficiency. These tools are designed to simplify the complex process of GenAI integration, ensuring that your applications not only keep up with the latest advancements but also provide a superior user experience. As GenAI continues to evolve, staying ahead with these essential tools will ensure your applications remain at the forefront of innovation and user satisfaction.

Announcing “Permit Share-If" Embeddable Access Sharing Components

Gabriel L. Manor — Tue, 23 Jul 2024 15:49:19 +0000

Never Build Access-Sharing Again

You've seen access-sharing components a million times before. From requesting to edit a document or view a widget in a dashboard to submitting a wire transfer for approval, they’re a must-have feature in almost any modern application.

Every time you’ve seen this feature, it’s taken an enormous amount of development work to build and maintain over time.

We kept seeing our customers building these experiences over and over on top of our API, and we decided, as our CEO Or Weis put it, “It was about time someone brought some order to this part of town”.

Permit Share-If - Embeddable Access Sharing Components | Product Hunt

“Permit Share-If” is a suite of prebuilt, embeddable UI components that make access sharing in applications a breeze. Designed to provide fully functional access control, they make delegating permission management to your users simple and safe.

producthunt.com

What is Permit Share-If?

"Permit Share-If" is a suite of prebuilt, embeddable UI components designed to streamline access sharing in applications. These components provide fully functional access control, making it easy and safe for users to manage permissions.

With just a few clicks, Permit Share-If enables application developers to create and embed custom interfaces such as user management, audit logs, access requests, operation approval flows, and more.

A Holistic Solution to Fine-Grained Authorization

With the ever-rising importance of security and privacy, secure collaboration through access-sharing is a must-have feature in almost any modern application. Despite how common this problem is, access-sharing features can be very hard to build and maintain.

These solutions must provide a good experience for end-users (Granting them access to what they need while maintaining the principle of least privilege) and a good access review experience to our users and developers so they don’t end up skipping fine-grained authorization entirely (by giving everyone Super-Admin permissions).

That was why we created Share-If - a solution that enables developers to implement secure collaboration features into their applications, maintain the principle of least privilege, provide a good access review experience, bring Fine-Grained Authorization to their applications, and maintain scalability and observability—all with zero development time.

Share-If Features:

The new Permit Share-If set of components includes:

Access Request:

Allow users to request restricted resource access directly from your application (just like the Share functionality in Google Drive / Dropbox). Requests are sent to designated users for approval or denial, simplifying access management.

Operation Approval:

Users can submit approval requests via an embedded component, allowing admins to oversee and control specific actions, such as wire transfers from joint accounts. While Access Requests are intended to provide long-term access to a resource, Operation Approvals allow managing requests to perform a singular action.

Approval Management:

Allow users to approve/deny operation requests through a friendly UI. A single embedded component where designated users can handle operation approvals efficiently, maintaining strict control over access review functions.

All Permit Share-If elements also include meta authorization features - allowing your users to decide which of their users can request and approve access and operations - all with proper limitations and within safe interface boundaries.

Secure, App-Level Collaboration in the AI Era

With the ever-rising importance of security and privacy, secure collaboration through access-sharing is a must-have feature in almost any modern application. This is especially true with the rise of GenAI integrations and non-human identities in our applications - they require a solution that ensures proactive access control management by our users.

That’s where Permit Share-If comes in. Being the latest addition to the Permit-Element suite of embeddable UI components, it is designed to provide fully functional access control to both your developers and end-users.

Supporting embeddable components such as User Management and fully-fledged Authorization Audit Logs, and with a strong focus on user experience, they allow you to achieve true fine-grained authorization without the hassle of developing it in-house.

Can’t Wait to See What You’ll Build!

Permit Share-If represents a significant advancement in simplifying access-sharing and authorization for application developers. By integrating these prebuilt, embeddable components, developers can ensure secure, efficient, and user-friendly access management without the extensive development time typically required. Permit Share-If not only streamlines the implementation of access controls but also enhances security, maintains the principle of least privilege, and supports seamless collaboration in today's AI-driven applications.

We invite you to try Permit Share-If and see how it can transform the way you manage access and authorization in your applications. Got questions? Join our Slack community, where thousands of devs are building and implementing authorization.

How to Protect Your Application from AI Bots

Gabriel L. Manor — Mon, 08 Jul 2024 16:40:00 +0000

Bots have traditionally been something we try to prevent from entering our applications. There were, of course, always good (or at least useful) bots as well, such as search engines and test automation scripts, but those were always less common compared to malicious ones.

In the past year, since LLMs and GPT have become a major part of our lives, we’ve found ourselves with a whole new set of bots that don’t really fit the categories previously known to us.

These machine identities are welcomed into our applications by users who want to get some help from GenAI, but that doesn’t change the fact that they should be a concern for us as developers who are trying to protect our data and users.

These new entities can be harmful from many security and privacy perspectives, and we need to know how to handle them.

In this blog, we will evaluate the presence of GenAI identities in our applications and show how to create a smart layer of fine-grained authorization that allows us to integrate bots securely into our applications. To do that, we’ll use two tools: Permit.io and Arcjet, to model and enforce these security rules in our applications.

Rise of The Machines

We’ve always had a very clear distinction between human and machine identities. The methods used to authenticate, authorize, audit, secure, and manage those identities have been very different. In security, for example, we tried to strengthen human identities against human error (i.e. Phishing, Password Theft), while with machine identities, we mostly dealt with misconfiguration problems.

The rise of GenAI usage has brought new types of hybrid identities that potentially can suffer from problems in both worlds. These new hybrid identities consist of machine identities that adopt human attributes and human identities that adopt machine identities.

From the machine side, take Grammarly (or any other grammar AI application) as an example. Grammarly is a piece of software that is supposed to be identified as a machine identity. The problem? It’s installed by the application user without notifying the developers of a new type of machine identity in the system. It gets access to tons of private data and (potentially) can perform actions without letting the developers deal with the usual weaknesses of machine identities.

On the other hand, from the human identity side, GenAI tools give human identities the possibility of adopting machine power without having the “skills” to use it. Even a conventional subreddit like r/prompthacking provides people with prompts that can help them use data in a way that no one estimates a human identity can perform. It's a common practice to have less validation and sanitization on API inputs than in the UI, but if users can access those APIs via bots, they can abuse our trust in the API standard.

These new hybrid identities force us to rethink the way we are handling identity security.

Ranking Over Detecting

One of the questions we need to re-ask when securing our applications for such hybrid identities is ‘ Who is the user?’. Traditionally, that was an authentication-only question. The general authorization question of ‘ What can this user do?’ fully trusts the answer of the authentication phase. With the new hybrid identities that can easily use a non-native method to authenticate, trusting this binary answer from the authentication service can lead to permission flaws. This means we must find a new way to ask the “Who” question on the authorization side.

In order to help the authorization service better answer this detailed "Who" question, we need to find a proper method to rank identities by multiple factors. This ranking system will help us make better decisions instead of using a traditional good/malicious user ranking.

When considering the aspects of building such a ranking system, the first building block is to have a method to rank our type of identity somewhere between machine and human. In this article, we will use Arcjet , an open-source startup that builds application security tools for developers and, more specifically, their ranking system. The following are the different ranks of identities between good and malicious bots, which could help us understand the first aspect of the new Who question.

NOT_ANALYZED - Request analysis failed; might lack sufficient data. Score: 0.
AUTOMATED - Confirmed bot-originated request. Score: 1.
LIKELY_AUTOMATED - Possible bot activity with varying certainty, scored 2-29.
LIKELY_NOT_A_BOT - Likely human-originated request, scored 30-99.
VERIFIED_BOT - Confirmed beneficial bot. Score: 100.

As you can see, each rank level also has a detailed score, so we can detect even more for the levels we want to configure.

Assuming we can rank our user activity in real-time, we will have the first aspect required to answer the question of “Who is the user?” when we make the decision of “What can they do?” Once we have this ranking, we can also add more dimensions to this decision, making it even more sophisticated.

Conditions, Ownership, and Relationships

While the first aspect considers only the user and its behavior, the others will help us understand the sensitivity of the particular operation that a user is trying to perform on a resource. Let’s examine three methods that can help us build a comprehensive policy system for ranking hybrid identity operations.

Conditions : With this method, we use the context of the authorization decisions and the user's bot rank score to build conditions that will help us get better control of these identity operations. For example, if we want to keep ourselves safe from an injection of vulnerable data by applications that were accessed by a human user, we can use the bot's level plus the characters in the request to verify the level of danger.
Ownership : With this method, we add the level of ownership to the decision data to give it another dimension. For example, we can decide that a user can let high-confidence bots modify their own data but not perform changes or read others’ data, while bots with lower ranking do not get access at all.
Relationship : With this method, we can use the relationship between entities to create another trust dimension in the user's rank. For example, if we have a folder owned by a user and files in this folder owned by others, we can let the good bot perform operations on the folder but not the files.

Thinking of our new ranking system as multidimensional ranking can even help us mix and match our ranking systems for a fine-grained answer to the ” What ” question that takes the “ Who ” question into account.

Let’s model such a simple ranking system in the Permit.io fine-grained authorization policy editor.

Modeling a Bot Ranking System

While Permit.io allows you to build a comprehensive multi-dimensional system with all the dimensions we mentioned, for the sake of simplicity in this tutorial, we will build a system based only on conditions and ownership.

For the model, we will use an easily understandable data model of a CMS system, where we have content items with four levels of built-in access: Public, Shared, Private, and Blocked.

Public documents are documents that are owned by the user and shared publicly
Shared documents are documents that are owned by others and shared publicly
Private documents are documents that are owned by the user and marked as private
Blocked documents are documents that are owned by others and marked as private

First, we would like to create segments for potential hybrid identities in our application. We will inherit Arcjet's direct model and configure five user sets that correlate to these five types of bots.

Login to Permit at app.permit.io (and create a workspace if you haven’t)
Go to Policy → Resources and create an Item resource with the following configuration
Now, we want to add a user attribute that allows for smart bot detection. Go to the Directory page click the Settings button on the top-right corner of the page, and choose User Attributes on the sidebar. Add the following attributes
Go back to the Policy screen, and navigate to ABAC Rules. Enable the ABAC options toggle, and click Create New on the User Set table. Create the following four user sets.

If we go back to the Policy screen now, we can see that our different user sets allow us to use the first dimensions of protection on our application.

Let’s now create the ranking on the other dimension with conditions.

Go to ABAC Rules → Create Resource Set and create four resource sets, one per item type
Go back to the Policy screen and ensure the following configuration

As you can easily see, we configured the following rules in the table:

Human users can read Public, Shared, and Private data
Trusted bots are allowed to read Public and Shared data
Untrusted bots can read only the Public
Evil bots (bots that try to hide their automated identity) are blocked for all kinds of data

This configuration actually stretched the “static” question of who to a dynamic multi-dimensional decision. With the policy model in mind, let’s run the project and see the dynamic enforcement in action.

Running a Demo

In the following Node.js project, we utilized a very simple application where we saved three content items, one for every category we defined. From the user perspective, we haven’t implemented authentication but are using a hardcoded authentication token with the user ID on it.

All the code is available here - https://github.com/permitio/fine-grained-bot-protection

To run the project locally in your environment, please follow the steps described in the project’s Readme.md file

Let’s take a short look at the code to understand the basics of our authorization enforcement.

First, we have our endpoint to read documents from our “in-memory” database. This endpoint is fairly simple: It takes a hardcoded list of items, filters it by authorization level, and returns them to the user as plain text.

const ITEMS = [
  { id: 1, name: "Public Item", owner: USER, private: false, },
  { id: 2, name: "Shared Item", owner: OTHER_USER, private: false, },
  { id: 3, name: "Private Item", owner: USER, private: true, },
  { id: 4, name: "Blocked Item", owner: OTHER_USER, private: true, },
];

app.get("/", async (req, res, next) => {
  const items = await authorizeList(req, ITEMS);
  res
    .type("text/plain")
    .send(items.map(({ id, name }) => `${id}: ${name}`).join("\\r\\n"));
});

The authorize function that we are using here enforces permissions in two steps. First, it checks the bot rank of the particular request, and then it calls the check function on Permit with the real-time data of the Arcjet bot rank and the content item ID. With this context, the Permit’s PDP will return the relevant function.

const authorizeList = async (req, list) => {
  // Get the bot detection decision from ArcJet
  const decision = await aj.protect(req);
  const isBot = decision.results.find((r) => r.reason.isBot());
  const {
    reason: { botType = false },
  } = isBot;

  // Check authorization for each item in the list
  // For each user, we will add the botType attribute
  // For each resource, we will add the item attributes
  const authorizationFilter = await permit.bulkCheck(
    list.map((item) => ({
      user: {
        key: USER,
        attributes: {
          botType,
        },
      },
      action: "read",
      resource: {
        type: "Content_Item",
        attributes: {
          ...item,
        },
      },
    }))
  );

  return list.filter((item, index) => authorizationFilter[index]);
};

To test the application, you can use your local endpoint or use our deployed version at: https://fga-bot.up.railway.app/

Visit the application from the browser, you can read Public, Private, and Shared the items
Try to run the following curl call from your terminal. Since this is a bot that does not try to pretend it isn't a bot, it will get the result as a trusted bot.
```
curl <https://fga-bot.up.railway.app/>
```
Now, let's try to run a bot from a cloud-hosted machine that pretends to be human by its user agent. To run the bot, access the following environment and run the code there.
https://replit.com/@gabriel271/Nodejs#index.js
As you can see, this bot will get only the public items

As you can see in this demo, we have a dynamic, context-aware system that ranks our hybrid identity in real-time and returns the relevant permissions as per activity.

Developer Experience and GenAI Security Challenges

Security challenges associated with non-human identities are threats that developers need to handle directly. Traditionally, security teams have been responsible for these concerns, but the complexity and nuances of hybrid identities require a developer-centric approach. Developers who understand the intricacies of their applications are better positioned to implement and manage these security measures effectively.

The only way to ensure our applications’ resilience is to use tools that give the developer an experience that seamlessly integrates into the software developer lifecycle. The tools we used in this article are great examples of how to deliver the highest standards of application security while speaking the language of developers.

With Permit.io, developers (and other stakeholders) can easily modify authorization policies to respond to emerging threats or changing requirements. For instance, we can adjust our rules to prohibit bots from reading shared data. This change can be made seamlessly within the Permit.io dashboard, instantly affecting the authorization logic without altering the application's codebase. All developers have to do is keep a very low footprint of enforcement functions in their applications.

With Arcjet, we are taking the usual work of bot protection, which is traditionally part of the environment setup and external to the code itself, into the application code. Using the Arcjet product-oriented APIs, developers can create a dynamic protection layer without the hassle of maintaining another cycle in the software development lifecycle.

The demo we show demonstrates a better situation where those tools work together without any software setup that is outside the core of product development.

Conclusion

In this article, we explored the evolving landscape of machine identities and the security challenges they present. We discussed the importance of decoupling application decision logic from code to maintain flexibility and adaptability. By leveraging dynamic authorization tools like Permit.io, we can enhance our application's security without compromising on developer experience.

To learn more about your possibilities with Permit’s fine-grained authorization, we invite you to take a deeper tour of the Permit UI and documentation and learn how to achieve fine-grained authorization in your application. We also invite you to visit the Arcjet live demos to experience the other areas where they can provide great application protection with few lines of code.

How to Model Cloud-Native Authorization

Gabriel L. Manor — Mon, 13 May 2024 12:00:00 +0000

Creating and managing an effective authorization system is no easy task. Especially when it comes to doing so effectively across distributed cloud-native applications. Working with people who have been building authorization for a long time, we designed our authorization service, Permit.io, to be cloud native. Throughout this process, we found that there are three crucial key elements to building cloud-native authorization: Proper CI/DC, thorough testing, and precise modeling and implementation of your fine-grained authorization processes.

This blog will cover these three crucial components for building cloud-native authorization, discuss how they allow you to build reliable and scalable fine-grained authorization, and show you how we implemented them in Permit.

What is Cloud Native Authorization?

In simple terms, Cloud Native Authorization refers to building and managing authorization systems that are fully integrated and operational within a cloud environment, leveraging cloud capabilities to enhance flexibility, scalability, and resilience. The key to achieving effective cloud-native authorization lies in focusing on three primary aspects:

Continuous Integration and Deployment (CI/CD), rigorous testing , and accurate modeling of your authorization processes.

CI/CD: Continuous integration and deployment ensure that your authorization system can adapt quickly to software changes and user requirements. This practice helps automate the update and deployment processes, which minimizes the risk of errors and maximizes operational efficiency.
Testing: Thorough testing is crucial to verify that the authorization system works as intended under various scenarios. It involves checking the system's security aspects and functional capabilities to prevent breaches and ensure that policies are enforced correctly.
Modeling Your Implementation: Precise modeling involves outlining and structuring how authorization processes interact within your application. This step is critical because it helps create a clear framework that defines how policies are applied and managed across different application components.

Let’s dive into each of these and see how you can utilize them in your own fine-grained authorization system.

Policy Lifecycle Management Through CI/CD

Enhancing policy management with Continuous Integration and Continuous Deployment (CI/CD) processes allows us to maintain a consistent and secure authorization layer. Managing and merging policies into various environments while ensuring consistency and compliance, syncing them to Git and deployments, and utilizing the power of policy as code allows us to handle authorization swiftly and effectively.

Automated Policy Updates and Deployments

Automating updates and deployments through CI/CD ensures that changes are applied consistently and without human error across all environments. This automation speeds up the deployment process and enhances security by reducing the risk of misconfigurations. At Permit.io, we primarily manage the policy life cycle as part of a CI process by using projects and environments together with the Environment API. By working with Permit environments for CI, CD is automatically achieved using OPAL, as every environment is automatically deployed to PDPs mapped to them (via their API secret key).

Version Control and Consistency with GitOps

Maintaining version control and ensuring consistency across environments is essential when managing complex systems. Using a Git-like model for environments, where each environment corresponds to a branch, helps teams manage development, staging, and production configurations separately yet consistently. This approach allows for editing, reviewing, and merging policies as code within a Git repository, ensuring transparency and collaboration. At Permit.io, we achieve this by allowing you to automatically map branches when you connect your Permit Project to a repository, facilitating efficient lifecycle management and leveraging Git's robust version control system.

Effective Authorization Testing Strategies

Before any policy is deployed to a production environment, it must be thoroughly tested in a controlled setting. Effective testing strategies confirm that the system behaves as expected under various conditions and help catch potential issues before they affect the production environment. Here's how testing should be structured:

Unit Testing

Unit tests are essential for verifying the individual components of your authorization policies. These tests should be designed to run independently from the rest of the system, allowing for quick checks on the logic and functionality of each policy. At Permit.io, unit tests can be executed using policy as code, where the policy code is loaded directly onto the policy engine (such as via the OPA test command line), ensuring that each component functions correctly in isolation.

Application and Integration Testing

Application and integration tests evaluate how well different parts of your application work together under real-world scenarios. This involves deploying a Policy Decision Point (PDP) that is synced to the development environment and running tests that simulate actual application queries against the PDP. This method ensures that policies are not only theoretically correct, but are also effectively enforced within the application context. In Permit.io, we incorporate these tests into our development cycles, allowing for thorough validation of policy implementations in a controlled yet realistic setting.

Automation of Testing Processes

Automation plays a vital role in maintaining efficiency and consistency in testing. Automated tests can be configured to run as part of the CI/CD pipeline, ensuring that every change is vetted before it goes live. We suggest you consider the following triggers and hooks, which you can mix and match according to your needs:

The CI system deploys PDPs specifically for testing policy changes.
Developers can trigger tests automatically through the CI system.
Tests must pass before environments are merged; if tests fail, the CI system will not proceed with merging changes.
The CI system uses APIs like Create/Copy-env to establish environments purely for testing purposes, guaranteeing that each test environment mirrors the target deployment scenario accurately.

Modeling and Implementation

Modeling and implementing a cloud-native fine-grained authorization system requires a structured approach. We suggest separating our implementation into a list of several planes, each focused on a different iteration of the SDLC and architecture levels. These planes—Application, Configuration, Data, and Enforcement—serve different functions, from handling user interactions to managing data security and enforcing policies. Let’s dive in -

The Application Plane

The Application Plane serves as the foundational layer of the authorization layer, designed to align closely with common product architectures, integrating authorization directly into the software development life cycle (SDLC). Here’s how we modeled the key components of this plane in Permit.io:

Workspaces/Organizations : These act as the main namespace or administrative domain within the authorization system, analogous to a development organization in the SDLC. Generally, each account should have one workspace to maintain a clear organizational structure.
Projects : Projects within a workspace mirror products and can be thought of as equivalent to code repositories. Each project holds its unique configuration and policies driven by specific product requirements.
Environments : Similar to branches in a code repository, environments within a project manage the deployment and testing of policies in different stages, such as development or production.
Members : These are the users involved in managing and operating the authorization system, including developers, security engineers, and product managers, who handle permissions and policy configurations.

Flow and User Interaction

In the SDLC timeline, the Application Plane is relatively static but critical as it establishes the policy management and deployment structure. Interaction with the Application Plane is facilitated through various methods:

User Interfaces (UIs): UIs allow non-technical stakeholders, such as product managers, to easily manage and navigate the structure of projects and environments. While costly to create, this type of accessibility is vital for fostering an inclusive environment where project configurations can be adjusted without deep technical knowledge.
GitOps Workflows : GitOps provides a declarative way to manage infrastructure and configurations using Git. It allows for transparent version-controlled environments that align with DevOps practices, making it easier for teams to track changes and roll back if necessary.
APIs : APIs offer developers the flexibility to manage projects and environments programmatically, integrate with existing CI/CD pipelines, and automate repetitive tasks. This is particularly useful for dynamically creating environments that align with feature branches or specific testing needs.

While developing these capabilities in-house can be resource-intensive and complex, our approach at Permit was to provide these capabilities out of the box, ensuring that developers can choose the most suitable method for their needs without the overhead of building and maintaining these systems.

The Configuration Plane

The Configuration Plane is central to defining and managing the rules and policies that govern access within an application. This plane is essentially about translating the complex requirements of permissions and roles into a structured, stateless configuration that integrates seamlessly with the application's codebase. Let’s go over this plane’s components:

Resources:
These are the various types of application assets requiring permission management. Each resource type specifies possible actions that users might undertake.
- Resource Relationships: Descriptions of potential connections between resources to facilitate permission derivation.
Roles:
User roles within the application, both at the system and resource levels.
- Role Derivations: Mechanisms to extend permissions from one role to another by using relationships.
Attributes: These are specifications that define the characteristics of resources and users, which can be used to set conditions for access permissions.
Condition sets - the ability to build conditions to match users or resources in a set. These conditions use the attribute configuration to configure match conditions.
Policy: These are the actual rules that determine whether access is allowed or denied based on roles, resources, and condition sets.
Custom Policies: Advanced policy declarations using specific policy languages (like Rego or Cedar). Used mostly in very advanced use cases.
Data Fetchers: These synchronize data from the application to the authorization system, crucial for maintaining current and applicable permission settings.
URL Mapping: This feature links API endpoints directly to resource definitions, streamlining the integration of authorization layers with application APIs.

Flow and User Interaction

Managing the Configuration Plane can be approached through multiple methods, each offering distinct advantages and catering to different organizational needs:

UI : Ideal for non-developer stakeholders such as product managers who need to configure permissions easily and visually. This method enhances accessibility and reduces complexity for users without deep technical knowledge.
Infrastructure as Code : Organizations committed to a code-centric SDLC can manage permissions via tools like the Permit Terraform provider, integrating permission management directly into their development processes.
Raw Policy as Code : For scenarios where customization needs exceed what is feasible through the UI, policies can be directly authored and managed in policy code files within version control systems.

As with the application plane, at Permit.io, we tried to enable developers to adopt the method that best fits their workflow. We support a hybrid approach, recommending the use of the UI for standard role-based and attribute-based access control configurations while accommodating more complex or stringent rules through custom policy code.

The Data Plane

As the configuration plane defines the application's authorization layer from the product requirement perspective, the data plane handles the dynamic elements of application data that influence policy decisions. It bridges the static configurations set in the Configuration Plane and the real-time enforcement of those policies in the Enforcement Plane. Let’s go over its components:

Users : The core element of the Data Plane, representing individuals who interact with the application. User data is often synchronized from identity providers that manage authentication.
Attributes : Attributes associated with users can be pivotal in determining the outcome of policy decisions and influencing access control based on dynamic user data.
Tenants : Representing groups of users, tenants facilitate segmented policy enforcement, similar to organizational units in traditional IAM systems or accounts in cloud-native architectures.
Role Assignments : These define the relationships between users and their roles within the application and can extend to relationships between users and specific resource instances.
Resource Instances : These are specific instances of resources defined in the Configuration Plane, typically identified by unique identifiers.
Relationship Tuples : These tuples create a graph of relationships between individual instances, aiding in the derivation of permissions between users and resources.

Flow and User Interaction

The management and synchronization of data within the Data Plane are continuous processes, tightly integrated with the application's lifecycle. Data can be handled in various ways:

API/SDK : The most straightforward method for syncing data is through the integration of SDKs or direct API calls from within the application code. This approach ensures that data remains consistent with the application's state and development cycle.
UI : Data can also be managed via a user interface, which is especially useful for non-developer stakeholders who need to interact with the data for configuration or testing purposes. However, direct manipulations in the UI should be used judiciously in production environments to maintain data integrity.
Policy Engine APIs : For advanced data synchronization scenarios, data fetchers or direct policy engine API calls can be used. These are particularly useful in large-scale environments where data needs to be consistently and automatically updated.

P ermit.io supports API/SDK integrations and provides UI capabilities that allow for easy data manipulation and testing. For environments where data synchronization needs to be automated and consistent, we utilize its OPAL to link data directly with the policy engines, maintaining a single source of truth and enhancing the reliability of policy enforcement.

The Enforcement Plane

The Enforcement Plane is where all the preparatory work done in the other planes comes into action. It is the most dynamic aspect of a cloud-native authorization system, responsible for the real-time application of configured policies. This plane ensures that the authorization decisions, such as allowing or denying user actions, are enforced consistently and accurately across the application. Let’s go over how its components are modeled in Permit:

Check Function(
permit.check()
):
This is the core component of the Enforcement Plane in Permit. It evaluates whether a particular action by a user on a resource should be allowed or denied based on the policies. The function considers several elements to make this decision:
- User : Includes the user ID and, optionally, user attributes.
- Action : Specifies the operation the user is attempting.
- Resource : Identifies the type or ID of the resource involved and, optionally, resource attributes.
- Context : Any additional data that might be relevant for evaluating the policy decision.
Data Filtering : This function assists in filtering data according to the policy evaluation. It is particularly useful in applications where data visibility depends on user permissions, although it typically requires custom policy code to implement.
Local PDP APIs : These APIs fetch necessary data from the local policy decision point to aid the application in making informed authorization decisions.

Flow and Integration

The enforcement logic is embedded within the application code in the software development life cycle. It acts as the gatekeeper, controlling what users can or cannot do within the application based on the policies defined in earlier planes.

At Permit.io, enforcement is integrated using SDKs or by direct calls to the policy decision point. This integration allows developers to directly incorporate permission checks and data filtering mechanisms into the application flow.

Conclusion

Crafting an effective cloud-native authorization system is a complex yet crucial task. Through our experience dealing with cloud-native authorization in Permit.io and based on the way we modeled our own system, we have dissected the processes that contribute to building a strong authorization framework that is scalable, flexible, and secure.

The integration of continuous integration and deployment (CI/CD), meticulous testing, and precise modeling are a must when it comes to developing an authorization system that not only meets the current demands but is also prepared for future challenges. Each component—from the Application Plane through to the Enforcement Plane—plays a vital role in ensuring that the system operates seamlessly and adheres to strict security standards.

Whether you are a developer, a security engineer, or a product manager, understanding and implementing these facets will empower you to build and maintain a strong system.

45 Questions to Ask Yourself Before Modeling Authorization

Gabriel L. Manor — Thu, 09 May 2024 13:00:00 +0000

Authorization is part of every modern application, ensuring users can only access the resources they are permitted to. While this might sound rather straightforward, considering how complex modern applications are, ensuring the right people get the right access to the right places is far from easy.

Before you start building, whether you are planning to build your own solution from scratch or use an existing authorization as a service solution, there are some crucial questions you must ask yourself when planning your implementation.

We see these questions being asked repeatedly on Reddit, StackOverflow, and in our own community dedicated to helping people build authorization systems. In order to make sure you have everything covered, we gathered them together in one place.

It doesn't matter whether you're upgrading an existing authorization system (From monolith to microservices-based, for example) or creating an authorization for a new application from scratch - these are the most critical questions you should ask yourself before modeling your authorization implementation.

1. Scope and Granularity (RBAC, ABAC, ReBAC):

What types of resources do you need to secure in your application (e.g., data, functions, services, APIs)?
Do your applications utilize resource hierarchies, organizational hierarchies, or ownership models? Are you able to easily model those (recursively) into your policies?

If you have an existing implementation -

How granular are the current permissions? Do you support role, attribute, or context-based access control?
Does your authorization layer support multi-tenancy as a first-class citizen?

The first step in designing an authorization layer is determining the resources to which you need to manage access. Each type of resource and its place in the overall structure of your application might require you to utilize a different type of authorization model (RBAC, ABAC, ReBAC, or a combination of them).

It is important that you familiarize yourself with the available policy models out there, their pros and cons, and try to assess which ones are the best fit for your application.

2. Policy Authoring: Involving Other Stakeholders

Are non-technical stakeholders (e.g. Product, Security, Compliance, Sales, Support) able to participate in policy authoring? Should they? If so, to what extent?
Are end-customers able to customize their policies within your system (e.g. dynamically create roles, assign permissions, define hierarchies)?
Are you able to utilize policy as code as part of your authorization layer?
Are you able to utilize Infrastructure as code to define these policies?
How quickly can you deliver new policies to production? Seconds? Hours?

Authorization policies should be flexible and accessible while remaining secure. It is common for various stakeholders (Product, Security, Compliance, Sales, Support etc.) to require a certain level of access to your authorization layer, being able to author and edit policies, and having these policies take immediate effect in the system.

Facilitating this need can’t come as an afterthought to building your authorization layer, and should be considered from day one. Utilizing Policy-as-code for this endeavor facilitates automation and integration into CI/CD pipelines, enabling faster deployment and iteration of policies while keeping all the best practices of code deployment in place.

The Permit.io UI allows you to define policy via a UI that generates policy as code for you in your language of choice.

3. User and Data Management:

How do you manage the synchronization of user identities and attributes across systems?
Can you consume external data sources to aid in the authorization decision process without creating dependencies (To systems that aren’t highly available, highly performant / low latency)?
What mechanisms manage user roles and hierarchies?
Is there a method of loading dynamic data (e.g. geo-location, quotes, billing) into the authorization system in place?

Effective user and data management ensures the authorization system is both accurate and responsive. Handling dynamic data efficiently can enhance the system's adaptability and responsiveness to real-time changes.

This can be achieved by using tools like Open Policy Administration Layer (OPAL), which helps keep your authorization layer updated in real-time with data and policy updates. This OSS includes two important features:

OPAL allows tracking a specific policy repository (like GitHub, GitLab, or Bitbucket) for updates. It does this by either using a webhook or checking for changes every few seconds. This makes the system act as a Policy Administration Point (PAP), which sends the policy changes to your policy engine, ensuring it is always up to date.
The ability to track any relevant data source (API, Database, external service) for updates via a REST API, and fetch up-to-date data back into your policy engine. Using these capabilities allows you to take advantage of the full benefits of policy languages by keeping your policy engines up to date with all the relevant policies and data in real-time.

4. Policy Management:

How are authorization policies managed and defined within your system?
Can policies react dynamically to contextual changes at runtime?
Is there a single source of truth for your policies?
How are policies tested, reviewed, and benchmarked? Can this be done as part of their authoring process?
Are you able to unify policies across different surfaces (gateways, proxies, middleware, code, DBs)?

A centralized management system helps maintain consistency and integrity of policies across all platforms. Dynamic policies that adapt to real-time data ensure that access control is always relevant and secure. Centralization of your policy decisions can be achieved by using Policy Engines such as Open Policy Agent vs AWS Cedar. It is important to choose the policy engine and policy language that best suits your needs.

5. Auditing and Compliance: Tracking and Simplification

How do you track and log access decisions?
Can you aggregate and search audit logs effectively?
Are you able to track decision paths for audit logs?
Is your audit log aggregation retaining logs in a way that matches your policy requirements?
Does your system simplify compliance with standards like HIPAA, GDPR, and PCI?
Are there tools in place to analyze access patterns and detect anomalies on top of audit logs?

Quality logging and auditing capabilities are essential for compliance and security. They help track access patterns and detect anomalies, ensuring that your application meets regulatory standards and effectively manages risk.

6. Integration and Scalability: Preparing for Growth

How does your authorization system integrate with other infrastructure components?
Is the system scalable to meet the growth of your application?
What is the impact of changing your policy model (RBAC to ABAC, for example) on your engineering resources?
Do you practice decoupling of policy and code?

A well-integrated system reduces maintenance overhead and avoids bottlenecks as your application scales. Consider the long-term impact of potential system changes to ensure sustainability.

7. Performance and Reliability: Ensuring High Availability

What impact does the authorization system have on application performance?
What percentage of this impact is due to latency to the authorization service or dependent data sources?
How do you ensure the service’s reliability and availability?
Is the information stored in your JWTs limited to identity-bound data points?

Minimizing latency and maximizing reliability are critical for maintaining user satisfaction and trust. Efficient performance management ensures that security measures do not impede the application’s responsiveness.

8. Security and Risk Management: Safeguarding Access

What security measures protect your authorization data?
How do you manage breach detection and response to unauthorized access?
Are there access controls and logs for changes to access management?
Do you have audit logs on who can change your access control?
Is the lifespan of your JWTs less than a minute? Or at least less than 10 minutes?

Having an authorization layer that monitors access to the app’s authorization layer is crucial. It prevents unauthorized changes from being made to the authorization layer and ensures that any potential breaches are quickly identified and addressed.

9. Technology and Tooling: Leveraging the Best Tools

What external libraries, frameworks, or services are you using for authorization?
What are the current tools and solutions for authentication? Are you able to leverage all your authentication and identity claims in your authorization layer with ease? Are you easily able to support attributes coming from external identity providers?
What are the limitations of your current tooling?

Choosing the right technology stack for authorization and authentication can greatly affect both the system's effectiveness and the developer's ease of implementation. Understanding the limitations of current tools can guide future improvements and integrations.

10. Future-Proofing: Staying Ahead with Continuous Improvement

How do you ensure your authorization system remains up-to-date with the latest security practices?
Are you able to quickly adapt your authorization strategies to accommodate new technologies and changing regulatory requirements?
What processes do you have in place for continuous assessment and improvement of your authorization system?

The IAM landscape, as well as the potential security risks involved are constantly changing. This means we must keep our system current and adaptable. Implementing a process for ongoing assessment and improvement can help address emerging security challenges and incorporate advancements in technology. Regular updates, guided by the latest security research and compliance demands, ensure that your system not only meets current standards but is also prepared for future requirements. This approach reduces vulnerabilities and ensures that your authorization system evolves in step with both technological innovations and changes in the regulatory environment.

Conclusion

Building and managing an effective authorization system requires a thoughtful approach that balances security, usability, and performance. By considering these detailed questions, you can ensure your authorization system is strong, compliant, and ready for the challenges of modern application development.

OPA, Cedar, OpenFGA: Why are Policy Languages Trending Right Now?

Gabriel L. Manor — Thu, 02 May 2024 18:00:00 +0000

You might have noticed a rising trend lately - Policy languages like OPA, Cedar, and OpenFGA are being increasingly used in Identity and Access Management (IAM) to manage complex authorization requirements. Join us as we explore the challenges faced in authorization, the solutions provided by policy languages, and the benefits of using them.

Policy Languages are on the Rise

Domain-specific declarative languages have been a huge part of software development since its early days. They were created to tackle the complexities and requirements general-purpose programming languages struggled to manage and are now a part of every developer's toolkit.

In Identity and Access Management (IAM), authorization is becoming increasingly challenging in recent years - apps are getting more complex, as are user requirements. The result? a huge surge in domain-specific declarative languages focused on authorization. Older languages, such as Open Policy Agent’s Rego, are getting a facelift with their upcoming V1, and new languages and platforms like OpenFGA and, more recently, AWS’ Cedar, are being created.

It’s quite clear that significant steps are being made to tackle authorization’s ever-growing complexity. In this blog, we’ll talk about why these policy languages are rising in popularity, and how you can use them to your advantage to build better, more secure applications.

The Challenge of Fine-Grained Decisions

There’s a new problem in the software development world: the problem of decisions. Decisions are obviously not a new issue - it’s one of the most basic aspects of software development, and simple ‘if’ statements are at the very foundation of any programming language out there. But in the vast majority of cases, that’s not enough.

Many modern applications require extremely fine-grained decisions to be made, especially regarding security matters in authorization (handling what a user or service can or cannot do in your application). Let’s briefly go over these challenges:

Application Architecture

Working as a developer back in 2010, you could easily imagine having one server, one programming language, one database, and one application. Today, even the most basic apps start tons of services from the get-go, yet we still don’t want users to access data that they're not supposed to. This means all of these services need to have one concrete source of truth for their decision-making, and these decisions have to be streamlined across the entire stack.

Data Points and Decision Fatigue

In LAMP or older architectures, we used to have one SQL database. Even the simplest apps today use multiple data sources, which are only growing more complex by the minute. All of this data still needs to adhere to the same level of security when in comes to making decisions. That means the way of making these decisions is also growing increasingly complex.

The more data we have, the more decisions we need to make, and the more data needs to be included in that decision-making process. At some point, it gets too complex, and we can’t keep supporting more and more granularity.

Velocity and Frameworks

We’re delivering more software. That means more endpoints and more production environments that just keep growing. This creates the need for a layer we can trust to always make the right decision when it comes to access.

Confidence - Not Just End-Users Anymore

Users of modern-day applications are significantly more security aware. They want to own their data and manage its privacy, and you need to support that. That means supporting very fine-grained ownership, temporary data access functions, location-based access policies; you name it. On the other hand, app users are not really users in the classic sense anymore. Think DevOps, RevOps, and AppSec - they all want access to the code, and they affect the way that software should be delivered. Above all else, they affect how access decisions should be made.

And all of that complexity doesn't include the newest player on the block - AI Agents and LLMs. These create a problem of unstructured decisions, as they want unstructured access to our data - how do we provide them with the right access

This long list of challenges requires more complex solutions than what can be achieved with ‘if’ statements hard coded into your application. That’s where policy engines and policy languages come in.

The solution? Structure and Domain-Specific Declarative Code

Now that wev’e gained a better understanding of the problem, - let’s talk solutions.

The first step to solving this challenge is understanding where all these complex decisions should be made. This can be achieved by mapping out our application into a few authorization layers:

The most basic layer is the code itself. Developers today have a lot of effect on how code is delivered and what production looks like. So the first decision that needs to be made is, basically put, “What can the developer do?”
Then there are the services. Here there are the questions of “Which service can talk to other services?”, “How are they deployed in the CI/CD and speak with each other”?
Above that is the application database. Here, we need to make the decision of “Who can read what from the database?”
On top of that, there’s the application backend, where we need to decide “What actions can application users perform?”
On top of everything else, we have the frontend, where we need to ask ourselves, “What can our application users see?”

With a clear structure of where authorization decisions should be made, it’s easier for us to design a solution that can actually handle them. To do that, we can use two important architectural principles:

Centralized Policy Configuration: consolidating all our configuration in one place will help us streamline it and ensure that we're following all the standards we're trying to establish.
Policy Engines: The Policy Engine is in charge of evaluating authorization queries, using the policy rules as a source of truth. Authorization policies are written in Policy Languages, which the policy engine interprets, providing a decision to any authorization query it is presented with. Having a piece of software that knows how to take the policies we configure and make the right decisions is a must.

This plane needs to be decentralized for several reasons: First, it has to react super fast, and second, we want every part of our stack to be able to communicate with this plane directly and enforce permissions based on these decisions.

Now that we've identified the need for using a decentralized authorization engine let’s dive deeper into the language these engines utilize to process and handle authorization queries - Policy Languages.

What are Policy Languages?

A policy language is a formal and structured way of defining rules, conditions, and logic for specifying policies. It provides a standardized syntax and semantics for expressing authorization rules and access control requirements, making it easier to manage and enforce security policies. There are many different policy languages, such as OPA’s Rego, AWS’ Cedar, OSO’s Polar, and more.

The Benefit of Using Policy Languages

The benefits of using Domain-Specific Declarative languages can help us overcome these challenges thanks to the benefits of having policy as code -

They are readable. When you look at policy as code written in languages intended for authorization policies, you should immediately understand what is happening - who can do what, on what, and when.
They improve performance. As all decisions are made in a single domain, nothing is in their way of being made and delivered with no latency.

Not only that - defining policies using code provides you with the ability to ensure policies are consistently enforced across different systems and environments, which can help prevent policy violations and reduce the risk of unauthorized access. It allows you to easily manage and update policies, as you do that with the same tools and processes used to manage and deploy software. This makes it easier to track changes to policies over time, roll back changes if necessary, and in general, enjoy the well-thought-through best practices of the code world (e.g., GitOps).

What Policy Languages are there?

There are many policy languages available to choose from, each more fit to handle different scenarios:

Open Policy Agent (OPA) - Rego

allow {
    input.user.role == "viewer"
    validate_department(input.user, input.document)
    validate_classification(input.user.role, input.document.classification)
    validate_dynamic_rules(input.user, input.document)
 }
 validate_department(user, document) {
    user.department == document.department
 }
 validate_classification(user_role, doc_classification) {
    role_permissions[user_role][_] == doc_classification
 }
 validate_dynamic_rules(user, document) {
    dynamic_rules[_](user, document)
 }

OPA started out as a multi-purpose policy engine, and that’s where its power comes from. It’s an extremely flexible language that can help you model any type of decision you want. The thing is, Rego can get quite complicated - it's not the perfect example of a declarative language being simple and intuitive, but it does provide you with the ability to handle extremely complex decisions on any layer.

If you have the ability to learn this new language, and you want to have one agent with one policy language across the stack, Open Policy Agent is a great choice.

Read more about it here: RBAC with Open Policy Agent (OPA)

AWS’ Cedar

permit (
    principal == PhotoApp::User::"stacey",
    action == PhotoApp::Action::"viewPhoto",
    resource
 )
 when { resource in PhotoApp::Account::"stacey" };

Launched by AWS just one year ago, Cedar’s started as a language dedicated language for application-level authorization. Unlike AWS IAM, it's a language that can be used in any application. Cedar uses the Dafny language to provide scientific proof of correctness and performance, yet it is still challenging to use it when dealing with unstructured data, and it lacks ReBAC support. It’s a great option to use for fast ABAC based decisions, with auditing, static analysis, and partial evaluation supported out of the box.

Read more about it here: RBAC With AWS’ Cedar

OpenFGA

Not a policy language per-se, but more of an authorization platform based on Google’s Zanzibar white paper, OpenFGA is a great choice when it comes to handling ReBAC. Backed and maintained by Auth0 and used by them for authorization, with a graph-based engine built-in, it is the perfect solution for large-scale authorization implementations. OpenFGA is less suitable when it comes to RBAC and ABAC.

You can learn more about how it compares with Cedar here: OpenFGA

A broader overview and comparison of all three languages can be found here: How Open Policy Agent compares to AWS Cedar and Google Zanzibar

What do Policy Engines Lack?

While policy languages and engines provide us with a great basis for creating a separate microservice for authorization, both OPA and Cedar lack several key abilities. Let’s look at an example -

Say our policy requires a user to be a subscriber to see parts of our site. To make a policy decision, we need to know the user’s subscription status from our billing service (e.g. PayPal or Stripe) and be immediately aware of any changes to it : a new subscriber expects immediate access to our site, and a churned user should lose access on the spot.

That means our policy engine needs to be updated in real time, from outside data sources , while all of our decentralized policy engines are in sync with each other.

Open Policy Administration Layer (OPAL) is an OSS project created to aid with Policy Engine management, which keeps them updated in real-time with data and policy updates. Supporting both OPA and AWS’ Cedar, OPAL offers two important features:\

OPAL allows tracking a specific policy repository (like GitHub, GitLab, or Bitbucket) for updates. It does this by either using a webhook or checking for changes every few seconds. This makes the system act as a Policy Administration Point (PAP), which sends the policy changes to your policy engine, ensuring it is always up to date.
The ability to track any relevant data source (API, Database, external service) for updates via a REST API, and fetch up-to-date data back into your policy engine.

Using these capabilities allows you to take advantage of the full benefits of policy languages by keeping your policy engines up to date with all the relevant policies and data in real time.

Please consider supporting this open-source project by giving OPAL a star on GitHub.

Conclusion

Domain-specific declarative languages are proving to be crucial tools in managing complex tasks in software development. They help us build systems that are high-performing, secure, and user-friendly. Whether it's managing fine-grained access controls or adapting to the demands of AI agents, these languages are keeping us ahead of the curve.

Authorization is a critical component of any modern application, and we can see the tremendous benefit brought to this space with domain-specific declarative languages. Open Policy Agent (OPA), AWS' Cedar, and OpenFGA allow us to tackle the challenges that come with the modern state of IAM, while OPAL (Open Policy Administration Layer) enhances their functionality by automating the synchronization between the policy store and the real-time data required for decision-making, ensuring that policies are consistently applied with the latest relevant data. This integration enables us to create secure, reliable, and dynamic authorization systems that can adapt to changing conditions and requirements.

Authentication is Not Enough: Here's Your Auth Roadmap for 2024

Gabriel L. Manor — Wed, 27 Dec 2023 11:30:00 +0000

Reflecting on the technological advancements of 2023, it was a remarkable year for software developers. Notably, the introduction of tools like Co-pilot has exponentially expedited development speed, while AI agents and vector databases have been effectively processing massive amounts of data for meaningful insights. Moreover, frontend clouds have revolutionized the deployment process, enabling full-stack applications to be launched in mere minutes.

Building on these advancements, our prediction for 2024 is a continued focus on security and reliability. Specifically, we forecast the implementation of robust features that will secure and support the evolution of these remarkable trends into our applications.

In the following article, we will delve into one of the most fundamental areas in user experience and security, access control, and find the five new features we should implement in 2024 to benefit the most from the amazing capabilities of applications nowadays.

Passkeys Authentication

Passwords have not been considered a secure method to verify identities for many years now. Not only have brute-force techniques become easy to apply even for complex passwords with modern methodologies, but the nature of users using one key for all their applications also makes it a bad pattern for secure applications.

Over the last decade, Multi-Factor Authentication (MFA) has attempted to address the security issues associated with passwords by requiring users to verify their identity using an additional factor. While MFA initially held great promise, by 2023, MFA fatigue attacks had become a significant attack surface, and MFA was no longer considered the most secure method.

Besides the security issues, passwords with MFA are also considered a bad user experience. They need to remember multiple passwords (or have weak security), insert them many times, and use a device as another factor for authentication. Passkeys authenticate users with a method that proves their identity with biometrics or physical devices.

In 2023, WebAuthn, an open standard for passkeys and biometric authentication, was adopted by all the main application platforms, including all modern browsers and mobile devices. The WebAuthn standard paved the way for every application developer to adopt passkeys as an authentication method.

Using open-source tools like Hanko.io can help you implement passkeys into any application in a matter of minutes. With WebAuthn and Hanko, you can ensure your application provides an amazing and secure experience for all your users in 2024.

Fine-Grained Authorization

The amount of data we process in our applications is growing exponentially every day. One of the challenges with data of any size is managing who can perform operations on it, or in other words, authorizing users in our applications.

The complexity of authorization with large amounts of data has two aspects

From the decision-making perspective, much more data is involved in our decisions. For example, to decide the permissions of a subset of data, we need to consider the time it was created, the users who are related to it, and more. All of that makes authorization decisions more complex than ever.
From the permissions perspective, we need to obtain high granularity on the permission levels we get on the data. For example, we want to give someone access to file metadata, but not to its content.

While the traditional Role-Based Access Control (RBAC) used to be the de-facto authorization capability of applications, the amount of data and the challenges we encounter cannot fit into the simple roles we assign to users. This is where Fine-Grained authorization comes into the picture.

Fine-grained authorization combines advanced approaches such as Relationship-Based Access Control (ReBAC) and Attribute Based Access Control (ABAC) to provide the granularity that modern applications with complex data deserve.

Please Support Us

If you find this post helpful,please give OPAL a star on GitHub! Your support helps us make access control easier and motivates us to write more articles like this one.

For example, ReBAC leverages the relationships between data entities to evolve the static RBAC model into a dynamic one, deriving permissions between entities. In ABAC, we use data attributes to construct conditions that enable detailed decision-making for authorization.

Example of RBAC/ABAC/ReBAC usage in one healthcare permissions model 👇🏻

Implementing fine-grained authorization has become essential for every application, and you should prioritize it in 2024.

Decouple Policy from Code

The most trending cloud-native field in 2023 was the "frontend" cloud. Services for edge computing, such as Vercel Edge and Railway, provide an efficient way for developers to deploy comprehensive full-stack web applications to a fully managed cloud environment in record time. This trend is simply a continuation of our application's nature to exist in small, autonomous environments, separate from each other.

While the separation of concerns and modern distributed architectures are great for rapid development, it's challenging to ensure our security standards are streamlined across all applications. To assist with the authorization aspect, we need to decouple policy from code.

In the decoupling pattern, instead of using imperative code to write authorization conditions in the application code, we use dedicated languages or standards to declare centralized policy rules in one policy store. All the distributed applications enforce their permissions using these streamlined policy rules.

Another approach that has been gaining traction lately is using policy as a graph. This is similar to the concept of Policy as Code, but incorporates a graph DB into the mix. This graph DB contains all the nodes as resources and users, while the edges determine the dynamic permission derivations. This approach is primarily relevant to the ReBAC model we discussed earlier.

In 2023, AWS announced its first application policy language, Cedar, which paved the way for giants to join the party and use the decoupling pattern as the best practice for application authorization. Cedar allows application developers to adopt Policy as Code and implement fine-grained authorization into their applications without the hassle of creating complex policies.

Here's an example of how Cedar code combines RBAC and ABAC. 👇🏻

permit(
    principal in Role::"writer",
    action in [Action::"post", Action::"put"],
    resource in ResourceType::"article"
) when { principal.karma > 1000 || (context has published && context.published == false) }

Another tool that can help you deploy a Policy as Code-based solution in 2024 is OPAL, the Open Policy Administration Layer. OPAL is an open-source project that provides a comprehensive policy-based service for applications. With one click, you can deploy a full architecture of a Git-based centralized policy store with decentralized policy engines running as a sidecar with your applications. OPAL also provides a unified architecture to sync all the data you need with the policy engines.

Better Audit Logs

2023 was a year of diversity, not only in the workforce but also in our application identities. Besides users, our application now has access to many computer-based identities, such as AI agents, bots, and more. Even our application code is accessible by co-pilots, CI/CD automation, etc.

A fundamental requirement for stable access control is audit logs, often referred to as the recurring this.audit({…}) code snippet that should be placed wherever an authorization decision occurs. Given the diversity of identities accessing our applications, these logs require special attention. We must ensure that at any given time, we can precisely audit who has access to which resource in our applications.

Modern policy engines and policy-as-code architectures solve many aspects of audit log challenges. First, they allow developers to define a single location where all the authorization audit logs are logged. Second, since all the policy rules are configured in the same way, the logs can provide much more data with no extra effort.

Besides that, Policy as Code architectures provide logging of all the changes in authorization. It starts with configuration changes that are logged in the same format, continues with versions and data updates, and then the application decisions themselves.

Using a policy-as-code system can provide you with what you need to start improving audit logs in your applications in 2024.

Approval Flows

In the early days of applications, permissions were only in a Mandatory Access Control (MAC) model, which meant the application developer was the only one to assign permissions to users. The modern web replaces MAC with Discretionary Access Control (DAC), which allows users to assign permissions to themselves and to other users.

The rise of AI and cloud-native architectures in 2023 pushed the DAC to a new limit. Users now need to assign permissions for scopes of data that are unknown to the application developer. For example, users now want the ability to give access to third-party AI applications that are unknown to developers, and they want to define the scope of the data to which they are allowing access. The best way to deal with this is through policy-based approval flows.

In a well-structured approval flow, the developer defines the tasks or the flow of permissions in the form of request → approve (or partial approve) → policy change. Using policy as code, this configuration is not coupled to a particular configuration or data. For example, a developer defines a method for users to approve other users to access their data by dynamically generating new policy rules into the policy engine.

In our work in 2023, we found that Approval Flows are one of the most requested features by our users for their applications. Our perspective is that 2024 will be full of ideas and work around defining and designing smart approval flows for applications.

Conclusion

The list you just read summarizes the work we did at Permit.io with Application Developers in 2023. As the leader in end-to-end solutions for application authorization as a service, we have experience with various types of applications and engineering teams around authorization and access control.

If you plan to implement improved access control in your application in 2023, we encourage you to open a free account on the Permit.io platform and try our solutions for fine-grained authorization. Our service is based on policy-as-code and a decentralized architecture, and our audit logs are industry-leading.

In the meantime, you can join our Authorization Slack community, where we chat and collaborate on day-to-day access control challenges. See you there.

How Reddit Built Authorization with OPA

Gabriel L. Manor — Mon, 18 Dec 2023 18:30:00 +0000

Introduction

Effectively managing Authorization in Advertising Technology (Ad Tech), is a complex and crucial task. Tackling this challenge, *Reddit * developed an advanced authorization system for its advertising platform, a process described in great detail by Staff Engineer Braden Groom in this Reddit post.

Inspired by Braden’s post, this blog explores the journey of Reddit's team, focusing on their strategic decisions, the challenges they encountered, and the innovative solutions they crafted. Alongside Reddit's in-house efforts, we also examine OPAL, an open-source solution that aligns with the functionality of Reddit’s system, presenting an alternative approach for organizations seeking sophisticated authorization management solutions in the field of Ad Tech.

Authorization in Ad Tech

Advertising technology consists of a wide range of digital strategies and platforms for targeting, delivering, and analyzing online advertisements. From advertisers and publishers to ad exchanges and networks, each of these entities manages vast amounts of data and a range of transactions with multiple stakeholders involved.

One of the critical challenges in Ad Tech is authorization. Unlike simpler systems where access control can be relatively straightforward, authorization in Ad Tech platforms requires a more sophisticated approach.

Advertisers have distinct expectations of how their accounts should be structured and who should access them. These systems should not only be thoroughly secure but also flexible enough to accommodate a wide range of requirements. They need to manage who (or what, in the case of automated systems) has access to which parts of the platform, under what conditions, and to what extent. This requirement for detailed and dynamic access control is where basic authorization solutions often fall short, necessitating more advanced, granular solutions.

Reddit’s Ad Tech platform as a case study

Reddit is one of the largest online platforms out there, with its advertising platform being an integral part of its business model, allowing businesses to tap into its vast and varied user base. The platform enables advertisers to target audiences based on interests, demographics, and behaviors.

As much of Reddit’s content is public and does not necessitate an overly complex authorization system, Reddit’s team was unable to find an existing generalized authorization service within the company and started exploring the development of a homebrew solution within the ads organization.

In his post, Braden Groom, a Staff Engineer at Reddit, describes the unique challenges Reddit faced with creating authorization for its Ad Tech platform, specifically with crafting an effective authorization system for its advertising platform. These challenges stem from the need to cater to a diverse range of advertiser requirements and the complex nature of digital advertising itself.

Let’s start by seeing what their requirements were -

Reddit’s Authorization Requirements:

In developing its authorization system for the advertising platform, Reddit identified several crucial requirements that would guide its approach. These requirements were essential in ensuring that the system would not only meet their current needs but also be adaptable for future challenges:

Low latency

Every action on Reddit’s advertising platform necessitates a rapid authorization check. This requirement for low latency is crucial to ensure a seamless experience for users and advertisers alike.

Availability

An outage in the authorization service could mean a complete halt in the operation of the advertising platform, making it impossible to perform essential authorization checks. Therefore, high uptime is critical to maintain the continuous functioning of the platform.

Auditability

For security and compliance, a detailed log of all decisions made by the authorization service is necessary. This aspect of auditability is not just a regulatory requirement but also a fundamental component of managing this system, especially in the case of unauthorized access. It allows Reddit to track and review authorization decisions, ensuring that the system is functioning correctly and adhering to all necessary policies and regulations.

Flexibility

Reddit, like every player in the advertising landscape, must frequently evolve based on the expectations of its advertising partners - allowing them to define and manage their own roles. Therefore, the authorization system must be flexible and adaptable to changing requirements without significant overhauls.

Multi-Tenancy (stretch goal)

While not an explicit initial requirement, Reddit aimed for a multi-tenant capability in their authorization system. This goal was set with the understanding that a generalized authorization solution was lacking at Reddit, and thus, a system that could address multiple use cases across the company would be beneficial. Although focused on the advertising platform, this stretch goal would enhance the system’s flexibility and scalability, allowing it to potentially serve various needs across Reddit as a whole.

With the requirements laid out before us, there is one more important challenge, unique to ad tech, to consider -

Authorization for Anonymous Identities

An additional significant challenge with advertising on a platform like Reddit comes from the fact that a large portion of user interaction occurs through anonymous identities, as you don’t have to create an account in order to browse content (And see ads while you do). This presents a unique challenge in the context of advertising authorization.

When it comes to advertising, the platform needs to perform authorization checks to determine which ads to show to which users. These checks are straightforward when dealing with registered users, as their profiles, preferences, and histories can guide ad targeting. However, for anonymous users, the platform lacks this personalized data, requiring a different approach to authorization and ad targeting.

So how did the Reddit team seek to tackle these challenges, and what can we learn from their experience? Let’s start with the first principle they decided to implement -

Decoupling Policy from Code

Inspired by Google Zanzibar, the first decision the Reddit team decided to make when designing their authorization solution was decoupling policy and code. Separating the app’s authorization code from the actual application code is a recommended best practice for various reasons.

The Reddit team explained their choice to do so meant their database had to perform no rule evaluation when fetching rules at query time, keeping the query patterns “simple, fast, and easily cacheable”. Rule evaluation will thus only happen in the application after the database has returned all of the relevant rules. Having the policy storage and evaluation engines clearly isolated also allowed them to potentially replace one of them with relative ease if they decide to do so in the future.

To achieve that, they have decided to use the Open Policy Agent (OPA) policy engine.

Open Policy Agent

Open Policy Agent (OPA) is an open-source, general-purpose policy engine that decouples policy decision-making from policy enforcement. It provides a high-level declarative language (Rego) to specify policy as code and APIs to offload decision-making from your software.

OPA was already in use at Reddit for Kubernetes-related authorization tasks. It also provides a testing framework that the Reddit team could use to enforce 100% coverage for policy authors.

Using OPA allowed the Reddit team to facilitate centralized rule management, allowing policies to be defined in a unified manner and applied consistently across various parts of a system, maintaining consistency and manageability.

OPA’s architecture also enabled policies to be enforced anywhere in the system without requiring the policy engine to be co-located with the service making the decision. This is aligned with Reddit's approach of separating rule retrieval from rule evaluation.

An example of Rego code representing ABAC rule 👇🏻

package abac

# User attributes
user_attributes := {
    "Squid": {"tenure": 10, "title": "cashier"},
    "Pat": {"tenure": 0.5, "title": "cashier"}
}

# Menu attributes
menu_attributes := {
    "Burger": {"items": "Menu", "price": 3},
    "Shake": {"items": "Menu", "price": 1}
}

default allow = false

# All cashiers may process orders of up to 1$ total
allow {
    # Lookup the user's attributes
    user := user_attributes[input.user]
    # Check that the user is a cashier
    user.title == "cashier"
    # Check that the item being sold is on the menu
    menu_attributes[input.ticker].items == "Menu"
    # Check that the processed amount is under 1$
    input.amount <= 1

}

# Cashiers with 1=> year of experience may ⁠process orders of up to 10$ total.
allow {
   # Lookup the user's attributes
    user := user_attributes[input.user]
    # Check that the user is a cashier
    user.title == "cashier"

    # Check that the item being sold is on the menu
    menu_attributes[input.ticker].items == "Menu"
    # Check that the user has at least 1 year of experience
    user.tenure > 1
    # Check that the processed amount is under is under $10
    input.amount <= 10
}

Another decision made by the Reddit team was to build a centralized service instead of a system of sidecars. While the sidecar approach seemed viable, it seemed unnecessarily complex for their needs, so they opted for a centralized service to keep maintenance costs down.

Modeling Policy Rules

As outlined in the requirements of the Reddit team, it was crucial for them to create a highly flexible system capable of accommodating the evolving needs of their advertising platform.

To do that, developers often utilize the use of common authorization models such as RBAC, ABAC, and ReBAC. The Reddit team decided to take a more abstract approach, creating rules consisting of three fields describing access policies:

Subject: Describes who or what the rule pertains to.
Action: Specifies what the subject is allowed to do.
Object: Defines what the subject may act upon.

As well as two more fields representing different layers of isolation:

Domain - Represents the specific use-case within the authorization system. For example, there is a distinct domain dedicated to advertisements, while other teams within Reddit can utilize the service for different domains, such as community moderation, maintaining isolation from the advertising domain.
Shard ID - Provides an additional layer of sharding within the domain. In the advertising domain, sharding is organized by the advertiser's business ID, whereas in the community moderation domain, sharding could be based on community IDs.

Rule Storage, OPAL, and GitOps

The system Reddit designed does not enforce validations on these fields. Each use-case has the freedom to store simple IDs or employ more sophisticated approaches, such as using paths to describe the scope of access. Each use-case can shape its rules as needed and encode any desired meaning into its policy for rule evaluation.

Whenever the service is asked to check access, it only has one type of query pattern to fulfill. Each check request is limited to a specific (domain, shard ID) combination, so the service simply needs to retrieve the bounded list of rules for that shard ID. Having this single simple query pattern keeps things fast and easily cacheable. This list of rules is then passed to the evaluation side of the service.

As mentioned above, Reddit’s team made a strategic decision to develop a centralized service for managing authorization. While the Reddit team made the decision to develop this capability themselves, it is also possible to achieve these results by using OPAL.

Open Policy Administration Layer (OPAL), is an open source administration layer for Policy Engines such as Open Policy Agent (OPA), and AWS' Cedar Agent that detects changes to both policy and policy data in real time and pushes live updates to those agents. Using Git repositories and GitOps as a method for rule storage, OPAL provides several benefits:

Version Control: Using Git repositories for rule storage means that every change is tracked. This is crucial for audit trails, allowing teams to see who made changes, when, and why.
Rollback and History: In case of errors or unforeseen issues, it’s easy to roll back to previous versions of policies, enhancing the system's reliability.
Collaboration and Review: GitOps facilitates collaboration among team members. Changes can be reviewed through merge requests, ensuring that updates to policies undergo scrutiny before implementation.
Automated Deployment: Changes in the repository can trigger automated deployments, making the update process more efficient and reducing manual intervention.

Rule Evaluation, Policy, and Data Synchronization

After successfully establishing a system for efficiently retrieving rules, the next step for the Reddit team was to evaluate these rules and generate an answer for the client.

For each domain within their system, the ability to define specific policies determining how rules are evaluated was crucial. Although their application was written in Go, which would have facilitated the direct implementation of these policies, Reddit prioritized keeping policy logic distinctly separate from the application logic.

As mentioned previously, this separation served two key purposes: it prevented policy logic from inadvertently influencing other parts of the service and allowed for remote updating of policy logic, enabling clients to publish policy updates independently of service deployments.

In parallel to the bespoke solution developed by Reddit, OPAL (Open Policy Administration Layer) stands out as a ready-made open-source solution offering similar capabilities. OPAL, when used in conjunction with OPA, acts as a dynamic administration layer, ensuring the policy engine is continuously synchronized with the latest policies and data. This is achieved by deploying OPAL Clients alongside OPA, which then subscribe to topic-based Pub/Sub updates. These updates are efficiently managed and disseminated from the OPAL Server, supplemented by data from various sources like databases, APIs, or third-party services.

The synergy of OPA and OPAL provides a comprehensive solution for managing authorization systems, particularly in environments as dynamic and complex as Reddit's advertising platform.

Please Support Us

If you find this post helpful,please give OPAL a star on GitHub! Your support helps us make access control easier and motivates us to write more articles like this one.

Auditing

To fulfill the requirements mentioned above, the Reddit team had to create a system of Audit Logs to record all decisions made by the service, playing a crucial role in both compliance and security. The auditing mechanism was implemented in two distinct parts:

A change data capture pipeline: This system is engineered to track and upload all changes occurring within the database directly to BigQuery. This process ensures that every modification, whether minor or significant, is captured and stored securely for review and analysis.
Application logs : The application itself also logs all of the decisions, which are then uploaded to BigQuery by a sidecar. While this functionality was developed in-house, it's noteworthy that OPA also offers a decision log feature.

Initially, these auditing features were primarily integrated for compliance and security purposes. However, as the system evolved, the team discovered an additional, invaluable benefit: these logs became a powerful tool for debugging. By providing detailed insights into the decision-making process of the authorization service, the team gained the ability to trace and rectify issues with greater efficiency and precision.

Performance

Following the implementation of their newly developed authorization service, the Reddit team undertook several key steps to align the service with the needs of their advertising platform.

They established a detailed rule structure, defined policies for rule evaluation, integrated authorization checks throughout the platform, and developed user interfaces tailored for rule definition on a per-business basis.

Upon reviewing the performance of the newly implemented service, the Reddit team reported outstanding results. The service has demonstrated impressive efficiency, with p99 latencies around 8 milliseconds and p50 latencies close to 3 milliseconds for authorization checks. These metrics are indicative of the service's ability to handle authorization requests swiftly and effectively.

Equally notable is the service's remarkable stability. Since its launch over a year ago (At the time Branden published his post), the service has operated without any outages, underscoring its reliability. Interestingly, the majority of issues encountered were related to logical errors within the policies themselves, rather than the infrastructure or the software.

A critical factor contributing to the service's success is the separation of policy and code and its effective use of audit logs. This system ensures that the results of every check are accurately recorded, and isolated from other software complexities. In many systems, the lack of clear separation between policy and code can lead to muddled results and increased difficulty in debugging. However, by decoupling policy from code and maintaining detailed audit logs, Reddit has been able to achieve clear, unambiguous insights into the authorization process. This clarity not only aids in compliance and security but also significantly enhances the debugging and maintenance process, ensuring the system remains efficient and reliable.

Conclusion

Reddit's journey in crafting the authorization system for its advertising platform shows the complex challenges in the realm of Ad Tech. Their endeavor, as described by Staff Engineer Braden Groom, underscores a crucial evolution in managing digital advertising's nuanced authorization demands.

The choice to decouple policy from code, inspired by Google's Zanzibar, and the implementation of Open Policy Agent (OPA) reflect Reddit’s commitment to building a system that is both robust and adaptable. The auditing mechanisms they established, ensuring every action is logged and reviewable, not only enhance security and compliance but also serve as a powerful tool for debugging and system refinement.

Reddit's results speak for themselves. The performance metrics of their authorization checks and the system's remarkable stability since its launch are testaments to the efficacy of their solution. The clear separation of policy and code, paired with comprehensive audit logs, has provided them with a system that is efficient, reliable, and adaptable to ever-changing needs.

We also learned about OPAL, an open-source solution that echoes the functionalities developed by Reddit. Its use of Git repositories and GitOps for rule storage, combined with the dynamic synchronization capabilities provided by OPAL Clients, offers a streamlined, efficient alternative for managing complex authorization systems. For organizations seeking to implement sophisticated authorization management without building from scratch, OPAL presents a compelling option, enabling them to stay agile and responsive in the fast-evolving landscape of digital advertising.

Reddit's case study is a shining example of how thoughtful, well-engineered solutions can successfully meet the intricate demands of Ad Tech authorization. It serves as both a blueprint and an inspiration for others in the industry, showcasing the power of innovative thinking in overcoming complex technological challenges.

Want to learn more about Authorization? Join our Slack community, where there are hundreds of devs building and implementing authorization.

DEV Community: Gabriel L. Manor

Building a Secure Flight Booking System with LLM Agent in Langflow

Tool Overview

Prerequisites

Configuring Attribute-Based Access Control Policies

Resources:

User Attributes

Condition Sets

Setup a New Project and Credentials

Define Resources

User Attributes

Creating Condition Sets

Enforcing Policies

Building the Flows

Setting up local PDP container

Flight Search Flow

Flight Information Flow

Flight Booking Flow

Conclusion

DeepSeek Completely Changed How We Use Google Zanzibar

What is Google Zanzibar?

Why Policy-as-Graph?

Why Relationships?

What Are Relationship Tuples?

The Challenge of Maintaining Policy-as-Graph

The Solution: Management Layer + AI Tuple Generator

How Does This Help?

Is This Production-Ready?

What Are We Going to Build?

Project set-up

Setting Up the ReBAC Schema

Building the Node.js + DeepSeek Parser

Configuring our Node.js application

Prompt engineering

Creating ReBAC Relationships

Testing and Validation

Real-world usage

Event-driven system for syncing relationships

AI-Powered Permission Bots for Automated Access Requests

AI Agents for Proactive Permission Management

The Future of AI-Driven Access Control

Building AI Applications with Enterprise-Grade Security Using RAG and FGA

Introduction

Use Case Example: Healthcare Applications

Security Through Fine-Grained Authorization

Retrieval Augmented Generation (RAG)

Implementation Guide

1. Ingestion Flow

2. Chat Flow

PermitFilter Component

See It In Action

Conclusion

How Custom GitHub Actions Enabled Us to Streamline Thousands of CI/CD Pipelines

Introduction

Understanding Your Architecture for the CI/CD

The Advantages of a CI/CD Structure

Workflow Friction: Identifying the Challenges

Creating a Custom GitHub Action

Workflow Breakdown

1. Creating a New Environment (new-env.yaml)

2. Running Tests in the New Environment (run-pdp.yaml)

3. Merging Changes and Cleanup (merging.yaml)

Our Custom GitHub Action

Conclusion

7 Developer Tools to Prepare Your Stack for the GenAI Era

Permit Share-If - Embeddable access sharing components | Product Hunt

1. Arcjet

2. GitButler

3. DataStax AstraDB and Langflow

4. Lunar.dev

5. Fern

6. Permit.io

7. Neon

Conclusion

Announcing “Permit Share-If" Embeddable Access Sharing Components

Never Build Access-Sharing Again

Permit Share-If - Embeddable Access Sharing Components | Product Hunt

What is Permit Share-If?

A Holistic Solution to Fine-Grained Authorization

Share-If Features:

1. Creating a New Environment (`new-env.yaml`)

2. Running Tests in the New Environment (`run-pdp.yaml`)

3. Merging Changes and Cleanup (`merging.yaml`)