This guide demonstrates how to build a Node.js application using a new approach to security: Token-Based Access Control, where developers authorize capabilities by presenting a bundle of JWT tokens to a policy engine, specifically the Janssen Project Cedarling. The Cedar policy syntax is very expressive. A developer can even express policies based on a person’s role or group membership. And that’s exactly what we’re going to do here: use TBAC to implement RBAC and ABAC. That may not sound very clear, but please continue for more details on why this makes sense.

🎬 Sample Application: Cloud Infrastructure

For demo, we’re going to use role-based access control (or “RBAC”) and attribute-based access control (or “ABAC”) to develop a sample application that allows users to create, update, and delete virtual machines. It’s a very simple version of Digital Ocean APIs! In the sample application, we have a simple username and password login that simulates OAuth tokens. In your real application, you can add federated authentication via a standard OpenID Connect Provider. After authentication, Cedarling plays a role in authorization, which will take roles from the ID Token to authorize a user. Below are the roles that will perform the following actions and access virtual machine resources. If a user has enough permission, then allow the action; otherwise, deny.

• Principals: Users with roles like admin, developer, and auditor.
• Actions: Create, Update, Delete, and View virtual machines
• Resources: Virtual Machine

Roles and Permissions:

1. Admin:

• Can perform any operation

2. Developer:

• Can perform Create But the limit should be > 0
• Can perform Update, View
• Cannot perform Delete

3. Auditor

• Can perform only View

🔧 Setting Up Cedar Policies

We’ll use the Agama-Lab Policy Designer to create and manage our authorization policies. Check out the Agama Lab Documents for more information.

Step 1: Create Policy Store

1. Sign-in to Agama Lab with your GitHub ID.
2. Open the Policy Designer section.
3. Select the repository where you want to save your policies.
4. Create a new policy store named JansNodeJSCedarling.

Step 2: Define Schema

1. Open the Manage Policy Store section by clicking the arrow link button on the store list.
2. Create an Entity called VirtualMachine, which is our sample Resource.

3. Once you add the Resource, you need to associate an action with it. Configure actions (Create, Update, Delete, View):

• Set Principal: User
• Set Resources: VirtualMachine

Step 3: Create Policies

1. Go to Manage Policy Store > Policies > Add Policy > Text Editor.
2. Copy policies one by one, add to the text editor, and save.

i. Admin Policies (full access): Admin can perform any action

@id("AdminCanDoAnything")
permit (
  principal in Jans::Role::"admin",
  action,
  resource
);

Only the admin can delete resources.

@id("OnlyAdminCanDelete")
forbid (
    principal,
    action == Jans::Action::"Delete",
    resource
)
unless {
   principal in Jans::Role::"admin"
};

ii. Developer Policies:

Developers can create Virtual Machines within limits. Below is an example of attribute-based access control(ABAC) where we are authorizing user access based on id_token.limit.

@id("LimitDeveloperCreateAccess")
permit (
  principal in Jans::Role::"developer",
  action in [Jans::Action::"Create"],
  resource is Jans::VirtualMachine
)
when {
  principal has id_token.limit &&
  principal.id_token.limit > 0
};

Developers can update and view VMs

@id("DeveloperCanUpdateView")
permit (
  principal in Jans::Role::"developer",
  action in [Jans::Action::"Update",
  Jans::Action::"View"],
  resource is Jans::VirtualMachine
);

iii. Auditor Policy

Auditor can only view resources.

@id("AuditorCanViewOnly")
permit (
  principal in Jans::Role::"auditor",
  action == Jans::Action::"View",
  resource
);

Step 4: Setup Trusted Issuer

A trusted issuer is required to configure the Cedarling. We can configure which token is used for user and workload authentication. access_token is for workload and id_token is for user authentication. The cedarling also validates the access token and ID token, so we need to add configuration for both tokens in the token metadata. More details

• Go to Manage Policy Store > Trusted Issuer > Add Issuer.
• Add name, description, and OpenID Configuration endpoint
• Add token metadata

{
  "access_token": {
    "trusted": true,
    "entity_type_name": "Jans::Access_token",
    "user_id": "sub",
    "token_id": "jti",
    "workload_id": "rp_id",
    "claim_mapping": {},
    "required_claims": [
      "jti",
      "iss",
      "aud",
      "sub",
      "exp",
      "nbf"
    ],
    "role_mapping": "role",
    "principal_mapping": [
      "Jans::Workload"
    ]
  },
  "id_token": {
    "trusted": true,
    "entity_type_name": "Jans::id_token",
    "user_id": "sub",
    "token_id": "jti",
    "role_mapping": "role",
    "claim_mapping": {},
    "principal_mapping": [
      "Jans::User"
    ]
  }
}

🧑‍💻 Setting up a Node.js Application

Step 1: Install the Cedarling WASM

npm install @janssenproject/cedarling_wasm@0.0.131-nodejs

You just need to add the suffix -nodejs in the current version to install Node.js Cedarling version. By default, it installs the web cedarling version.

Step 2: Configure the Cedarling

Initialize with these properties:

export const cedarlingBootstrapProperties = {
  CEDARLING_APPLICATION_NAME: 'CloudInfrastructure',
  CEDARLING_POLICY_STORE_URI: '<your_policy_store_URI>',
  CEDARLING_USER_AUTHZ: 'enabled',
  CEDARLING_LOG_TYPE: 'std_out',
  CEDARLING_LOG_LEVEL: 'INFO',
  CEDARLING_LOG_TTL: 120,
  CEDARLING_PRINCIPAL_BOOLEAN_OPERATION: {
    '===': [{ var: 'Jans::User' }, 'ALLOW'],
  },
};

