ACL WIP

_data/toc.yml

@@ -6,10 +6,11 @@
       children:
         - title: Overview
           url: "docs/getting-started#rönd-overview"
-        - title: RBAC
-          url: "docs/getting-started#rönd-and-rbac"
         - title: Capabilities
           url: "docs/getting-started#rönd-capabilities"
+        - title: Access Control System
+          url: "docs/getting-started#managing-access-control-system-with-rönd"
+
     - title: "Configuration"
       url: "docs/configuration"
       children:
@@ -38,5 +39,9 @@
           url: "docs/policy-integration#custom-built-ins"
         - title: RBAC Data Model
           url: "docs/policy-integration#rbac-data-model"
+        - title: ACL Data Model
+          url: "docs/policy-integration#acl-data-model"
+        - title: Custom Data Model
+          url: "docs/policy-integration#custom-permission-evaluation"
     - title: "Cheat Sheet"
       url: "docs/cheat-sheet"

_docs/getting-started.md

@@ -28,14 +28,49 @@ For further details on how to configure Rönd, check out the [configuration page
   content="Rönd can also be used in standalone mode. In this scenario, services must explicitly contact Rönd to perform authorization rule evaluation. Further information about this are available in the [configuration page](/docs/configuration)."
 %}
 
-## Rönd and RBAC
-
-In addition to simple request-based authorization rules, Rönd provides the means for implementing a full-fledged RBAC solution. Rönd uses MongoDB to store Roles and Bindings, and allows you to write policies on user roles permissions and bindings.
-
 ## Rönd capabilities
 
 Rönd evaluated policy can be used to perform three different actions:
 
 - Allow or block API invocations;
 - Generate queries to filter data (currently supported syntax is MongoDB);
 - Modify the response payload (only supported for JSON bodies).
+
+## Managing Access Control System with Rönd
+### RBAC
+
+Rönd provides the means for implementing a full-fledged RBAC solution. Rönd uses MongoDB to store Roles and Bindings, and allows you to write policies on user roles permissions and bindings. To start using RBAC see [the guide here](docs/policy-integration#rbac-data-model).
+
+### ACL
+Rönd provides the means for implementing a full-fledged ACL solution. Rönd uses MongoDB to store User, Groups and Permissions. Rönd allows you to write policies on user roles and permissions. To start using ACL see [the guide here](docs/policy-integration#acl-data-model).
+
+
+### ACL vs RBAC
+
+ALC (Access Control List) and RBAC (Role-Based Access Control) are two popular access control systems used in computer security to ensure that only authorized individuals have access to resources. Here's a comparison between ALC and RBAC:
+
+* Conceptual Difference: ALC is a permission-based access control system, which means it grants access based on a user's permission to access a particular resource. In contrast, RBAC is a role-based access control system, which means it grants access based on a user's role or job function within the organization.
+
+* Complexity: ALC is a simpler access control system as compared to RBAC, as it only focuses on granting permissions to users on a per-resource basis. RBAC, on the other hand, is more complex, as it involves assigning roles to users and mapping those roles to permissions.
+
+* Flexibility: ALC is less flexible compared to RBAC. As permissions are granted on a per-resource basis, it is challenging to manage large-scale systems with numerous resources and many users. In contrast, RBAC provides greater flexibility as it allows for the assignment of roles to users and the grouping of permissions based on job functions or departmental needs.
+
+* Scalability: ALC is not scalable to a large number of users and resources, as managing permissions for every resource can be challenging. In contrast, RBAC is designed to handle larger systems with multiple users and resources, as it groups users by their roles and permissions by job function.
+
+* Administration: ALC is more challenging to administer as permissions are managed on a per-resource basis. In contrast, RBAC is easier to administer as permissions are managed by roles, which can be assigned to groups of users.
+
+Overall, RBAC is a more sophisticated and flexible access control system, ideal for larger organizations with many resources and users. ALC is a simpler system, suited for smaller organizations with fewer resources and users.
+
+| Capability  | ACL | RBAC |
+|-------------|-----|------|
+| Simplicity  | ✅  |  ❌   |
+| Flexibility | ❌  | ✅   |
+| Scalability | ❌  | ✅   |
+| Administration | ✅  | ❌   |
+| -------------- |---- | ----- |
+
+### References
+* Wikipedia - [Role-based Access Control](https://en.wikipedia.org/wiki/Role-based_access_control)
+* Wikipedia - [Access Control List](https://en.wikipedia.org/wiki/Access-control_list)
+* Geeks For Geeks - [ACL](https://www.geeksforgeeks.org/access-lists-acl/)
+* Imperva - [RBAC](https://www.imperva.com/learn/data-security/role-based-access-control-rbac/)

_docs/policy-integration.md

@@ -436,6 +436,10 @@ This collection contains all the bindings between users or groups of users and a
       "roles": [
          "TLRoleId"
       ],
+      "permissions": [
+         "canDoStuff",
+         "canDoActions",
+      ],
       "resource": {
          "resourceId": "project1",
          "resourceType": "project"
@@ -455,3 +459,77 @@ has_read_permission {
    userRoles.permissions[_] == "can_read"
 }
 ```
+
+## ACL Data Model
+
+You can use a the [binding association collection](#bindings) to represent a ACL data model, in this case you could only use the following fields:
+
+- **bindingId** (string, required): **_unique_** id of the binding
+- **subject** (string array): list of user ids, _usually contains only one subject_
+- **permissions**: (strings) list of permissions or grants (i.e. `canRead`, `canWrite`, ....)
+- **resource**: (object) with properties `type` and `id`.
+
+```json
+[
+   {   
+      "bindingId": "bindingUniqueIdentifier",
+      "subjects": [
+         "bob"
+      ],
+      "permissions": [
+         "canDoStuff",
+         "canDoActions",
+      ],
+      "resource": {
+         "resourceId": "project1",
+         "resourceType": "project"
+      }
+   }
+]
+```
+
+### ACL Policies for permission evaluation
+
+Let's check, in the following example, if the user have the permission to read some data:  
+```rego
+package policies
+
+has_read_permission {
+   user := input.user
+   user.permissions[_] == "canRead"
+}
+
+has_read_permission_for_given_company {
+   companyId := input.request.query["companyId"][0]
+   user := input.user[_].resource == { resourceType: "company", resourceId: companyId }
+   user.permissions[_] == "canRead"
+}
+```
+
+## Custom permission evaluation
+
+If you have a csutom permission model, different from ACL or RBAC you can use the built-in functions [find_one](/docs/policy-integration#custom-built-ins) and [find_many](/docs/policy-integration#custom-built-ins) function
+
+For example if you have a model like this:
+``` json
+[
+   {
+      "userId": "user01",
+      "grants": [
+         "grantA",
+         "grantB"
+      ]
+   }
+]
+```
+
+you can use this query to check permissions:
+
+```rego
+package policies
+
+has_read_permission {
+   user := find_one("users", { "userId": input.user.id })
+   user.grants[_] == "grantB"
+}
+```