Pick a language:
Build Attribute-Based Access Control (ABAC)
Build Attribute-Based Access Control (ABAC) While role-based access control (RBAC) emphasizes granting permissions based on roles, you may also wish to grant permissions or roles based on attributes of actors or resources. With Oso, you can use attribute-based logic alongside roles.
Grant permissions with attributes Granting users permissions based on attributes is simple with Oso. Let’s say your policy contains the following resource block:
main.polar# ... resource Repository { permissions = ["read"]; roles = ["contributor", "admin"]; "read" if "contributor"; } The block contains a role-based rule that grants the "read" permission to actors who have the "contributor" role.
You can add an attribute-based rule that grants all users the "read" permission for any repository that is public:
main.polar# ... resource Repository { permissions = ["read"]; roles = ["contributor", "admin"]; "read" if "contributor"; } has_permission(_: User, "read", repo: Repository) if repo.is_public; The has_permission rule above tells Oso to look up the is_public attribute on the Repository application type in order to determine whether or not someone should be granted "read" access. This rule will be evaluated alongside the "read" if "contributor" shorthand rule in the resource block so that a user can read a repository if they have the "contributor" role OR if the repository is public.
Grant roles with attributes Oso also supports granting users roles based on user or resource attributes. Oso uses has_role rules to look up a user’s roles in your application. By defining multiple has_role rules, you can customize how users are granted various roles.
For example, you could add a has_role rule to the policy above that grants the "admin" role to the repository creator:
main.polar# ... resource Repository { permissions = ["read"]; roles = ["contributor", "admin"]; "read" if "contributor"; } has_role(user: User, "admin", repo: Repository) if user = repo.created_by;
Build Authorization for Resource Hierarchies
Implement Resource Hierarchies This guide is coming soon for Rust!
If you want to implement resource hierarchies in your app now or just want to register your interest for this guide in Rust, drop into our Slack.
Test Your Policy
Learn to test your Oso policies.
Share Rules Across Resources
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.
Use Context in Policies
Pass context beyond the actor, action, and resource into Oso policies.
Connect with us on Slack
If you have any questions, or just want to talk something through, jump into Slack. An Oso engineer or one of the thousands of developers in the growing community will be happy to help.