Scribd
Upload
15 views6 pages

Authorization

The document discusses designing a user authorization system for an organization using Permify. It involves defining roles and permissions based on a hierarchical structure, implementing dynamic roles and attribute-based access control (ABAC), and handling user transfers and changes in attributes.

Uploaded by

v dev
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
15 views6 pages

Authorization

The document discusses designing a user authorization system for an organization using Permify. It involves defining roles and permissions based on a hierarchical structure, implementing dynamic roles and attribute-based access control (ABAC), and handling user transfers and changes in attributes.

Uploaded by

v dev
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 6

Designing a user authorization system for an organization like NHAI using Permify requires a thoughtful

approach to capture the hierarchical structure, dynamic role assignments, and attribute-based access
control (ABAC). Permify allows for the implementation of a flexible and granular access control system
using roles, permissions, and attributes.

### Step 1: Understanding the Requirements

- **Organization:** NHAI.
- **Hierarchical Designations:** CGM, DGM, Manager.
- **Features:**
- Static roles assigned to a post.
- Special circumstances allow a single person to inherit permissions of other roles, regardless of
hierarchy.
- Project access and other data access based on attributes like assigned project, office location, etc.
- Upon transfer, an employee gets assigned different office, project, etc.
- Higher post inherits all functionalities of lower posts.

### Step 2: Define Roles and Permissions

First, define the roles according to the hierarchical structure:

1. **CGM (Chief General Manager)**


2. **DGM (Deputy General Manager)**
3. **Manager**

Each role will have specific permissions, plus the permissions of the roles below it in the hierarchy.
Permissions can include actions like `view_project`, `edit_project`, `assign_project`, etc.

### Step 3: Implementing Hierarchical and Dynamic Roles

- **Static Role Assignment:** Each designation (CGM, DGM, Manager) is a role with predefined
permissions.
- **Dynamic Role Permissions:** For special circumstances where a person needs permissions outside
their current role, you can create temporary roles or add permissions directly to the user for a specific
timeframe or under specific conditions.

### Step 4: Attribute-Based Access Control (ABAC)

Implement ABAC to manage access based on attributes such as `assigned_project`, `office_location`, etc.
This involves:

- **Defining Attributes:** These are the properties based on which access control decisions are made. For
example, `office_location` can be an attribute that determines access to certain resources.
- **Assigning Attributes to Users and Resources:** Each user and resource should have relevant
attributes assigned. For example, a user might have `assigned_project: ProjectA` and `office_location:
Location1`.
- **Creating Policies:** Define policies that use these attributes to grant or deny access. For example, a
policy could state that only users with `office_location: Location1` can access `ResourceX`.

### Step 5: Handling Transfers

When a person gets transferred, update their attributes (`office_location`, `assigned_project`, etc.)
accordingly. The ABAC policies will automatically adjust their access based on the new attributes.

### Step 6: Implementing in Permify

Given the dynamic and complex nature of the requirements, here is a simplified example of how to start
implementing this model in Permify:

1. **Define Roles and Permissions:**


- Use the Permify dashboard or API to create roles (CGM, DGM, Manager) and define their
permissions.

2. **Implement ABAC:**
- Define attributes and create policies using Permify's policy language or GUI.
3. **User and Role Management:**
- When assigning a user to a role or updating their attributes (e.g., due to a transfer), use Permify's API
to update their profile and roles accordingly.

4. **Dynamic Permissions:**
- For special cases, dynamically assign additional permissions or roles to a user temporarily, utilizing
Permify's flexible role and permission management system.

### Conclusion

This model provides a foundation for building a comprehensive user authorization system with Permify
for NHAI. It incorporates hierarchical roles, dynamic permissions adjustments, and ABAC for granular
access control. Since organization-specific requirements can be complex, further customization and
refinement will likely be necessary.

Based on the documentation provided, we can design a Permify schema to model the user authorization
system for the NHAI organization with hierarchical designations, role assignments, and attribute-based
access control (ABAC). Here's an example schema:

```
entity user {}

entity designation {
relation member @user
action view_self = member
}

entity codeProject {
relation assigned_users @user @designation#member
attribute location string
action view_project = assigned_users
action edit_project = assigned_users or parent.admin
}

entity office {
relation admin @designation#member
relation member @designation#member
attribute location string
action view_office = member or admin
action manage_office = admin
}

entity organization {
relation admin @user
relation cgm @designation
relation dgm @designation
relation manager @designation

action assign_role = admin


action override_role = admin
action create_project = cgm or dgm or manager
action delete_project = admin or cgm

permission cgm_permissions = cgm


permission dgm_permissions = dgm or cgm_permissions
permission manager_permissions = manager or dgm_permissions
}
```

Explanation:

1. `user` entity represents the users in the system.


2. `designation` entity represents the different hierarchical designations like CGM, DGM, and Manager.
The `member` relation associates users with their respective designations. The `view_self` action allows
members to view their own designation.
3. `codeProject` entity represents the projects. The `assigned_users` relation associates users with their
assigned projects based on their designation. The `location` attribute represents the location of the project.
The `view_project` action allows assigned users to view the project details, while the `edit_project` action
allows assigned users or admins of the parent organization to edit the project details.
4. `office` entity represents the offices. The `admin` relation associates admins (based on designation)
with the office, and the `member` relation associates members (based on designation) with the office. The
`location` attribute represents the location of the office. The `view_office` action allows members and
admins to view the office details, while the `manage_office` action allows admins to manage the office.
5. `organization` entity represents the NHAI organization. The `admin` relation associates users with the
admin role. The `cgm`, `dgm`, and `manager` relations associate designations with their respective roles
within the organization. The `assign_role` action allows admins to assign roles to users. The
`override_role` action allows admins to override roles and grant permissions to users outside of their
designated roles. The `create_project` action allows CGMs, DGMs, and Managers to create projects,
while the `delete_project` action allows admins and CGMs to delete projects. The `cgm_permissions`,
`dgm_permissions`, and `manager_permissions` permissions define the inherited permissions for each
designation based on the hierarchical structure.

With this schema, you can model the hierarchical designations, role assignments, project and office access
based on location and assigned users, and the ability to override roles in special circumstances. The
ABAC approach using attributes like `location` allows for contextual access control based on the user's
project or office assignment.
Note: This is a high-level example, and you may need to adjust or extend the schema based on your
specific requirements and edge cases.

You might also like