> ## Documentation Index
> Fetch the complete documentation index at: https://docs.endorlabs.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Authorization policies
> Learn how to manage authorization policies in Endor Labs.
Authorization policies define the permissions provided to an identity authenticated by a supported identity provider when that identity meets specific rule criteria defined as attributes or claims about the identity.
Authorization policies must contain the following information:
* The [supported identity provider](/platform-administration/rbac/authentication-providers) through which a given identity comes from.
* The [role](/platform-administration/rbac/authorization-roles) provided to an identity.
* An optional expiration time for the policy.
* The rule criteria or claims required for an identity to access Endor Labs.
After setting up the authorization policy, you can [invite users to Endor Labs](/platform-administration/rbac/invitations).
## Set up authorization policies
To set up an authorization policy to your Endor Labs tenant:
1. Select **User menu** > **Settings** from the left sidebar.
2. Select **Access Control** > **Auth Policy**.
3. Select **Add Auth Policy**.
4. Select the identity provider for which you want to configure an authorization policy.
5. Select the role to be granted to a matching identity.
6. Select an expiration time for the authorization rule.
This may be either **No expiration**, **24 hours**, **72 hours**, **one week**, **two weeks**, **30 days**, **60 days**, or **90 days**.
7. Select the [claims](#claims) for which the authorization rule will provide access.
8. Select [**Add Permission Rule**](#permission-rules) to define granular permissions by specifying resource kinds and allowed methods.
9. Under **Advanced**, select a set of namespaces for which the authorization policy applies. If you choose to propagate this policy to all child namespaces, then the authorization policy will apply to any selected namespaces and their children.
10. Click **Add Auth Policy** to save your authorization policy.
After adding the authorization policy, a user with the corresponding authorization claims can sign in to Endor Labs with their configured permissions.
See [Invite users to Endor Labs](/platform-administration/rbac/invitations).
## Claims
Claims are key-value pairs from your identity provider's JWT or SAML token that Endor Labs evaluates when a user authenticates. Each claim has a:
* **Key**: the token attribute name
* **Value**: the expected attribute value
When an incoming token's attributes match all the claims in a policy, Endor Labs grants the policy's assigned role to that user.
When a policy contains multiple claims, all of them must match for the policy to apply. Claim values are case-sensitive.
The following are the claim keys available for each identity provider and what values to enter.
Use the `user` key with the user's platform username as the value. The username is the handle the user signs in with on GitHub or GitLab, not their display name or email address.
For example, to grant access to a GitHub user with the handle `jsmith`, set **Key** to `user` and **Value** to `jsmith`.
Use the `user` key to grant access to a specific Gmail address, or the `domain` key to grant access to all users in an email domain.
For example:
* To grant access to a single user, set **Key** to `user` and **Value** to `jsmith@example.com`.
* To grant access to everyone in a domain, set **Key** to `domain` and **Value** to `example.com`.
Using `domain` is useful for organizations where all employees share a corporate Google Workspace domain and you want to grant access to the whole group rather than individual users.
Use the `email` key with the principal email address of your workload's service account.
This is typically a service account address in the format `name@project-id.iam.gserviceaccount.com`.
Use the `user` key to restrict access to workflows running in a specific GitHub organization or repository. Set the value to the organization or repository in the format `org` or `org/repo`.
For example:
* To allow any workflow in the `acme` organization, set **Value** to `acme`.
* To restrict access to a specific repository, set **Value** to `acme/payments-service`.
This is commonly used to authenticate CI/CD pipelines to Endor Labs without storing credentials.
Use the `user` key with the full AWS ARN of the IAM role your machine uses to authenticate. For example, `arn:aws:iam::123456789012:role/endorlabs-scanner`.
The ARN must match exactly as it appears in your AWS IAM configuration.
Use the `email` key with the email address to which Endor Labs sends the authentication link. This is for users who sign in via a one-time link sent to their email address.
Azure authorization policies require three claim keys that together uniquely identify the application identity:
* `tid`: The Directory (tenant) ID of your Azure Active Directory tenant.
* `appid`: The Application (client) ID of the registered application in Azure.
* `oid`: The Object ID assigned to the application or managed identity in the tenant.
The following keys are optional and can be used to further narrow access:
* `az_jwt_sub`: The subject claim from the Azure JWT token. Use this to scope the policy to a specific identity within the application.
* `subscriptions`: The Azure subscription ID, to restrict access to workloads running under a specific subscription.
Use any key-value pair that your SAML or OIDC identity provider includes in its token. The key must match the claim attribute name exactly as it appears in the token.
For example, if your Okta OIDC token includes a `groups` claim, set **Key** to `groups` and **Value** to the group name you want to match. If your organization maps department information into a custom claim called `department`, you can use that to scope access to a specific team.
## Permission rules
Permission rules control what actions an authenticated identity can perform in Endor Labs.
Each rule has two parts:
* **Resource kind**: The type of object the rule applies to, such as `Project`, `Finding`, `AuthorizationPolicy`, or `ScanProfile`. Use `*` to apply the rule to all resource kinds.
* **Methods**: The operations allowed on that resource.
The following methods are available:
* **Read**: Use this to grant view-only access to a resource without allowing any modifications.
* **Create**: Use this to allow an identity to add new resources, such as creating projects or scan profiles.
* **Update**: Use this when an identity needs to edit resources it did not necessarily create, such as updating findings or policies.
* **Delete**: Assign this only when the identity explicitly needs to delete resources, as it cannot be undone.
* **All**: Use this when an identity needs full control over a resource type.
You can add multiple rules to a single policy to compose exactly the access level you need. For example, you could allow `Read` on all resources using `*`, then add a separate rule granting `Create` and `Update` on `Project` only, giving a CI service account the ability to run scans without broader write access.
## Search authorization policies
You can use the search functionality to find authorization policies based on specific criteria.
To search for authorization policies:
1. Select **User menu** > **Settings** > **Access Control**.
2. Select **Auth Policy**.
3. Use the search bar to find policies by:
* **Rule**: Search policies by any text or string patterns within the rule definitions.
* **Created By**: Search policies by the email address of the creator.
* **Namespaces**: Search policies associated with a specific namespace.
### Edit authorization policies
To edit an authorization policy:
1. Select **User menu** > **Settings** > **Access Control**.
2. Select **Auth Policy**.
3. Click the vertical three dots on the right side of the policy you want to edit and click **Edit Auth Policy**.
4. You can update the identity provider, permission, expiration time, claims of key and value, and namespaces the policy applies to.
5. Click **Propagate this policy to all child namespaces** to apply this policy to all child namespaces within the hierarchy.
6. Click **Update Auth Policy**.
### Delete authorization policies
To delete an authorization policy:
1. Select **User menu** > **Settings** from the left sidebar.
2. Select **Access Control** > **Auth Policy**.
3. Click the vertical three dots on the right side of the policy you want to delete and click **Delete Auth Policy**.
4. Click **Confirm** in **Delete Authorization Policy**.
### Grant support access
You can give the Endor Labs team read-only access to your namespaces for a limited time, allowing them to offer technical support and resolve issues.
You can revoke access and delete these policies at any time. See [delete authorization policy](#delete-authorization-policies) for more information.
To grant support access to your namespace:
1. Select **User menu** > **Settings** from the left sidebar.
2. Select **Access Control** > **Auth Policy**.
3. Select **Grant Support Access**.
4. Select an expiration time for the access from the drop down menu.
5. Click **Grant Access**.