• CEDARLING_POLICY_STORE_URI: URL of your policy store (from Agama-Lab). In the policy store list, use the link button to copy the policy store URI.

Step 3: Create Authorization Client

This class implements a singleton pattern for managing Cedar authorization using WebAssembly (WASM), providing a centralized way to initialize the Cedar policy engine and perform authorization checks. It wraps the @janssenproject/cedarling_wasm module to handle policy evaluation through a single, reusable instance that can be accessed throughout the application.

class CedarlingClient {
  private static instance: CedarlingClient;
  private cedarling: Cedarling | null = null;
  private initialized = false;
  // eslint-disable-next-line @typescript-eslint/no-explicit-any

  private constructor() {}

  static getInstance(): CedarlingClient {
    if (!CedarlingClient.instance) {
      logger.info("WASM initialing. Creating new instance");
      CedarlingClient.instance = new CedarlingClient();
    }
    return CedarlingClient.instance;
  }

  // eslint-disable-next-line @typescript-eslint/no-explicit-any
  async initialize(policyStoreConfig: any): Promise<void> {
    if (!this.initialized) {
      this.cedarling = (await init(policyStoreConfig)) as unknown as Cedarling;
      logger.info("WASM initialized", this.cedarling);
      this.initialized = true;
    }
  }

  // eslint-disable-next-line @typescript-eslint/no-explicit-any
  async authorize(request: any): Promise<AuthorizeResult> {
    if (!this.cedarling || !this.initialized) {
      const errorMessage = "Cedarling not initialized";
      logger.error(errorMessage);
      throw new Error(errorMessage);
    }
    try {
      const result = await this.cedarling.authorize(request);
      return result;
    } catch (error) {
      logger.error("Error during authorization:", error);
      throw error;
    }
  }
}

export const cedarlingClient = CedarlingClient.getInstance();

Step 4: Initialize Cedarling

We are globally initializing the Cedarling object. You can add it to your app’s startup files. Like in the sample application, you can add it in app.ts.

app.listen(PORT, () => {
  cedarlingClient.initialize(cedarlingBootstrapProperties).catch(console.error);
  logger.info(`Server running on http://localhost:${PORT}`);
  swaggerDocs(app, Number(PORT));
});

Step 5: Middleware for Authorization

This Node.js middleware provides authorization functionality using the Cedarling client, with the ability to enforce authorization checks. The middleware builds the request for cedarling with actions, resources, and tokens, and checks the cedarling authz results. This is just an example to protect the route. You can write your logic to protect resources as per your requirements with the help of the Cedarling client.

export const authenticate = async (
  req: Request,
  res: Response,
  next: NextFunction
) => {
  try {
    const authHeader = req.headers.authorization;
    const token = authHeader.split(' ')[1];

    .
    .
    .

    // Cedarling authorization
    const request = {
      tokens: {
        access_token: token,
        id_token: token,
      },
      action: `Jans::Action::"${getAction(req)}"`,
      resource: {
        type: "Jans::VirtualMachine",
        id: "CloudInfrastructure",
        app_id: "CloudInfrastructure",
        name: "CloudInfrastructure",
        url: {
          host: "jans.test",
          path: "/",
          protocol: "http",
        },
      },
      context: {},
    };

    logger.info(`Request: ${JSON.stringify(request)}`);

    const result = await cedarlingClient.authorize(request);
    logger.info(`Authentication result: ${result.decision}`);

    if (!result.decision) {
      throw new HttpException(403, "Permission denied!");
    }

    next();
  } catch (error) {
    logger.error(`Authentication failed: ${error}`);
    next(error);
  }
};


export const getAction = (req: Request): string => {
  if (req.method === 'GET') {
    return 'View';
  } else if (req.method === 'POST') {
    return 'Create';
  } else if (req.method === 'PUT') {
    return 'Update';
  } else if (req.method === 'DELETE') {
    return 'Delete';
  } else {
    return 'Invalid';
  }
};

In the above example:

• We make a middleware authenticate which helps us to make an authorization request to the Cedarling WASM with Access Token and ID Token. Your ID Token should have a Role claim, and if you don't have a role, then you need to change the policy, which will act like ABAC.
• The getAction function helps to get the correct action.
• There is a request object that checks the authorization for the action. In response, it returns a result where we get which policy is responsible for authorization, timestamp, and decision. Below is an example of the Create(or POST HTTP request) action result. Use result.decision to authorize the request and show/hide elements.

{
  "id": "0197a15c-cee0-72da-905f-5800be68fc4b",
  "request_id": "0197a15c-ced6-7653-b17d-257d50de663e",
  "timestamp": "2025-06-24T15:25:03.520Z",
  "log_kind": "Decision",
  "policystore_id": "22942366f5ad4d8338514bc402d4b901b056051f2bed",
  "policystore_version": "undefined",
  "principal": ["User"],
  "User": {},
  "diagnostics": {
    "reason": [
      {
        "id": "feac81b973836478ae6478ac63b59d4f2f6691dcddae",
        "description": "LimitDeveloperCreateAccess"
      }
    ],
    "errors": []
  },
  "action": "Jans::Action::\"Create\"",
  "resource": "Jans::VirtualMachine::\"CloudInfrastructure\"",
  "decision": "ALLOW",
  "tokens": {
    "id_token": {
      "jti": "6dV4hO0kQ3OaPJerJHNwgg"
    },
    "access_token": {
      "jti": "6dV4hO0kQ3OaPJerJHNwgg"
    }
  },
  "decision_time_micro_sec": 7000,
  "pdp_id": "a446ecda-b6aa-4ad5-9d0e-b7c09b1fb30e",
  "application_id": "CloudInfrastructure"
}

