Access Control: Difference between revisions
No edit summary |
|||
| Line 19: | Line 19: | ||
==== Don't use RBAC ==== | ==== Don't use RBAC ==== | ||
RBAC | |||
* In RBAC, the main characteristic of a requesting entity considered is the role(s) assigned to it. This isn't very good for object-level/horizontal access control decisions with multiple factors. | |||
** In ABAC, attributes can be considered with each other, and can take on dynamic values. This allows for significantly more fine-grained control following principle of least priviledge | |||
** ReBAC supports assigning relationships between direct objects and direct users, so it is also more fine-grained. | |||
* With a large number of roles, it is easy to improperly perform role checks, causing too much or too little access, especially if the implementation doesn't support role hierarchies. | |||
* With a large number of roles, it may be difficult/slow to send credentials. | |||
* | |||
= Design Principles = | = Design Principles = | ||
Latest revision as of 04:05, 6 March 2024
Sources
Description
Access control is the process of granting or denying specific requests from a user, program, or process. There are many types of access control.
Models
RBAC (role based access control) grants or denies access based on roles assigned to a user. The relationship between roles and users can be many-to-many, and roles can be hierarchical.
Attributes are characteristics represented as name-value pairs. They are assigned to subjects, objects, or the environment. Attributes are very flexible, including things from job roles to time, and ABAC (attribute based access control) controls access with policies that are specified in terms of attributes.
ReBAC (relation based access control) grants access based on relationship between resources. For example, a post can only be edited by the user that created it.
There are many other models, but those are the big ones.
Don't use RBAC
- In RBAC, the main characteristic of a requesting entity considered is the role(s) assigned to it. This isn't very good for object-level/horizontal access control decisions with multiple factors.
- In ABAC, attributes can be considered with each other, and can take on dynamic values. This allows for significantly more fine-grained control following principle of least priviledge
- ReBAC supports assigning relationships between direct objects and direct users, so it is also more fine-grained.
- With a large number of roles, it is easy to improperly perform role checks, causing too much or too little access, especially if the implementation doesn't support role hierarchies.
- With a large number of roles, it may be difficult/slow to send credentials.
Design Principles
- Design upfront since it can get very complicated, ensure flexibility.
- Force all requests to go through access control checks
- Deny by default
- Principle of least priviledge: grant as little access as possible
- Don't hardcode roles: typos can be very bad
- Log access control events to identify malicious users
Tips
- Use libraries responsibly: check them, make sure to not misconfigure, understand any technology you build autohrization logic upon
