Overview
- Print
- PDF
Overview
- Print
- PDF
Article summary
Did you find this summary helpful?
Thank you for your feedback
Britive authorization allows granular and flexible access, permissions, and policies. With this policy-based access control, the user can add/create new roles and permissions to have customized policies as per the requirements and operational processes.
Britive comes with the predefined roles, permissions, and policies for easy access. The users can create and customize new roles/permissions/policies based on the predefined roles/permissions/policies. The predefined roles/permissions/policies cannot be deleted.
- Consumer: A consumer in access control is any component or entity that uses this policy-based access control for access decisions.
- Actions: A set of predefined actions for each consumer. For example: View/Edit/Manage
- Resources: A role or a policy, secrets, API tokens.
- Permissions: A pair consisting of resource(s) and actions that can be carried out on a resource. For example, a user can manage a particular resource.
- Roles: A set of different permissions. Permissions from different consumers can also be added to create a new role.
- Members: Users in Britive, tags(groups) in Britive, service identities, API/SCIM tokens.
- Policy: Add any member and permissions to create a new policy. Policy decides who has access to what. Policies can be time-based, IP-based, delegated admin only for a particular member or approval-based. A policy can be created using UI or writing it as a code (JSON).
Note: Permissions can be part of multiple roles. Roles and permissions can be part of multiple policies.
Was this article helpful?