✅ Test Cases

Admin Authorization

Let’s log in as an admin user and check the authorization. According to the above authorization policies, admin can access any resource. As you can see in the video below, Sachin is an admin user, and he has the admin role.

🟢 Admin can Create a VM

🟢 Admin can Update a VM

🟢 Admin can Delete a VM

🟢 Admin can View a VM

Developer Authorization

Log in with a developer role user and check the authorization.

🟢 Developer with limit, can Create a VM. You can see the video below. Dhoni is a developer user, and he has a limit limit: 1.

🔴 A developer with no limit cannot Create a VM. You can see the video below. Virat is a developer user with limit: 0 means he cannot create a new virtual machine.

🟢 Developer can Update a VM

🔴 Developer cannot Delete a VM

🟢 Developer can View a VM

Auditor Authorization

An auditor user can only view virtual machine resources.

🟢 Auditor can only View a VM

🔴 Auditor cannot Create a VM

🔴 Auditor cannot Update a VM

🔴 Auditor cannot Delete a VM

📚 Resources

For a complete implementation, reference the:

• Node.js Demo project
• Policy Store
• The Janssen Cedarling Documentation
• Janssen Home Page

Using Cedar to Modernize Authz in A Node.js Backend was originally published in Janssen Project Feed on Medium, where people are continuing the conversation by highlighting and responding to this story.

Security-aware frontends enable developers to personalize and improve user experiences. While in the past this meant a lot of “if-then” statements, or complex mappings of user roles to capabilities, the recent invention of the Cedar policy syntax offers new opportunities for React developers to leverage an embedded policy engine in their applications.

There are some other good reasons to use Cedar. Moving to “declarative” policies makes it easier for the CISO or security team to review application security rules. Also, the use of a Cedar policy engine guarantees consistent logs for all security decisions in an application. And consistent logging is the key to modern threat detection.

There has been another important security innovation that impacts React frontend developers: the move to JWT tokens to provide evidence for federated login. Today, instead of simply the user’s roles — just one vector of many — developers can make policies on any of the claims in the tokens they receive during the authentication and authorization journey. The use of tokens to govern access to resources is generically known as Token-Based Access Control.

This how-to article will introduce the Janssen Project Cedarling. This NPM package uses the performant Cedar Rust engine to enable React Developers to run their own local, embedded policy decision point (“PDP”). We’ll walk through setting up the integration with a practical example involving multiple roles and conditional policies. You’ll learn how to:

• Define the authorization schema
• Configure access policies
• Evaluate authorization requests
• Implement Cedarling’s streamlined authorization in React with minimal code

Sample Application: Task Management

For demo, we’re going to use role-based access control (or “RBAC”) to develop a sample application that performs Task Management. It’s a very simple version of Trello! For example, we will also support federated authentication via a standard OpenID Connect Provider. After authentication, Cedarling plays a role in authorization, which will take roles from the ID Token to authorize a user. Below are the roles which perform will perform the following actions and access Task resources. If a user has sufficient permission, allow the action; otherwise, deny it.

For our demonstration, we’ll implement Role-Based Access Control (RBAC) to build a sample Task Management application — essentially a simplified version of Trello. The application will feature:

1. Federated Authentication: Users will authenticate through a standard OpenID Connect Provider
2. Cedarling Authorization: After authentication, Cedarling will handle authorization by:

• Extracting user roles from the ID Token
• Evaluating permissions against Task resources
• Allowing or denying actions based on the user’s role

The system will enforce these access controls when users attempt to perform actions, only permitting operations when they have sufficient permissions.

• Principals: Users with roles like Admin, Manager, and Member.
• Actions: Add, Update, Delete, and View
• Resources: Task

Roles and Permissions:

1. Admin

• Can perform any operation

2. Manager

• Can perform Add, Update, View
• Cannot perform Delete

3. Member

• Can perform only View

Prerequisite

1. OpenID Connect Server: Use any compliant provider like Janssen, Google, or Okta.
2. React Application: Use any framework like Next.js or Vite.js to create a Fresh React App.

Setting Up Policies

We’ll use the Agama-Lab Policy Designer to create and manage our authorization policies. For more information, see the Agama Lab Documentation.

Step 1: Create Policy Store

1. Sign in to Agama Lab with your GitHub ID.
2. Open the Policy Designer section.
3. Select the repository where you want to save your policies.
4. Create a new policy store named JanssenReactCedarlingRBAC.

Step 2: Define Schema

1. Open the Manage Policy Store section by clicking the arrow link button on the store list.
2. Create an Entity called Task, which is our sample Resource.

3. Once you add the Resource, you must associate an action with it. Configure actions (Add, Update, Delete, View):

• Set Principal: User
• Set Resources: Task

Step 3: Create Policies

1. Go to Manage Policy Store > Policies > Add Policy > Text Editor.
2. Copy policies one by one, add to the text editor, and save.

• Admin Policy (full access):

@id("AdminPerformAnyOperationOnResource")
permit(
  principal in Jans::Role::"admin",
  action,
  resource
);

• Manager Policy (restricted access):

@id("ManagerCanAddUpdateViewTask")
permit (
  principal in Jans::Role::"manager",
  action in [Jans::Action::"Add",
  Jans::Action::"Update",
  Jans::Action::"View"],
  resource is Jans::Task
);

