Roles express responsibilities. Attributes express conditions. Relationships express how the actor is connected to the resource.
Three ways to express access
Roles · RBAC
A project reader may view resources within the project assigned to that role.
Attributes · ABAC
A policy narrows access to resources with a classification appropriate to the person’s department.
Relationships · ReBAC
A request can require a relationship, such as membership in the team that owns the project.
Illustrative policy examples. Actual decisions depend on configured grants, scopes and policies.
What this means for your team
Role-based access control (RBAC): built-in and custom roles, group membership, scoped assignments, inheritance and validity windows.
Attribute-based access control (ABAC): constrain a permitted action using identity, resource and environmental attributes under the configured policy.
Relationship-based access control (ReBAC): evaluate supported ownership, hierarchy or relationship context for scoped resources; unresolved scope must not become a permit.
An access relationship is not a blank cheque. Applicable grants and restrictive policy still determine the result. Explain and simulate decisions before applying reviewed changes.
A practical example
A project reader requests a repository. Their role may permit reading, while project relationship and policy narrow which repository they can reach.
How it works
Select a step to read its explanation
Select a step below to see what happens and why it matters.
Start with three questions: who is asking, what do they want to do, and which application or resource are they asking to use? AIdentity uses the authenticated identity rather than simply trusting a claimed privilege.
Check whether an assigned role grants the action for the relevant resource. For example, a project reader’s role can be limited to that project instead of granting access to every project.
Apply the conditions the organization has configured, such as a department, location or resource classification. A role can grant a starting permission while these conditions narrow when it may be used.
Check required relationships, such as membership in the team that owns a project. If a required relationship cannot be established, it must not be treated as permission.
Return an allow or deny decision based on the applicable role, conditions and relationships. Where supported, an explanation helps authorized teams understand why the decision was made.
1 / 5
This example illustrates the journey. Select any step to explore it at your own pace.
Try an illustrative access decision
A role is the beginning of the decision.
The example uses all three conditions. Real checks depend on the operation and policy; not every request requires the same relationship.
Explore more AIdentity features
Who we protect
Govern people and machines without making them share an identity.