Ash Framework•3y ago

We created a small extensions for rbac policies

https://github.com/traveltechdeluxe/ash-rbac

GitHub

GitHub - traveltechdeluxe/ash-rbac

Contribute to traveltechdeluxe/ash-rbac development by creating an account on GitHub.

104 Replies

natterstefan•3y ago

Awesome! 🚀

Blibs•3y ago

Does this generate, under the hood, a policies code block, meaning it still uses the policies mechanism from Ash? Will it always check for the roles field in a resource for its role or is there any way to configure that (for example, for my users, I normally have a roles and organization_roles fields that mean different things).

barnabasjOP•3y ago

It is just generating normal policy and field_policy blocks. I was thinking of making the role getter function configurable, but as of now it expects an actor with a roles attribute We also combine this with normal policy blocks to add filter policies on resources that need them, as the extension is not handling that case at the moment. Tests are the best docs atm As relationships work a bit differently, e.g. not supported by field_policies. But you can specify that a user can only use an action if it is accessed from a relationship

Blibs•3y ago

Super cool man, this seems to have the potential to make my projects policies way simpler, amazing work 👍

barnabasjOP•3y ago

Thanks, field policies really brought everything together.

Blibs•3y ago

Would you be interested in a PR adding support for custom checkers? I was able to change the code to allow it like this:

  rbac do
    role :admin do
      fields [:*]
      actions [:create, :read]
    end

     role :user, checker: HasRole2 do
       fields [:id, :child, :children, :number]
       actions [:read]
     end
  end

  rbac do
    role :admin do
      fields [:*]
      actions [:create, :read]
    end

     role :user, checker: HasRole2 do
       fields [:id, :child, :children, :number]
       actions [:read]
     end
  end

I can't figure out how to make the bypass part take 2 arguments instead of one to allow something like this:

bypass :admin, checker: HasRole2

bypass :admin, checker: HasRole2

barnabasjOP•3y ago

Sure, if you open the PR we can check what is needed for the bypass and stuff also not sure if changing the whole module is the right approach, as the semantics of the check shouldn't change. Would it be enough for you use case if you were able to pass a function that takes the actor and returns the roles?

Blibs•3y ago

Sure, I thought about passing a module just to try to make less verbose, but I guess something like this:

role :user, field: &get_role_field/1 do

role :user, field: &get_role_field/1 do

Is fine too. What would be a good key name for it? Or should it not even be a keyword and just the function directly like this:

role :user, &get_role_field/1 do

role :user, &get_role_field/1 do

barnabasjOP•3y ago

could be just a function if it is an argument i think. Could you pleaseopen an issue on the repo. I think that is the better place for this discussion we probably also need a way to configure this globaly if the actor looks different in general, having to specify it on every resource would become tedious very quickly

Blibs•3y ago

So, another unrelated question about the lib (not sure if I should ask that here or in the repo since that is not a PR). Does AshRbac works alongside a normal policies block? For example, let's say I have this policies:

  policies do
    policy action(:read) do
      forbid_if actor_attribute_equals(:confirmed?, false)
      authorize_if always()
    end

    policy action(:read) do
      authorize_if expr(:user in ^actor(:roles))
    end
  end

  policies do
    policy action(:read) do
      forbid_if actor_attribute_equals(:confirmed?, false)
      authorize_if always()
    end

    policy action(:read) do
      authorize_if expr(:user in ^actor(:roles))
    end
  end

I was under the impression that this would be equivalent to this:

  rbac do
    role :user do
      actions [:read]
    end
  end

  policies do
    policy action(:read) do
      forbid_if actor_attribute_equals(:confirmed?, false)
      authorize_if always()
    end
  end

  rbac do
    role :user do
      actions [:read]
    end
  end

  policies do
    policy action(:read) do
      forbid_if actor_attribute_equals(:confirmed?, false)
      authorize_if always()
    end
  end

But from what I can tell from my testings the rbac rule is simply ignored. Is that not supported right now?

barnabasjOP•3y ago

As of now it is creating policies like this

# this 

rbac do
  role :user do
    actions [:read]
  end
end

# ends up being this

policies do
  policy action(:read), has_role(:user) do
    authorize_if always()
  end
end

# this 

rbac do
  role :user do
    actions [:read]
  end
end

