diff --git a/docs/documentation/platform/access-controls/attribute-based-access-controls.mdx b/docs/documentation/platform/access-controls/attribute-based-access-controls.mdx
index 99c49c63ad..bf708d395b 100644
--- a/docs/documentation/platform/access-controls/attribute-based-access-controls.mdx
+++ b/docs/documentation/platform/access-controls/attribute-based-access-controls.mdx
@@ -3,10 +3,10 @@ title: "Attribute-based Access Controls"
description: "Learn how to use ABAC to manage permissions based on identity attributes."
---
-Infisical's Attribute-based Access Controls (ABAC) allow for dynamic, attribute-driven permissions for both user and machine identities.
+Infisical's Attribute-based Access Controls (ABAC) allow for dynamic, attribute-driven permissions for both user and machine identities.
ABAC policies use metadata attributes—stored as key-value pairs on identities—to enforce fine-grained permissions that are context aware.
-In ABAC, access controls are defined using metadata attributes, such as location or department, which can be set directly on user or machine identities.
+In ABAC, access controls are defined using metadata attributes, such as location or department, which can be set directly on user or machine identities.
During policy execution, these attributes are evaluated, and determine whether said actor can access the requested resource or perform the requested operation.
## Project-level Permissions
@@ -18,24 +18,25 @@ Attribute-based access controls are currently available for polices defined on p
-
- 
-
-
- 
-
-
- 
-
+
+
+
+
+
+
+
+
+
- For organizations using SAML for login, Infisical automatically maps metadata attributes from SAML assertions to user identities.
- This makes it easy to create policies that dynamically adapt based on the SAML user’s attributes.
+ For organizations using SAML for login, Infisical automatically maps
+ metadata attributes from SAML assertions to user identities. This makes it
+ easy to create policies that dynamically adapt based on the SAML user’s
+ attributes.
-
## Defining ABAC Policies
@@ -49,6 +50,22 @@ The following attributes are available within project permissions:
During policy execution, these placeholders are replaced by their actual values prior to evaluation.
+## ABAC Policies From Authentication
+
+ABAC policies can also be defined based on your identity authentication. This means you can design your authentication process using metadata provided by an external authentication provider.
+
+1. Navigate to the identity authentication table and select the Advanced section.
+2. Map the values to be included in the permission authentication key, and assign the corresponding values from the external authentication provider's data.
+3. After logging in, your access token will contain these values, and the permissions will reflect them as well.
+
+
+
+ Currently, only OIDC authentication is supported.
+
+### OIDC Authentication
+
+- **OIDC Bound Claims**: `{{ identity.auth.oidc.claims. }}`
+
### Example Use Case
#### Location-based Access Control
@@ -58,8 +75,10 @@ You could assign a `location` attribute to each user (e.g., `identity.metadata.l
You could then structure your folders to align with this attribute and define permissions accordingly.
For example, a policy might restrict access to folders matching the user's location attribute in the following pattern:
+
```
/appA/{{ identity.metadata.location }}
```
+
Using this structure, users can only access folders that correspond to their configured `location` attribute.
Consequently, if a users attribute changes due to relocation, no policies need to be changed to gain access to the folders associated with their new location.
diff --git a/docs/images/platform/access-controls/abac-policies-by-auth.png b/docs/images/platform/access-controls/abac-policies-by-auth.png
new file mode 100644
index 0000000000..5b80be7890
Binary files /dev/null and b/docs/images/platform/access-controls/abac-policies-by-auth.png differ