• Member Policy (view only):

@id("MemberCanOnlyViewTask")
permit (
  principal in Jans::Role::"member",
  action in [Jans::Action::"View"],
  resource is Jans::Task
);

Step 4: Set up Trusted Issuer

A trusted issuer is required to configure the Cedarling. We can configure which token is used for user and workload authentication. access_token is for workload and id_token is for user authentication. The cedarling also validates the access token and ID token, so we need to add configuration for both tokens in the token metadata. More details

• Go to Manage Policy Store > Trusted Issuer > Add Issuer.
• Add name, description, and OpenID Configuration endpoint
• Add token metadata

{
  "access_token": {
    "trusted": true,
    "entity_type_name": "Jans::Access_token",
    "user_id": "sub",
    "token_id": "jti",
    "workload_id": "rp_id",
    "claim_mapping": {},
    "required_claims": [],
    "role_mapping": "role",
    "principal_mapping": [
      "Jans::Workload"
    ]
  },
  "id_token": {
    "trusted": true,
    "entity_type_name": "Jans::id_token",
    "user_id": "sub",
    "token_id": "jti",
    "role_mapping": "role",
    "claim_mapping": {},
    "principal_mapping": [
      "Jans::User"
    ]
  }
}

Step 5: Generate CJAR

The Cedarling accepts a .CJAR zip file containing all the policies, schemas, and trusted issuers. To generate CJAR, go to Policy Manage Page > Release > Pre-release.

Once you release, you can find releases with the CJAR file on your GitHub.

Setting up a React Application

Step 1: Install the Cedarling WASM

npm install @janssenproject/cedarling_wasm@0.0.338

For Vite.js, update vite.config.ts:

import { defineConfig } from "vite";

export default defineConfig({
  optimizeDeps: {
    exclude: ["@janssenproject/cedarling_wasm"],
  },
});

Step 2: Configure the Cedarling

Initialize with these properties:

export const cedarlingBootstrapProperties = {
  CEDARLING_POLICY_STORE_URI: "<your-cjar-file-link>",
  CEDARLING_APPLICATION_NAME: "TaskManager",
  CEDARLING_USER_AUTHZ: "enabled",
  CEDARLING_WORKLOAD_AUTHZ: "disabled",
  CEDARLING_LOG_TYPE: "std_out",
  CEDARLING_LOG_LEVEL: "INFO",
  CEDARLING_PRINCIPAL_BOOLEAN_OPERATION: {
    "===": [{ var: "Jans::User" }, "ALLOW"],
  },
};

• CEDARLING_POLICY_STORE_URI: URL of your CJAR file link.

In this demo, we are not using a CEDARLING_POLICY_STORE_URI property in the configuration because the GitHub CJAR file download link returns a cross-origin problem for the React App. In a React App, we have server-side routes to fetch the CJAR file from GitHub.

Check out Cedarling Documents for more ways to fetch and initialize Cedarling with CJAR.

Step 3: Create Authorization Client

This class implements a singleton pattern for managing Cedar authorization using WebAssembly (WASM), providing a centralized way to initialize the Cedar policy engine and perform authorization checks. It wraps the @janssenproject/cedarling_wasm module to handle policy evaluation through a single, reusable instance that can be accessed throughout the application.

class CedarlingClient {
  private static instance: CedarlingClient;
  private cedarling: Cedarling | null = null;
  private initialized = false;
  private wasmModule: any = null;

  private constructor() {}

  static getInstance(): CedarlingClient {
    if (!CedarlingClient.instance) {
      CedarlingClient.instance = new CedarlingClient();
    }
    return CedarlingClient.instance;
  }

  async initialize(policyStoreConfig: any): Promise<void> {
    if (!this.initialized) {
      this.wasmModule = await initWasm();
      // Fetch CJAR zip file
      const responseArrayBuffer = await fetchPolicyStoreZip();

      // Initialize Cedarling using init_from_archive_bytes
      const bytes = new Uint8Array(responseArrayBuffer);
      this.cedarling = (await init_from_archive_bytes(
        policyStoreConfig,
        bytes,
      )) as unknown as Cedarling;
      console.log("WASM initialized", this.cedarling);

      this.initialized = true;
    }
  }

  async authorize(request: any): Promise<AuthorizeResult> {
    if (!this.cedarling || !this.initialized) {
      throw new Error("Cedarling not initialized");
    }
    try {
      const result = await this.cedarling.authorize(request);
      return result;
    } catch (error) {
      console.error("Error during authorization:", error);
      throw error;
    }
  }
}

export const cedarlingClient = CedarlingClient.getInstance();

Step 4: Initialize Cedarling

We are globally initializing the Cedarling object. You can add it to your app’s startup files. Like in the ViteJS case, you can add it in App.tsx, and in the Next JS case, you can add it in src/layout.tsx.

useEffect(() => {
  cedarlingClient.initialize(cedarlingBootstrapProperties).catch(console.error);
}, []);

Step 5: React Hook for Authorization

This Reack hook provides authorization functionality using the Cedarling client, with the ability to enforce authorization checks when enabled through environment variables. The hook manages loading and error states while processing authorization requests, and returns a boolean or AuthorizeResult indicating whether the authorization was successful.

import { useCallback, useState } from "react";
import { cedarlingClient } from "./cedarlingUtils";
import { parseJwt } from "./parseJWT";
import { AuthorizeResult } from "@janssenproject/cedarling_wasm";

