In many cases, knowing what authorization logic you want to write is just as hard as actually writing the logic itself. Here, we take you through some common authorization patterns that exist, and how you might represent and build these in oso.
Role-based access control (RBAC) assigns each actor a role. Instead of granting permissions to individual actors, they are granted to roles.
Read on to see how to implement RBAC with oso.
Attribute-based access control relies on rich attributes associated with each actor to make authorization decisions. This model is often used when RBAC is not expressive enough, and is a natural extension of RBAC when using oso.
Read on to see how to implement ABAC with oso.
Sometimes an authorization decision will require context beyond the action, actor, and resource. This could be information about the HTTP request, or the environment the application is running in.
Read on to see how to access contextual information within oso policies.
Some applications have common authorization rules that apply to many different types of resources. oso policies make it possible to share rules across related resource types, and override them as needed.
See how to use Resources with Inheritance to implement extensible policies with oso.
Applications may have multiple types of users. Frequently, internal user accounts for support reps, operations teams, or testing. oso policies can recognize different user types & apply different rules when necessary, avoiding the need for multiple authorization systems.
Continue to see how to write policies that distinguish between multiple users types.