I'm having trouble understanding the logic when evaluating permission for a shared resource.
Alice creates the resource aliceResource with the scopes read, create, delete
Alice creates the policy isAdmin that verifies if a user is admin
Alice creates a permission that applies the policy isAdmin to the resource aliceResource
Alice shares the resource aliceResource with the scope read to the user Bob
Evaluating permissions
For aliceResource in the scope read for bob with no role assigned.
Question 1. Why is it ignoring the policy isAdmin that is applied to the resource ?
For aliceResource in the scope delete for bob
Question 2. When bob has no role assigned, why the policy resource owner is granting read even though I'm evaluating for the scope delete ?
Question 3. When bob has the role admin, why is it the result permit ?, Alice shared the resource with bob for read not delete
I would appreciate if someone could help me understand what's going on.
Thanks
Edit 1.
I have my client evaluation strategy set to unanimous, what I would expect is for all the policies to apply but if I evaluate for a user that has role admin with whom the resource has not been shared, the decision is grant, how can I make the client enforce all the policies ?
Right now the client is doing an or between my policies and the policies created by keycloak when the resource is shared.
Keycloak did not crystal clear documentation for grant decisions.
This diagram is my understanding. The key is Client Decision Strategy
if set Affirmative, will OR logic.
if set Unanimous, will AND logic.
I made my own permissions(read, delete, and create) and policies. Each permission has a single scope (read, delete, or create). Bob assigned read policy, admin assigned all three policies. The permission decision strategy does not affect in this case (due to single assigned between permission and scope)
If set it with Disabled, any users can access the aliceResource.
This affects two cases by set client decision strategy. for bob
This affects two cases by set client decision strategy. for admin
So, if you want to allow bob only read scope and admin three scopes, the client decision should be Affirmative
This is my test decision results.
Related
So I am using Node/MongoDB (mongoose) to implement this feature.
What I need is the right solution for the following problem:
We have many Company(ies)
Each Company can create it's own Roles
Role is a set of predefined Permissions (like task.create, task.read, task.update, task.delete)
They can choose which Permissions are included in which Role
Company can create it's own Users, and assign them a Role
Lets say that company created 3 roles (the order matters):
Owner (always predefined, has all Permissions)
Team Leader
SuperAgent
Agent
Beside that, I also have Users in a tree structure, with parent reference which holds the _id of the User above him.
The rules are:
User can have none or many children
User cannot be above someone that have higher role than him
User cannot be below someone that have lower role than him
The Tree can get as deep as they want...
So the right representation of this would be:
But because Company Owner can at any time make new Role, or switch the order of roles, the problem occurs...
Let's say he switched the places of 2 roles, and they are now:
Agent
SuperAgent
How would you update all Users?
Also, what if he creates a new Role, puts it in 3rd place, and now needs to update everyone 1 role below, so he can attach that new role to a user...
What approach would you take to solve this kind of issue?
Snowflake follows the role-based access control (RBAC) paradigm. Best practice for RBAC is, to have functional and access roles managing either user and clients or access privileges. This creates in worst-case a variety of roles that inherits permissions from and to each other. By nature, one can easily lose sight.
In snowflake, grants to roles and users are stored in ACCESS_USAGE.GRANTS_TO_ROLES and ACCESS_USAGE.GRANTS_TO_USERS. What is a proper approach to identify the data stewards/owner of a role automatically (if not labeled explicitly in a 3rd party tooling)?
Options I thought of:
recursive lookup of OWNERSHIP privileges of roles of roles (will generate a lot of false positives)
recursive discovery of a service account that has advanced permission to a role and lookup the service account owner
lookup over usage pattern of executed queries (might be actually more consumers than producers)
A couple of options:
Populate the role’s comment field with the relevant Data Steward information
Use Tags (in public preview)
I'm writing a terraform template to setup escalation policies.
https://www.terraform.io/docs/providers/pagerduty/r/escalation_policy.html
I want to create an escalation policy to a specific user, but I don't know whether to specify user or user_reference as a value of rule.target.type. What's the difference between user and user_reference in PagerDuty API?
As a value of rule.target.type, user and user_reference are one and the same. Using either type should create an escalation policy that involves the specified user that is defined with rule.target.id.
This is not about having permission to make GET/POST/PUT/DELETE request on resource endpoint. This is about certain user having GET/POST/PUT/DELETE request permission on certain resource.
In our application, we called it Access Control List (ACL) with the following sqlalchemy schema
class ACL(db.Model):
__tablename__ = 'acl'
id = db.Column(db.Integer, primary_key=True)
res_id = db.Column(db.Integer, nullable=True)
res_type = db.Column(db.String(50), nullable=True)
permission = db.Column(db.String(20), nullable=True)
is_allowed = db.Column(db.Boolean, default=True)
users = db.relationship("User", secondary=acl_users)
created_at = db.Column(db.DateTime, default=datetime.datetime.utcnow)
This ACL has many to many relationship with users and many to one relationship with each resource. This ACL can be four things:
if res_id is not null and users are not an empty list, it's called "Exact" because it specifies particular user's permission on particular resource
if res_id is null and users are not an empty list, it's called "Anything" because it specifies particular user's permission on any resource
if res_id is not null and users are an empty list, it's called "Anyone" because it specifies any user's permission on particular resource
if res_id is null and users are an empty list, it's called "Any" because it specifies any user's permission on any resource
I'm not sure this design is common or not, but it seems to have everything it needs to define resource permission.
The question is the following:
If a resource has multiple ACLs, what should be the priority?
We are down to three options:
Add 'priority' column on ACL table and let that determine priority. This approach makes sense but it becomes a nightmare to create Fetch Collection query that considers ACL by priority.
False >> True. e.g. "Anyone" False trumps "Exact" True. If "Anyone" is set False, no user has permission on the resource. This is easiest to make Fetch Collection query.
Exact >> Anyone >> Anything >> Any. Even if "Anyone" is False, if Exact user is set to be True, then all but that user has permission. Making Fetch Collection query is neither easy nor impossible.
Which one of these three options best reflect common practice on permission?
I don't know that any of those is common, the pattern in general is a little different from how I've seen permissions done in the past. (Incidentally, I found this post while looking up how other people have done permissions for a problem of my own, so thanks for the different perspective!)
My previous systems follow a pretty standard Roles+Permissions+Users system. (Many)Users can be assigned to (Many)Roles. (Many)Roles can have a (One)Parent Role. (Many)Roles and (Many)Users can be assigned (Many)Permissions. Permissions are either Allow or Deny and the Operation or Resource that is being controlled. We also had a "Neutral" permission but it isn't really necessary and tends to make an already complex system much worse.
The way I had structured that was that more specific permissions overrode less specific ones, so User trumps Role trumps ParentRole. Within the same level, Deny trumps Allow. Unrelated Roles are the "same level", as are all permissions on any one object. There are no separate priority controls to complicate things, the hierarchy of Roles bakes that in, and anything specific to a User is as narrow as it gets.
So to answer your question, I think you need to mix 2 and 3, or most likely just go with 3 since you wouldn't really have conflicting permissions on one level. Exact permissions should always win. I would then say that Anything beats Anyone, as "Anything" is still specific to one subject, while "Anyone" is specific to a resource but not any particular user. The Any is obviously least critical, acting essentially as a default.
What is the differences beween roles and users.
A role can have many users. An example might be an Admin role, which could mean someone who's assigned and their backup. Both would have the same rights, which are embodied in the role. Individuals can come and go, but roles remain.
A role typically defines a business function (or set of functions) performed by one or more users. Examples would be 'customer service agent' or 'business analyst'. A user is an individual person who is included in the role - Bob, Nancy, and Steve might be assigned to the customer service agent role.
This makes is easier to assign permissions to database objects. You can assign permissions to the role, and any user who belongs to that role inherits the same set of permissions.
On a technical level, see other answers. On a practical level, when you have large user set with fluid permissioning needs due to changing roles, the difference is that assigning per-user permissions means any change in user responsibilities necessitates permissions changes on MULTIPLE database objects that user needs to be added to/removed from perms.
Whereas if the perms are assigned to the roles, the only change is in the role membership.
The latter is both significantly less resource taxing on DBAs, and due to less work needed, significantly less likely to suffer from operator error (e.g. less work to do => less chance to screw it up) and thus more secure.