export function useCedarling() {
  const [isLoading, setIsLoading] = useState(false);
  const [error, setError] = useState<Error | null>(null);
  const authorize = useCallback(
    async (request: any): Promise<AuthorizeResult> => {
      setIsLoading(true);
      setError(null);
      try {
        // debug logs
        console.log("Enforcing Cedarling authorization");
        console.log("Request: ", request);
        console.log("Decoded idToken: ", parseJwt(request.tokens.id_token as string));
        console.log("Decoded accessToken: ",parseJwt(request.tokens.access_token as string));
        // userinfo token case
        // console.log('Decoded userInfo: ', parseJwt(request.tokens.userinfo_token as string))
        return await cedarlingClient.authorize(request);
      } catch (err) {
        const error = err instanceof Error ? err : new Error("Authorization failed");
        setError(error);
        throw error;
      } finally {
        setIsLoading(false);
      }
    },
    []
  );
  return { authorize, isLoading, error };
}

Step 6: Protect Actions and Components

Use React Hooks to protect actions and components. Your ID Token should have a role claim. It can be one value, like role: admin or an array, like role: ["admin", "manager"]both are valid. Check the Cedarling entities document for more details about role entity creation and usage.

Below is an example of the Task React Page:

import { useCedarling } from "@/factories/useCedarling";
import { AuthorizeResult } from "@janssenproject/cedarling_wasm";

export default function TasksPage() {
  const { authorize } = useCedarling();

  const cedarlingRequest = async (action: string) => {
    const idToken = "<your_id_token>";
    const accessToken = "<your_access_token>";

    const request = {
      tokens: {
        access_token: accessToken,
        id_token: idToken,
      },
      action: `Jans::Action::"${action}"`,
      resource: {
        type: "Jans::Task",
        id: "App",
        app_id: "App",
        name: "App",
        url: {
          host: "jans.test",
          path: "/",
          protocol: "http",
        },
      },
      context: {},
    };

    const result: AuthorizeResult = await authorize(request);
    return result;
  };

  const handleAdd = async () => {
    try {
      const result = await cedarlingRequest("Add");
      console.log(result);
      if (result.decision) {
        alert("Successfully added!");
      } else {
        alert("You are not allowed to add new Task!");
      }
    } catch (e) {
      alert("You are not allowed to add new Task!");
      console.log(e);
    }
  };
}

<button className="btn btn-primary mb-3" onClick={handleAdd}>
  <FaPlus className="me-2" />
  Add Task
</button>;

In the above example, there are 2 things:

• First, we make a function cedarlingRequest which accepts an action and helps us to make an authorization request to the Cedarling WASM with Access Token and ID Token. Your ID Token should have a Role claim, and if you don't have a role, then you need to change the policy, which will act like ABAC.
• Second, we have the handleAdd function, which helps us to request and check the authorization for the Add operation. In response, it returns a result where we get which policy is responsible for authorization, the timestamp, and the decision. Below is an example of the result. Use result.decision to authorize the request and show/hide elements.

{
  "id": "0196118a-ce6e-74c8-9c25-5da154aa8b90",
  "request_id": "0196118a-ce6a-7653-b64c-e5fb9722c1d1",
  "timestamp": "2025-04-08T00:07:11.662Z",
  "log_kind": "Decision",
  "policystore_id": "87d2c8877a2455a16149c55d956565e1d18ac81ba10a",
  "policystore_version": "undefined",
  "principal": ["User"],
  "User": {},
  "diagnostics": {
    "reason": [
      {
        "id": "6b51f8244fe1fc3b273733f9d93def7f07080367fbc1",
        "description": "ManagerCanAddUpdateViewTask"
      }
    ],
    "errors": []
  },
  "action": "Jans::Action::\"Add\"",
  "resource": "Jans::Task::\"App\"",
  "decision": "ALLOW",
  "tokens": {
    "id_token": {
      "jti": "J4TB2NsgTZOBtPTYTzHtmg"
    },
    "access_token": {
      "jti": "hNhnQW18RA2AIOh5ihOfTQ"
    }
  },
  "decision_time_micro_sec": 3000,
  "pdp_id": "bbcf165b-1b7b-452a-af46-b9dbf3ae7cf0",
  "application_id": "AgamaLab"
}

Like we handled the Add action, you can handle other actions and show hide components.

Step 7: Protecting UI Components

This ProtectedSection component is a React wrapper that controls access to UI components based on user authorization. It takes a resource ID and optional action ID, checks if the user has permission to access that resource using Cedar authorization, and either displays the protected content (children) if authorized or shows a fallback component (typically an error message) if access is denied.

import { useCedarling } from "@/factories/useCedarling";
import React from "react";

export function ProtectedSection({
  accessToken,
  idToken,
  actionId,
  resourceId,
  children,
  fallback = (
    <div>
      <div>Access Denied</div>
      {`Please contact your administrator.`}
    </div>
  ),
  loadingFallback = <div>Loading...</div>,
}: ProtectedSectionProps) {
  const { authorize, isLoading, error } = useCedarling();
  const [isAuthorized, setIsAuthorized] = React.useState(false);

  React.useEffect(() => {
    const checkAuthorization = async () => {
      const request = {
        tokens: {
          access_token: accessToken,
          id_token: idToken,
        },
        action: `Jans::Action::"${actionId}"`,
        resource: { type: "Jans::Task", id: resourceId, name: resourceId },
        context: {},
      };
      try {
        const result = await authorize(request);
        setIsAuthorized(result.decision);
      } catch (err: any) {
        setIsAuthorized(false);
      }
    };
    checkAuthorization();
  }, [accessToken, idToken, authorize, actionId, resourceId]);

  if (isLoading) return <>{loadingFallback}</>;
  if (error) return <div>Error: {error?.message}</div>;
  if (!isAuthorized) return <>{fallback}</>;
  return <>{children}</>;
}

