Skip to main content
Please note the difference between roles and permissions. A role is a grouping of permissions and is managed from the roles page. For detailed role permission matrices, see the Role Permission Details page.

Current Authorization Model

Apinizer’s authorization system is based on the asset category + action model. Each asset category groups components with similar functions, and specific actions are defined for each category.

Asset Categories

Apinizer has 12 different asset categories. Each category covers specific components and functions:

Actions

Five different actions are defined for each asset category:
  • View: Permission to view components
  • Manage: Permission to create, edit, and delete components. In auto-deploy categories, Manage permission also includes automatic deployment of changes to workers
  • Deploy/Undeploy: Permission to deploy and remove API Proxies and Proxy Groups to/from workers
  • Execute: Permission to run test operations
  • Export/Import: Permission to export and import components

Auto-Deploy Categories

Some asset categories have the auto-deploy feature. Users with MANAGE permission in these categories can automatically deploy their changes to workers. Categories with auto-deploy feature:
  • Global Settings: Global policy settings and predefined values
  • Connections: Connection configurations
  • Identity & Access Control: Identity management components (Credential, Certificate, Key, JWK)
  • Secrets & Certificates: Secret information and encrypted values

Asset Categories and Actions Relationship Table

The following table shows which actions each asset category supports. ✓ indicates supported actions, - indicates unsupported actions. Note: 🔵 indicates auto-deploy categories. In these categories, Manage permission also includes automatic deployment of changes to workers.

Permission Control Hierarchy

Permission control in Apinizer follows a specific hierarchy. System-level roles are higher than project-level roles.

System-Level Roles

System-level roles are valid system-wide and are assigned by System Admin:

System Admin (sysAdmin)

  • Admin Project: Can perform all operations (all categories, all actions)
  • Normal Projects:
    • Must be a project member and pass role-based permission control
    • Cannot perform operations if no permission (checked like a normal user)
    • Can perform operations if permission exists

Project Manager (sysProjectManager)

  • All Projects: Project Owner level permissions
  • Has all actions in all categories
  • Project membership check is not performed (automatically passes)

System Analyzer (sysAnalyzer)

  • In Admin Menu: View permission for Analytics & Reports, Monitoring, Audit & Application Logs categories (special case - no role required)
  • In Normal Projects: Role-based permission control required (subject to same rules as normal users)

Project-Level Roles

Project-level roles are assigned on a project basis and managed by the project owner. These roles provide authorization based on asset categories and actions.

Permission Control Process

  1. Project Membership Check: User must be a member of the project
  2. Role-Based Permission Check: User’s roles in the project are checked
  3. Category + Action Check: Permission is checked through each role’s assetPermissions list by category and action

Permission Control Flow

The following diagram shows how a permission control request is processed:

Predefined Roles

Apinizer has seven predefined roles for project-level access. Each role is designed to perform specific tasks: For detailed permission matrices, see the Role Permission Details page.

System-Level Roles

System-level roles are valid system-wide and are assigned by System Admin: