ZuploZuplo
LoginSign Up
  • Documentation
  • API Reference
Introduction
Getting Started
    Develop using the Portal
      1 - Setup Your Gateway2 - Rate Limiting3 - API Key Auth4 - Deploy5 - Dynamic Rate LimitingMCP - Quick start
    Develop Locally
      1 - Setup Your Gateway2 - Rate Limiting3 - API Key Auth
Concepts
Development
Policies
    Policy Catalog
    Authentication
    Authorization
      AuthZEN Authorization PolicyOkta FGA Authorization PolicyOpenFGA Authorization PolicyAxiomatics Authorization PolicyJWT Scope Validation PolicyAccess Control List PolicyRBAC Authorization PolicyGeo-location filtering PolicyIP Restriction Policy
    Security & Validation
    Metrics, Billing & Quotas
    Testing
    Request Modification
    Response Modification
    Upstream Authentication
    Archival
    GraphQL
    Other
    Guides
Handlers
API Keys
MCP Server
MCP Gateway
AI Gateway
Developer Portal
Monetization
Deploying & Source Control
Observability
Networking & Infrastructure
Account Management
Programming API
Build with AI
Zuplo CLI
Migration Guides
Platform LimitsSecuritySupportTrust & ComplianceChangelog
powered by Zudoku
Authorization

Access Control List Policy

Custom Policy Example

Zuplo is extensible, so we don't have a built-in policy for Access Control List, instead we've a template here that shows you how you can use your superpower (code) to achieve your goals. To learn more about custom policies see the documentation.

ACL policies can be built many ways depending on your requirements. This example shows how to perform an authorization check on a hard-coded list of users.

This policy could be extended to fetch data from external sources or even use an authorization service such as OpenFGA.

modules/my-policy.ts
import { HttpProblems, ZuploContext, ZuploRequest } from "@zuplo/runtime"; interface PolicyOptions { users: string[]; } export default async function ( request: ZuploRequest, context: ZuploContext, options: PolicyOptions, policyName: string, ) { // Check that an authenticated user is set // NOTE: This policy requires an authentication policy to run before if (!request.user) { context.log.error( "User isn't authenticated. A authorization policy must come before the ACL policy.", ); return HttpProblems.unauthorized(request, context); } // Check that the user has one of the allowed roles if (!options.users.includes(request.user.sub)) { context.log.error( `The user '${request.user.sub}' isn't authorized to perform this action.`, ); return HttpProblems.forbidden(request, context); } // If they made it here, they are authorized return request; }

Configuration

The example below shows how to configure a custom code policy in the 'policies.json' document that utilizes the above example policy code.

config/policies.json
{ "name": "my-acl-policy-inbound-policy", "policyType": "acl-policy-inbound", "handler": { "export": "default", "module": "$import(./modules/YOUR_MODULE)", "options": { "users": ["google|12345", "google|23456"] } } }

Policy Configuration

  • name <string> - The name of your policy instance. This is used as a reference in your routes.
  • policyType <string> - The identifier of the policy. This is used by the Zuplo UI. Value should be acl-policy-inbound.
  • handler.export <string> - The name of the exported type. Value should be default.
  • handler.module <string> - The module containing the policy. Value should be $import(./modules/YOUR_MODULE).
  • handler.options <object> - The options for this policy. See Policy Options below.

Policy Options

The options for this policy are specified below. All properties are optional unless specifically marked as required.

  • users (required) <string[]> - The list of users authorized to access the resource

Using the Policy

Read more about how policies work

Edit this page
Last modified on May 29, 2026
JWT Scope Validation PolicyRBAC Authorization Policy
On this page
  • Configuration
    • Policy Configuration
    • Policy Options
  • Using the Policy
TypeScript
JSON