Use ProtectedSection to protect any elements. Your ID Token should have a role claim. It can be one value, like role: admin or an array like role: ["admin", "manager", "member"]both are valid. Check the Cedarling entities document for more details about role entity creation and usage.

<ProtectedSection
  accessToken={accessToken}
  idToken={idToken}
  resourceId="App"
  actionId="Delete"
>
  <h1>Welcome, permission granted!</h1>
</ProtectedSection>

Test Cases

Admin Authorization

Let’s log in as an admin user and check the authorization. As per the above authorization policies, admins can access any resource. As you can see in the video below, Sachin is an admin user, and he has the admin role in ID Token.

🟢 Admin can Add a task

🟢 Admin can Update a task

🟢 Admin can Delete a task

🟢 Admin can view a task

Manager Authorization

Log in with a manager role user and check the authorization. As per our authorization policies, a manager cannot perform the `Delete` action.

🟢 Manager can Add a task

🟢 Manager can Update a task

🟢 Manager can view a task

🔴 Manager cannot Delete a task

Member Authorization

Log in with a member role user and check the authorization. As per our authorization policies, members can only `view` tasks.

🟢 Member can view a task

🔴 Member cannot Add a task

🔴 Member cannot Update a task

🔴 Member cannot view a task

Key Takeaways

• The Cedarling is easy to integrate natively in a React Application and offers policy expression, from simple RBAC policies to complex contextual policies.
• The Cedarling makes it easy to protect components and limit user access. Use ProtectedSection to restrict UI elements.
• Policy authoring is centralized via the Agama Lab developer portal.

For a complete implementation, reference the:

• Next JS Demo project
• Policy Store

Using Cedar to Modernize Authz in a React Frontend was originally published in Janssen Project Feed on Medium, where people are continuing the conversation by highlighting and responding to this story.

This guide demonstrates how to build a React application using a new approach to security: Token-Based Access Control, where developers authorize capabilities by presenting a bundle of JWT tokens to a policy engine, in this case, the Janssen Project Cedarling. The Cedar policy syntax is very expressive. A developer can express policies based on a person’s role or group membership. And that’s just what we will do here… use TBAC to implement RBAC. That may sound confusing, but carry on further for more details on why this makes sense!

We’ll walk through setting up the integration with a practical example involving multiple roles and conditional policies. You’ll learn how to:

• Define the authorization schema
• Configure access policies
• Evaluate authorization requests
• Implement Cedarling’s streamlined authorization in React with minimal code

Sample Application: Task Management

For demo, we’re going to use role-based access control (or “RBAC”) to develop a sample application that performs Task Management. It’s a very simple version of Trello! For example, we will also support federated authentication via a standard OpenID Connect Provider. After authentication, Cedarling plays a role in authorization, which will take roles from the ID Token to authorize a user. Below are the roles which perform will perform the following actions and access Task resources. If a user has enough permission, then allow the action; otherwise, deny.

For our demonstration, we’ll implement Role-Based Access Control (RBAC) to build a sample Task Management application — essentially a simplified version of Trello. The application will feature:

1. Federated Authentication: Users will authenticate through a standard OpenID Connect Provider
2. Cedarling Authorization: After authentication, Cedarling will handle authorization by:

• Extracting user roles from the ID Token
• Evaluating permissions against Task resources
• Allowing or denying actions based on the user’s role

The system will enforce these access controls when users attempt to perform actions, only permitting operations when they have sufficient permissions.

• Principals: Users with roles like Admin, Manager, and Member.
• Actions: Add, Update, Delete, and View
• Resources: Task

Roles and Permissions:

1. Admin

• Can perform any operation

2. Manager

• Can perform Add, Update, View
• Cannot perform Delete

3. Member

• Can perform only View

Prerequisite

1. OpenID Connect Server: Use any compliant provider like Janssen, Google, or Okta.
2. React Application: Use any framework like Next.js or Vite.js to create a Fresh React App.

Setting Up Policies

We’ll use the Agama-Lab Policy Designer to create and manage our authorization policies. For more information, see the Agama Lab Documentation.

Step 1: Create Policy Store

1. Sign in to Agama Lab with your GitHub ID.
2. Open the Policy Designer section.
3. Select the repository where you want to save your policies.
4. Create a new policy store named JanssenReactCedarlingRBAC.

Step 2: Define Schema

1. Open the Manage Policy Store section by clicking the arrow link button on the store list.
2. Create an Entity called Task, which is our sample Resource.

3. Once you add the Resource, you must associate an action with it. Configure actions (Add, Update, Delete, View):

• Set Principal: User
• Set Resources: Task

Step 3: Create Policies

1. Go to Manage Policy Store > Policies > Add Policy > Text Editor.
2. Copy policies one by one, add to the text editor, and save.

• Admin Policy (full access):

@id("AdminPerformAnyOperationOnResource")
permit(
  principal in Jans::Role::"admin",
  action,
  resource
);

• Manager Policy (restricted access):

@id("ManagerCanAddUpdateViewTask")
permit (
  principal in Jans::Role::"manager",
  action in [Jans::Action::"Add",
  Jans::Action::"Update",
  Jans::Action::"View"],
  resource is Jans::Task
);

