Role-Based Access Control (RBAC) is the backbone of secure system design, offering a structured method to manage user permissions and reduce the risks associated with overprivileged access. For large enterprise systems, RBAC is essential to ensure compliance, maintain operational integrity, and enable fine-grained access control across multiple teams and projects. This becomes especially critical in environments requiring hierarchical and scalable access controls where managing roles directly impacts both security and productivity.

At Observo AI, we’ve gone a step further by implementing a Hierarchical RBAC (HRBAC) model, enabling organizations to efficiently manage complex resource hierarchies and role mappings for enterprise SSO integrations. In this blog, we will dive deep into how RBAC is implemented at Observo and how it can scale to meet the access control needs of large enterprises.

The Core of RBAC at Observo

Policy Structure
At Observo, RBAC policies are designed as tuples containing four key elements:

• Role Name: A unique identifier for roles like Admin, Viewer, or Editor.
• Organization: The organizational context, such as Acme, dev-ops, or infra.
• Actions: Permissions like Read, Write, Delete, or Create.
• Resource Path: A hierarchical URI-style path representing the resource hierarchy.

Example Policies:

• viewer, org1, read, /sites/site1/*: The Viewer role in org1 can read all resources under site1.
• editor, org1, write, /sites/site1/pipelines/pipeline1: The Editor role in org1 can modify pipeline1 under site1.
• admin, org1, delete, /sites/*: The Admin role in org1 has delete permissions across all sites.

Resource Path Hierarchy
Observo uses a structured hierarchy for resource paths, which supports both specificity and wildcards, simplifying policy management. Examples include:

• /sites/site1/*: All resources under site1.
• /sites/site1/pipelines/pipeline1: A specific resource under site1.

Hierarchical Resource Access

The HRBAC model introduced at Observo introduces cascading permissions where parent resource permissions automatically extend to child resources. This is particularly useful in scenarios where multiple nested resources (like pipelines, configurations, etc.) exist within an overarching resource (e.g., sites).

For instance, granting the "Site Manager" role read and write access to /sites/site1/* automatically apply these permissions to all child resources under site1, such as /sites/site1/pipelines/pipeline1. This reduces administrative overhead and ensures consistent permission application.

User and Role Management

User-Role Assignments

Users are assigned specific roles within organizations and can hold multiple roles across different sites. Additionally, a single role can be assigned to multiple users. For example:

• User1, admin, org1
• User1, viewer, org2

Predefined Roles
Observo offers predefined roles that simplify role assignment:

• Admin: Organization-wide access.
• Viewer: Read-only access to all resources within an organization.
• Site-admin: Admin access to a specific site, automatically created during site creation.

Role Creation Constraints

Admin roles must be associated with at least one user upon creation. This ensures that roles are never orphaned and always have initial users assigned.

Casbin for Policy Management

Observo leverages the Casbin Go Library for policy evaluation and enforcement. The Casbin model is customized to fit our HRBAC structure and supports various policy types and matchers.

Casbin Model Definition

‍

Example Policy Evaluation

• Policy: admin, /sites/site1/*, read, org1
• Request: Joe, /sites/site1/p1, read, org1
• Role Assignment: G = Joe, admin, org1

In this case, the policy is evaluated, and permission is granted based on the matching criteria.

Scaling Permissions to the DB Layer

• Gorm Adapter for Persistence
  Casbin policies are stored in a database table (casbin_rule) using the Gorm adapter, ensuring scalability and smooth integration. This approach enables efficient policy evaluation directly alongside system data, leveraging database optimizations for faster queries.
• Database-Level Enforcement
  Permissions are enforced in the database layer by translating gRPC requests into Casbin URIs and applying them as Gorm scopes to retrieve only the allowed resources, enhancing security and efficiency.

Scaling RBAC for Large Enterprises

Role Mapping for SSO Providers

To support large enterprises, Observo seamlessly integrates with external Single Sign-On (SSO) providers like Okta, enabling role mapping between external Identity Provider (IDP) groups and internal Observo roles. This eliminates the need to redefine roles within Observo for each user, simplifying the management of permissions for thousands of users.

Role Mapping Flow

1. Connect Your External IDP/SSO

Each IDP, such as Okta, provides an authentication token when a user logs in. This token typically contains a JSON structure that includes the user's roles and their associated group paths. These roles and groups define the access levels granted to the user within the IDP system.

For example, an Okta JWT token might look like this:

{

  "sub": "00u1abc12345",

  "name": "John Doe",

  "email": "john.doe@example.com",

  "roles": [

    "User",

    "Admin"

  ],

  "iss": "https://{your-okta-domain}.okta.com",

  "aud": "client-id",

  "exp": 1633032800,

  "iat": 1633029200

}

The roles array in this JWT token defines the roles assigned to the user. These roles are crucial for determining the permissions within Observo’s RBAC system.

2. Defining Role Mappings in Observo

Once the external IDP sends the authentication token, you can define how the roles within the IDP map to roles in Observo. In Observo, each role must already exist, or you can create them beforehand during the mapping process. The mapping is done by specifying a path in the IDP token, typically pointing to the roles or group structure as given as an example above.

For example, you may define the path as .roles in the token to directly link roles from the IDP to Observo roles.

Admin Interaction: Simplified Role Mapping

The role mapping process at Observo is designed to be intuitive and user-friendly. Admins can easily map external groups or roles to Observo roles via a streamlined UI. This interface allows admins to:

• View existing mappings: All role mappings that have been defined so far are clearly displayed for quick access.
• Create new mappings: New mappings can be added with ease, connecting external roles to internal Observo roles.

If any roles from the IDP are not explicitly mapped to roles in Observo, they will default to the "No Access" role. Additionally, Observo allows admins to define a default role for users who do not have an explicit mapping. This ensures that even if no specific role is assigned, users will still have a defined level of access.

4. Backend Processing: Group Mapping Table

All role mappings are stored in a Group Mapping Table. This table links external groups or roles to Observo roles and is associated with both the organization and the specific SSO provider used. This setup ensures that the role mappings are both scalable and flexible to accommodate large enterprise environments.

Authentication & Authorization Workflow

1. User Login and Token Issuance:
   
   • The user logs in through an external SSO provider (e.g., Okta), and an authentication token (JWT) is issued with the user's identity and roles (e.g., "roles": ["User", "Admin"]).
2. Token Evaluation & Role Mapping:
   
   • Observo evaluates the token and applies role mappings from the external IDP to Observo roles, using the Group Mapping Table.
   • If no mapping exists, the user is assigned a default role (e.g., "User").
3. Role Assignment:
   
   • The user is assigned the appropriate Observo roles based on the token or the default role if no match is found.
4. Context Population & RBAC Enforcement:
   
   • User context is populated with roles, organization, and resource scope. RBAC is enforced based on this context to control access.
5. Dynamic Role Updates:
   
   • Role mappings are periodically synchronized with the IDP to ensure real-time updates, using caching and eviction policies.

Conclusion

Observo’s hierarchical RBAC implementation provides a powerful, scalable solution for enterprises with complex access control needs. By incorporating role mapping at scale, hierarchical permissions, and database-level enforcement, Observo delivers secure, efficient, and flexible access management, making it adaptable to organizations of all sizes.

Try Observo AI for free with our sandbox.