# ends up being this

policies do
  policy action(:read), has_role(:user) do
    authorize_if always()
  end
end

As of now I'm not completely sure what the best way is to make this composable. I think allowing custom conditions shouldn't be to hard and might solve this problem.

  rbac do
    role :user do
      actions [:read]
    end
  end

  policies do
    policy action(:read) do
      forbid_if actor_attribute_equals(:confirmed?, false)
      authorize_if always()
    end
  end

  rbac do
    role :user do
      actions [:read]
    end
  end

  policies do
    policy action(:read) do
      forbid_if actor_attribute_equals(:confirmed?, false)
      authorize_if always()
    end
  end

In your example your read check would forbid it if the user was not confirmed but otherwise would authrize it. the block created from rbac would not lead to a definitive answer, therefore the authorization from your policy would allow the query to go through The default for the rbac extension is to deny acccess and explicilty set conditions where an action is allowed. so to make it play well together you need to either add policies that deny certain stuff or use the same condition as the rbac role creates.

Blibs•3y ago

By custom conditions you mean add the conditions directly to rbac code block? Would that mean that we would be able to add custom conditions inside the role or actions blocks? I guess that would alleviate the problem, but seems like something that would create a lot of code duplication if I have to set the same rules for all roles (like my confirmed example since that applies to all roles). @Zach Daniel I'm not familiar with the policies code, but is there any technical issue that makes it hard to be composable (meaning that I can split my policies into multiple policies code blocks inside a resource)?

barnabasjOP•3y ago

you can already add conditions to the actions like this:

rbac do
  role :user do
    actions [
      {:read, accessing_from(OtherResource, :relationship)}
    ]
   end
end

rbac do
  role :user do
    actions [
      {:read, accessing_from(OtherResource, :relationship)}
    ]
   end
end

It would be possible to also allow a third element in the tuple with custom checks. e.g.

rbac do
  role :user do
    actions [
      {:read, accessing_from(OtherResource, :relationship), [forbid_if: [actor_attribute_equals(:confirmed?, false)]}
    ]
   end
end

rbac do
  role :user do
    actions [
      {:read, accessing_from(OtherResource, :relationship), [forbid_if: [actor_attribute_equals(:confirmed?, false)]}
    ]
   end
end

which would result in

policies do
  policy has_role(:user), action(:read), accesing_from(OtherResource, :relationship) do
    forbid_if actor_attribute_equals(:confirmed?, false)
    authorize_if always()
  end
end

policies do
  policy has_role(:user), action(:read), accesing_from(OtherResource, :relationship) do
    forbid_if actor_attribute_equals(:confirmed?, false)
    authorize_if always()
  end
end

Maybe composable was not the right word. Policies follow certain rules, if you follow them you can put your policies into different blocks. If I'm not mistaken: all policy block with a matching conditions are executed. a block executes all checks until an answer is found (:authorized | :forbidden) or all checks are done (:unknown) afterwards the result of policy blocks is checked if any returned :forbidden the request is stopped if all are :unknown the request is also stopped if one of them :authorized and the rest is :unknown the request is processed the extension relies on the default being forbidden and explicitly authorizes if a condition matches. if you add another policies like your read policy, that policy essentially bypasses the extensions policies because their policy conditions are not matching. Now that I think about, you could possible already pass your actor_attribute_equals(:confirmed?, false} as condition.

rbac do
  roles :user do
    actions [
      {:read, actor_attribute_equals(:confirmed?, :true)}
     ]
  end
end

rbac do
  roles :user do
    actions [
      {:read, actor_attribute_equals(:confirmed?, :true)}
     ]
  end
end

That way the :user would only be allowed to execute the read actor is confirmed

policies do
  policy has_role(:user), action(:read), actor_attribute_equals(:confirmed?, :true) do
    authorize_if always()
  end
end

policies do
  policy has_role(:user), action(:read), actor_attribute_equals(:confirmed?, :true) do
    authorize_if always()
  end
end

I have to ask chatgpt to summarize this thread and create docs from it afterwards 🤣 In this case I think I probably only have to allow an array of conditions. I think this is more in line with allow list philosophy. That way you can define explicit conditions for when a user should be allowed to do something.

Gaming

Programming

We created a small extensions for rbac policies

Did you find this page helpful?