• Member Policy (view only):

@id("MemberCanOnlyViewTask")
permit (
  principal in Jans::Role::"member",
  action in [Jans::Action::"View"],
  resource is Jans::Task
);

Setting up a React Application

Step 1: Install the Cedarling WASM

npm install @janssenproject/cedarling_wasm

For Vite.js, update vite.config.ts:

import { defineConfig } from "vite";

export default defineConfig({
  optimizeDeps: {
    exclude: ["@janssenproject/cedarling_wasm"],
  },
});

Step 2: Configure the Cedarling

Initialize with these properties:

export const cedarlingBootstrapProperties = {
  CEDARLING_APPLICATION_NAME: "TaskManager",
  CEDARLING_POLICY_STORE_URI: "<your_policy_store_URI>",
  CEDARLING_USER_AUTHZ: "enabled",
  CEDARLING_LOG_TYPE: "std_out",
  CEDARLING_LOG_LEVEL: "INFO",
  CEDARLING_LOG_TTL: 120,
  CEDARLING_PRINCIPAL_BOOLEAN_OPERATION: {
    "===": [{ var: "Jans::User" }, "ALLOW"],
  },
};

• CEDARLING_POLICY_STORE_URI: URL of your policy store (from Agama-Lab). In the policy store list, use the link button to copy the policy store URI.

Step 3: Create Authorization Client

This class implements a singleton pattern for managing Cedar authorization using WebAssembly (WASM), providing a centralized way to initialize the Cedar policy engine and perform authorization checks. It wraps the @janssenproject/cedarling_wasm module to handle policy evaluation through a single, reusable instance that can be accessed throughout the application.

class CedarlingClient {
  private static instance: CedarlingClient;
  private cedarling: Cedarling | null = null;
  private initialized = false;
  private wasmModule: any = null;

  private constructor() {}

  static getInstance(): CedarlingClient {
    if (!CedarlingClient.instance) {
      CedarlingClient.instance = new CedarlingClient();
    }
    return CedarlingClient.instance;
  }

  async initialize(policyStoreConfig: any): Promise<void> {
    if (!this.initialized) {
      this.wasmModule = await initWasm();
      console.log("WASM initialized", this.wasmModule);
      this.cedarling = (await init(policyStoreConfig)) as unknown as Cedarling;
      this.initialized = true;
    }
  }

  async authorize(request: any): Promise<AuthorizeResult> {
    if (!this.cedarling || !this.initialized) {
      throw new Error("Cedarling not initialized");
    }
    try {
      const result = await this.cedarling.authorize(request);
      return result;
    } catch (error) {
      console.error("Error during authorization:", error);
      throw error;
    }
  }
}

export const cedarlingClient = CedarlingClient.getInstance();

Step 4: Initialize Cedarling

We are globally initializing the Cedarling object. You can add it to your app’s startup files. Like in the ViteJS case, you can add it in App.tsx, and in the Next JS case, you can add it in src/layout.tsx.

useEffect(() => {
  cedarlingClient.initialize(cedarlingBootstrapProperties).catch(console.error);
}, []);

Step 5: React Hook for Authorization

This Reack hook provides authorization functionality using the Cedarling client, with the ability to enforce authorization checks when enabled through environment variables. The hook manages loading and error states while processing authorization requests, and returns a boolean or AuthorizeResult indicating whether the authorization was successful.

import { useCallback, useState } from "react";
import { cedarlingClient } from "./cedarlingUtils";
import { parseJwt } from "./parseJWT";
import { AuthorizeResult } from "@janssenproject/cedarling_wasm";

export function useCedarling() {
  const [isLoading, setIsLoading] = useState(false);
  const [error, setError] = useState<Error | null>(null);
  const authorize = useCallback(
    async (request: any): Promise<AuthorizeResult> => {
      setIsLoading(true);
      setError(null);
      try {
        // debug logs
        console.log("Enforcing Cedarling authorization");
        console.log("Request: ", request);
        console.log("Decoded idToken: ", parseJwt(request.tokens.id_token as string));
        console.log("Decoded accessToken: ",parseJwt(request.tokens.access_token as string));
        // userinfo token case
        // console.log('Decoded userInfo: ', parseJwt(request.tokens.userinfo_token as string))
        return await cedarlingClient.authorize(request);
      } catch (err) {
        const error = err instanceof Error ? err : new Error("Authorization failed");
        setError(error);
        throw error;
      } finally {
        setIsLoading(false);
      }
    },
    []
  );
  return { authorize, isLoading, error };
}

Step 6: Protect Actions and Components

Use React Hooks to protect actions and components. Your ID Token should have a role claim. It can be one value, like role: admin or an array, like role: ["admin", "manager"]both are valid. Check the Cedarling entities document for more details about role entity creation and usage.

Below is an example of the Task React Page:

import { useCedarling } from "@/factories/useCedarling";
import { AuthorizeResult } from "@janssenproject/cedarling_wasm";

export default function TasksPage() {
  const { authorize } = useCedarling();

  const cedarlingRequest = async (action: string) => {
    const idToken = "<your_id_token>";
    const accessToken = "<your_access_token>";

    const request = {
      tokens: {
        access_token: accessToken,
        id_token: idToken,
      },
      action: `Jans::Action::"${action}"`,
      resource: {
        type: "Jans::Task",
        id: "App",
        app_id: "App",
        name: "App",
        url: {
          host: "jans.test",
          path: "/",
          protocol: "http",
        },
      },
      context: {},
    };

    const result: AuthorizeResult = await authorize(request);
    return result;
  };

  const handleAdd = async () => {
    try {
      const result = await cedarlingRequest("Add");
      console.log(result);
      if (result.decision) {
        alert("Successfully added!");
      } else {
        alert("You are not allowed to add new Task!");
      }
    } catch (e) {
      alert("You are not allowed to add new Task!");
      console.log(e);
    }
  };
}

