Is this ABAC? about oso HOT 6 CLOSED

Hey @simkimsia. Thanks for providing more information. I want to make sure I understand correctly, what you're looking for is:

• As the application developer, you can go into a UI (for example, the django-admin interface) and see the policies defined for a particular resource.
• You can make modifications to the policy and save them
• Those policy changes would be applied to all live/running instances of the application

Does that sound right?

You could achieve that with Oso today, but with a huge caveat that this isn't something we would recommend. I'll talk about that in a bit.

The steps you could take to achieve this, however would be:

• Create a new Policy model to store policies in the database
• Register the Policy model with the django admin: https://docs.djangoproject.com/en/3.1/ref/contrib/admin/#modeladmin-objects - this should mean you can modify policies in the django-admin UI
• Write a custom django middleware similar to this that calls reset_oso on each request, loads the policies from the database and does Oso.load_str to read the policy into Oso.

This is going to create quite a bit of overhead, since each request will need to access the database and load Oso policies.

Why do we not recommend this?

Modifying policy code on the fly like this is equivalent to modifying your Python code on the fly. It's risky to do this without suitable testing + validation.

What would be very helpful for us, would be to understand more your motivation for wanting this. What makes you want to change policy code without redeploying, compared to how you would think about changing application code? And if discussing over GitHub is too constrained, then we can discuss in Slack if you would prefer. There are other adjacent use cases that we are aware of that we would be happy to share with you.

from oso.

Hi Sim,

Oso can handle attribute based access control, as well as other common authorization models like role based access control. You can use Oso to write authorization policies over data from your application using our authorization library and policy language.

An Oso policy is written directly over attributes of your data model. For example, the below policy allows a user to read public posts, and their own private posts:

# A user can read a public post.
allow(_user: User, "read", post) if
    post.access_level = "public";

# A user can read a private post created by them.
allow(user: User, "read", post) if
    post.access_level = "private" and post.created_by = user;

If you use Python, you could call this policy like so:

oso = Oso()
oso.load_file("polar.policy")

user = get_user()
post = get_post()
oso.is_allowed(user, "read", post)

user and post would usually be fetched from the database when processing a request.

You might find our quickstart or ABAC documentation helpful.

If you have more questions, feel free to join our Slack community, our engineers hang out in there a bunch.

from oso.

Thank you

So what happens if I want to make the declarative polar to be database backed?

Meaning to say I can dynamically change policy in the fly without redeploying?

from oso.

Hey @simkimsia

Often when people ask us about dynamically changing policies, what they really want are the inputs to be dynamic. I'll describe that first, and talk about dynamic policies after.

You can use any data from the application in your Polar policies to make them fully dynamic based on the inputs. So in @dhatch's example. If this is the Polar policy:

allow(_user: User, "read", post) if
    post.access_level = "public";

the way you evaluate this policy (i.e. check "can this user read this post") is by passing in data from the application. So the user and post can be fetched from the database, and the check would be checking that the post is public. If the post is changed to private, then the next time the user wants to read it, they will get a deny instead.

Other kinds of inputs can be dynamic in similar ways. For example, another use case might be to have user configurable roles (see: #624), which requires the ability to dynamically change what a role can do.

If this doesn't cover your use case, would you mind sharing more details? We normally suggest that people treat their policy code the same as application code, and so updates to policies are made in much the same way. But Oso is flexible enough to support many use cases, and we've had similar discussions in the slack community :)

from oso.

i am a bit confused by #624 tho I'm also looking at using OSO for django app.

By dynamic I mean, i can see and edit all the policies on a webpage affecting a particular resource class.

I am thinking in terms of typical ActiveRecord ORM and RDBMS schema.

Let's say we have a Product class and the corresponding table is products so by resource class I mean for e.g. the Product model and its table products

Initially, there are zero policies affecting Product. I want to then add a new policy that says only Product owner can edit their products.

So typically, I can write this as code then redeploy the app. I want to be able to dynamically create this policy and have it go live immediately without redeploying the app. That's what I mean by dynamic. A bit like adding new products happens instantly as well.

Does that make sense?

from oso.

Ok I go slack

from oso.