Role-Based Access Control (RBAC)

The core mechanism where users are assigned to one or more predefined roles. A user inherits all the permissions associated with their assigned roles. For example, in an LLM platform:

• A Data Scientist role might have permission to read models in the registry and create new training jobs.
• A DevOps Engineer role might have permission to update inference endpoint configurations and delete old deployments.
• A Product Manager role might only have permission to read performance dashboards and cost reports. This separation of duties ensures users only have the access necessary for their job function.

Permissions, which define a specific action on a resource, are assigned directly to roles, not users. A permission is typically expressed as a tuple: (resource, action, effect). For LLM infrastructure:

• Resource: models/llama-3-70b, /v1/completions endpoint, prompt-templates repository.
• Action: read, write, execute, delete, list.
• Effect: allow or deny. Example permissions for an ML Engineer role: allow models/* read, allow /deploy execute. This creates a clear, auditable policy layer.

A principle that allows roles to inherit permissions from other roles, creating a logical structure that simplifies management. A Senior ML Engineer role might inherit all permissions from the ML Engineer role and add extra permissions like models/* delete. This is often visualized as a directed acyclic graph (DAG). It reduces redundancy; instead of assigning the same set of permissions to multiple roles, you define a base role (e.g., viewer) and have specialized roles (e.g., editor, admin) inherit from it.

The system that enforces RBAC policies at runtime. When a user authenticates, their session is tagged with their assigned roles. Each API request to an LLM service (e.g., a request to the inference endpoint or model registry) is intercepted by a Policy Decision Point (PDP). The PDP evaluates the user's roles against the requested (resource, action) to make an allow or deny decision. This is often integrated via middleware in API gateways (like Kong, Envoy) or directly in the application logic.

An advanced principle that adds contextual conditions or constraints to permissions. A permission is only granted if specific dynamic conditions are met. Common constraints for LLM operations include:

• Temporal: Permission to execute a fine-tuning job only during off-peak hours (e.g., 8 PM - 6 AM).
• Resource-Based: Permission to read a model's weights only if the model's cost_center metadata matches the user's department.
• Location/IP-Based: Permission to access the model serving dashboard only from the corporate IP range. This enables fine-grained, attribute-based control within the RBAC framework.

The operational practice of regularly reviewing role assignments and permissions to ensure they remain correct and compliant—a process often called role reconciliation. This is critical in dynamic ML teams. Automated audits should answer:

• Which users have the admin role for the production inference cluster?
• Does the researcher role have unnecessary delete permissions on the prompt versioning system?
• Have any roles been assigned that violate segregation of duties (e.g., a single user with both deploy and audit roles)? Regular review mitigates permission creep and is a key part of AI governance.

Attribute-Based Access Control (ABAC) is a dynamic authorization model where access decisions are based on attributes of the user, resource, action, and environment. Unlike RBAC's static role assignments, ABAC uses policies that evaluate multiple attributes in real-time.

• Key Components: Policies are defined using rules like IF user.department == 'Engineering' AND resource.classification == 'Internal' AND time.now < 18:00 THEN ALLOW.
• Granularity: Enables fine-grained, context-aware permissions (e.g., "Engineers can access project files only during business hours from corporate IP ranges").
• Standard: Often implemented using the eXtensible Access Control Markup Language (XACML) policy language and a Policy Decision Point (PDP).
• Use Case: Ideal for highly regulated environments or dynamic resources where access rules are complex and depend on multiple contextual factors.

These are the core components of a centralized authorization architecture, often used with ABAC but applicable to RBAC systems.

• Policy Decision Point (PDP): The brain of the system. It evaluates access requests against a set of policies (e.g., RBAC role mappings or ABAC rules) and returns a Permit or Deny decision.
• Policy Enforcement Point (PEP): The gatekeeper. It intercepts access requests (e.g., an API call), forwards them to the PDP, and enforces the returned decision by allowing or blocking the request. The PEP is integrated directly into the application or API gateway.
• Flow: User -> PEP -> (Request Context) -> PDP -> (Decision) -> PEP -> Resource.
• Separation of Concerns: This pattern decouples policy logic (PDP) from application code, enabling centralized policy management and audit.

Identity and Access Management (IAM) is the overarching discipline and set of tools for managing digital identities and their permissions across systems. RBAC is a specific authorization model within a broader IAM framework.

• Core Functions:
  • Identity Lifecycle Management: Provisioning, updating, and deprovisioning user accounts (Joiner-Mover-Leaver processes).
  • Authentication (AuthN): Verifying a user's identity (e.g., via passwords, SSO, MFA).
  • Authorization (AuthZ): Determining what an authenticated user is allowed to do (this is where RBAC operates).
• Systems: Enterprise IAM includes tools like Okta, Azure AD, and Ping Identity, which manage user directories, single sign-on (SSO), and often include RBAC capabilities.
• Principle of Least Privilege: A key IAM tenet that RBAC helps implement by assigning users only the permissions necessary for their role.

Role Engineering is the systematic process of designing, defining, and implementing roles within an RBAC system. It is the most critical and complex phase of RBAC deployment, as poorly designed roles lead to permission bloat or excessive administrative overhead.

• Methods:
  • Top-Down: Roles are designed based on business processes and organizational structure (e.g., "Financial Analyst," "Release Manager").
  • Bottom-Up: Roles are derived by analyzing existing user-permission assignments to find common patterns.
• Key Concepts:
  • Role Hierarchy: Structuring roles in a parent-child relationship where child roles inherit permissions from parents.
  • Separation of Duties (SoD): Defining conflicting permissions that should not be assigned to the same role (e.g., "create invoice" and "approve payment") to prevent fraud.
• Challenge: Avoiding role explosion—the creation of too many granular roles, which makes the system unmanageable.

JSON Web Tokens (JWT) are a compact, URL-safe means of representing claims to be transferred between parties, commonly used to convey authentication and authorization information in API-based systems, often in conjunction with RBAC concepts.

• Structure: A JWT consists of a Header, Payload, and Signature. The Payload contains claims about the user.
• RBAC Integration: The JWT payload often includes a roles or groups claim listing the user's assigned roles (e.g., "roles": ["editor", "viewer"]). The API's PEP decodes the JWT and checks the roles against required permissions.
• OAuth 2.0 Scopes: In OAuth 2.0, scopes are used to limit an application's access to a user's resources. While similar, scopes are typically assigned to applications (clients), whereas RBAC roles are assigned to users. They can be used together: a user (with a role) grants an application (with scopes) limited access.
• Example Flow: User authenticates, receives a JWT with roles: ['llm-deployer']. User calls a model serving API. The PEP validates the JWT and checks if the llm-deployer role has permission for the POST /deploy endpoint.