<button className="btn btn-primary mb-3" onClick={handleAdd}>
  <FaPlus className="me-2" />
  Add Task
</button>;

In the above example, there are 2 things:

• First, we make a function cedarlingRequest which accepts an action and helps us to make an authorization request to the Cedarling WASM with Access Token and ID Token. Your ID Token should have a Role claim, and if you don't have a role, then you need to change the policy, which will act like ABAC.
• Second, we have the handleAdd function, which helps us to request and check the authorization for the Add operation. In response, it returns a result where we get which policy is responsible for authorization, timestamp, and decision. Below is an example of the result. Use result.decision to authorize the request and show/hide elements.

{
  "id": "0196118a-ce6e-74c8-9c25-5da154aa8b90",
  "request_id": "0196118a-ce6a-7653-b64c-e5fb9722c1d1",
  "timestamp": "2025-04-08T00:07:11.662Z",
  "log_kind": "Decision",
  "policystore_id": "87d2c8877a2455a16149c55d956565e1d18ac81ba10a",
  "policystore_version": "undefined",
  "principal": ["User"],
  "User": {},
  "diagnostics": {
    "reason": [
      {
        "id": "6b51f8244fe1fc3b273733f9d93def7f07080367fbc1",
        "description": "ManagerCanAddUpdateViewTask"
      }
    ],
    "errors": []
  },
  "action": "Jans::Action::\"Add\"",
  "resource": "Jans::Task::\"App\"",
  "decision": "ALLOW",
  "tokens": {
    "id_token": {
      "jti": "J4TB2NsgTZOBtPTYTzHtmg"
    },
    "access_token": {
      "jti": "hNhnQW18RA2AIOh5ihOfTQ"
    }
  },
  "decision_time_micro_sec": 3000,
  "pdp_id": "bbcf165b-1b7b-452a-af46-b9dbf3ae7cf0",
  "application_id": "AgamaLab"
}

Like we handled the Add action, you can handle other actions and show hide components.

Step 7: Protecting UI Components

This ProtectedSection component is a React wrapper that controls access to UI components based on user authorization. It takes a resource ID and optional action ID, checks if the user has permission to access that resource using Cedar authorization, and either displays the protected content (children) if authorized or shows a fallback component (typically an error message) if access is denied.

import { useCedarling } from "@/factories/useCedarling";
import React from "react";

export function ProtectedSection({
  accessToken,
  idToken,
  actionId,
  resourceId,
  children,
  fallback = (
    <div>
      <div>Access Denied</div>
      {`Please contact your administrator.`}
    </div>
  ),
  loadingFallback = <div>Loading...</div>,
}: ProtectedSectionProps) {
  const { authorize, isLoading, error } = useCedarling();
  const [isAuthorized, setIsAuthorized] = React.useState(false);

  React.useEffect(() => {
    const checkAuthorization = async () => {
      const request = {
        tokens: {
          access_token: accessToken,
          id_token: idToken,
        },
        action: `Jans::Action::"${actionId}"`,
        resource: { type: "Jans::Task", id: resourceId, name: resourceId },
        context: {},
      };
      try {
        const result = await authorize(request);
        setIsAuthorized(result.decision);
      } catch (err: any) {
        setIsAuthorized(false);
      }
    };
    checkAuthorization();
  }, [accessToken, idToken, authorize, actionId, resourceId]);

  if (isLoading) return <>{loadingFallback}</>;
  if (error) return <div>Error: {error?.message}</div>;
  if (!isAuthorized) return <>{fallback}</>;
  return <>{children}</>;
}

Use ProtectedSection to protect any elements. Your ID Token should have a role claim. It can be one value, like role: admin or an array like role: ["admin", "manager", "member"]both are valid. Check the Cedarling entities document for more details about role entity creation and usage.

<ProtectedSection
  accessToken={accessToken}
  idToken={idToken}
  resourceId="App"
  actionId="Delete"
>
  <h1>Welcome, permission granted!</h1>
</ProtectedSection>

Test Cases

Admin Authorization

Let’s log in as an admin user and check the authorization. As per the above authorization policies, admins can access any resource. As you can see in the video below, Sachin is an admin user, and he has the admin role in ID Token.

🟢 Admin can Add a task

🟢 Admin can Update a task

🟢 Admin can Delete a task

🟢 Admin can view a task

Manager Authorization

Log in with a manager role user and check the authorization. As per our authorization policies, a manager cannot perform the `Delete` action.

🟢 Manager can Add a task

🟢 Manager can Update a task

🟢 Manager can view a task

🔴 Manager cannot Delete a task

Member Authorization

Log in with a member role user and check the authorization. As per our authorization policies, members can only `view` tasks.

🟢 Member can view a task

🔴 Member cannot Add a task

🔴 Member cannot Update a task

🔴 Member cannot view a task

Key Takeaways

• The Janssen Cedarling provides fine-grained RBAC for React apps.
• Easy to protect components and limit user access. Use ProtectedSection to restrict UI elements.
• Policy management is centralized via Agama Lab.

For a complete implementation, reference the:

• Next JS Demo project
• Policy Store