Advice on implementation of complex security permissions

[thaingo]

I am struggling in implementing of the following use-case:
Given:

• There are 3 users: User1, User2 and User3. Also, User3 reports to User2.
• persistent models has field createdBy indicating its owner

Requirement is to implement a solution to meet the following:

• each user can only access to his own data unless specified otherwise;
• if a record created by User1, then User2 can have read/write permissions on that record as well;
• if a record created by User3, then User2 can also have read permission on that record.

Could you please give me some advice on this?

[aklish]

Will respond tomorrow. You can check out yavin.dev security checks in the meantime for examples.

[thaingo]

Looked at Yavin security checks - very useful reference.

I do look for a sample design that gives a user flexibility to grant/revoke read/write permissions on his own data to a group or a his peers any time.

Your thoughts?

[aklish]

I'm not following this description below:

• if a record created by User1, then User2 can have read/write permissions on that record as well;
• if a record created by User3, then User2 can also have read permission on that record.

Are users 1, 2, and 3 specific users or examples of users where you want to generalize a specific rule. If the latter, I don't understand the rule you are trying to encode (specifically the first bullet).

In general, the approach we have taken for these kinds of rules is to:

• Create a user Principal object (in Spring this would be a subclass of Authentication), that has a set of additional properties or questions we can ask about the user (What roles does the user have, who is the user's employer, what companies do they belong to, etc). We then define a separate security check per property/question and then can combine these checks using AND, OR, and NOT in our permission expressions.
• A very common permission rule is related to ownership. A model is created or owned by a particular user. If we want to generalize a permission rule for a large number of models with an owner, we create an interface (Owned) with a method (getOwner - which returns the User owner), and write security checks parameterized by Owned (Check<Owened>)

[thaingo]

I'm not following this description below:

• if a record created by User1, then User2 can have read/write permissions on that record as well;
• if a record created by User3, then User2 can also have read permission on that record.

Are users 1, 2, and 3 specific users or examples of users where you want to generalize a specific rule. If the latter, I don't understand the rule you are trying to encode (specifically the first bullet).

Sorry, my bad. They are examples of users. I tried to generalize a specific rule.

In general, the approach we have taken for these kinds of rules is to:

• Create a user Principal object (in Spring this would be a subclass of Authentication), that has a set of additional properties or questions we can ask about the user (What roles does the user have, who is the user's employer, what companies do they belong to, etc). We then define a separate security check per property/question and then can combine these checks using AND, OR, and NOT in our permission expressions.
• A very common permission rule is related to ownership. A model is created or owned by a particular user. If we want to generalize a permission rule for a large number of models with an owner, we create an interface (Owned) with a method (getOwner - which returns the User owner), and write security checks parameterized by Owned (Check<Owened>)

In my use-case, user defines dynamic permission rules specifying who (predefined users and/or groups) can do (read/write/delete) on what (a large number of models). It is an attribute-based access control. Dynamic here means: the rule is persistent and is executed at run-time. The user who defines that rule, can change the rule at any time.

Appreciate your further advice @aklish .

[aklish]

I would probably associate these dynamic rules with the user who they apply to (associating them with the user who created the rule is also possible but wholly optional). Then I would create a principal object with a method that returns the rules that govern the particular user who is trying to read or write a model.

I might write general checks like 'canRead' and 'canWrite'. These checks would get the list of rules for the principal and apply them against the object that is being read or written.

[thaingo]

I would probably associate these dynamic rules with the user who they apply to (associating them with the user who created the rule is also possible but wholly optional). Then I would create a principal object with a method that returns the rules that govern the particular user who is trying to read or write a model.

I might write general checks like 'canRead' and 'canWrite'. These checks would get the list of rules for the principal and apply them against the object that is being read or written.

Thank you @aklish . Your advice gives me more confident of what I am experimenting. I am making some progress with an approach that is very similar to the one you shared. I have a concern with the approach too: there are many relationships associated with models like User. But I guess that might be a different problem.