Say I copycat Unix file system security groups in my DB: entities can be seen as files and visibility to those entities depend on which group a user belong to. Groups may contain users and other groups. Circular group membership is forbidden.
How to implement that in SQL?
You do not need to design any data model, just use existing patterns.
Unix Security has complete security model.
It has :
Subjects (Users, Groups, Processes make accesses)
Objects (Files, Directories, Services)
Operations (Read, Write, Execute)
In Data Modeling world, we have some patterns to manage this type of permissions (Access Control Models).
Context-based access control (CBAC)
Data-centric security
Discretionary access control (DAC)
Graph-based access control (GBAC)
Lattice-based access control (LBAC)
Mandatory access control (MAC)
Organisation-based access control (OrBAC)
Role-based access control (RBAC)
Rule-set-based access control (RSBAC)
Attribute-based-access-control (ABAC)
https://en.wikipedia.org/wiki/Attribute-based_access_control
I offer ABAC: Attribute Based Access Control. Because of
1- ABAC is so complete and can answer all your requirements.
2- Unix Security has equivalence elements to ABAC.
ABAC basic elemets are:
Subject: who is demanding access to an information asset
Action : that the Subject (User) wants to perform
Resource : identifying the information asset or object impacted by the action
google and find more details.
https://www.axiomatics.com/attribute-based-access-control/
Related
We are currently building a webapp, which has several user roles. Each user has one or more roles assigned, which grants them permission to interact with specific parts (REST resources) of the webapp. For example, a user with role admin is allowed to perform a create action on the resource user.
We have implemented this access control using RBAC with Casbin. This has suited our access control needs until now. We have arrived at the point where we have to implement some kind of mechanism, which enables users of our webapp to grant access to other users for specific data objects (for example their address). In some cases these other users also need to be able to mutate this data.
I have a feeling RBAC is not meant for this level of fine-grained access control. Therefore I am looking for best practices/alternative access control models which are suited for this use case.
I read about ABAC in this answer, but still have the following 2 questions:
Is ABAC still a recommended model, or are there other models I should know about?
If I end up using ABAC, what is the best way to combine this with RBAC?
I much appreciate any responses.
I'm Casbin author. Recently, Casbin adds support for scaling ABAC rules: https://casbin.org/docs/en/abac#scaling-the-model-for-complex-and-large-number-of-abac-rules. Now you can write very powerful ABAC rules within Casbin. You can also mix RBAC and ABAC together inside Casbin.
Every user has one or more roles, every role has one or more permissions. So far I can gather all permissions that are associated to a user via the roles.
The Problem
Some permissions have some constraints. For example:
A user can edit all posts that belong to his site, but no other posts.
Therefore the permission "edit post" should have this constraint.
Regarding the model: If the Constraints are related to the permission, I can't resolve which constraints are active for the particular user.
The user model can have an attribute like "site", but not all users, that belong to one site should have the constraint mentioned above. Some of them should be able to edit all posts.
Question
What is the best way to determine which constraint is active for a particular user. Do I have to split this into seperate permissions and integrate the constraints into the permission model or is there a better solution? I stumbled upon attribute based access control but I am not sure if I should switch to a completely different appoach
Any help is appreciated :)
I replied the following to a previous similar question
You want to use a solution that is agnostic of the type of application it protects. That's the goal of XACML, the eXtensible Access Control Markup Language.
XACML provides attribute-based, policy-based access control (ABAC and PBAC). This gives you the ability to write extremely expressive authorization policies and managed them centrally in a single repository. A central authorization engine (called Policy Decision Point or PDP) will then serve decisions to your different applications.
The minimum set of attributes you will need is typically attributes about the user (Subject), the resource, and the action. XACML also lets you add environment attributes. This means you can write the following type of policy:
Doctors can view the medical records of patients they are assigned to.
Doctors describes the user / subject
view describes the action
medical records describes the targeted resource
of patients describes the targeted resource too. It's metadata about the resource
they are assigned to is an interesting case. It's an attribute that defines the relationship between the doctor and the patient. In ABAC, this gets implemented as doctor.id==patient.assignedDoctorId. This is one of the key benefits of using XACML.
Benefits of XACML include:
- the ability to externalize the authorization logic as mentioned by Bell
- the ability to update authorization logic without going through a development/deployment lifecycle
- the ability to have fine-grained authorization implemented the same way for many different applications
- the ability to have visibility and audits on the authorization logic
HTH
I work for an organization that hosts applications used by many other organizations that reside in a hierarchy (I work in the education field).
This article detailing what they call "ROBAC" identifies and proposes a new model for access control that we'd like to try and implement. Does anyone have experience with implementing IdentityServer by Thinktecture or any other .NET/Katana based technology?
Is it possible to use OAUTH2/OpenId to implement a ROBAC/OrBac model? If so, is there any documentation available out there on how to do so?
What you need is ABAC, attribute-based access control and possibly XACML, the extensible access control markup language which implements ABAC.
ABAC is generic enough to implement RBAC, ROBAC, and generally *-bac. In ABAC you get to define the attributes you need. Those attributes can be about:
the user e.g. role, department, age, clearance...
the object (resource) they're trying to access e.g document, classification, owner, author, status...
the action they want to do on that object e.g. view, delete, approve...
the context e.g. time of day.
You then combine these attributes into policies e.g.
A user with the role publisher can do the action publish on a document if the document status is draft and if the user's department is equal to the document's department
There are a lot of resources on ABAC/XACML. Check out:
the NIST project page on ABAC
the OASIS XACML standard page
the Axiomatics Policy Server Express Edition - a lightweight implementation of ABAC.
I am learning Apache Shiro, and I found this article:
The New RBAC: Resource-Based Access Control
And the author said:
.......you could assign behaviors (permissions) directly to a Role if you
want. In this sense, you would still have a Role-Based Access Control
security policy - it is just you would have an explicit RBAC policy
instead of the traditional implicit strategy.
But that begs the question - why stop at roles? You can assign
behaviors directly to users, or to groups, or to anything else your
security policy might allow.
It seems that the author prefer to store the relationship of User and Permission directly instead of through a Role.
Though it seems this is simple and straightforward, I have some questions:
Are there any essential differences between two of them?
The Database schema.
In a Role Based Access Control, normally we use three tables to describe the relationship:
user
role
user_role
No if I use the Resource Based Access Control, what is the normal practice for building the tables?
This is the first time I hear of resource-based access control.
I would be extremely careful in going down this path. In the world of authorization there are essentially 2 standards:
Role-based access control (RBAC) as standardized by NIST and implemented in thousands of apps and frameworks with support from the main vendors (CA, Oracle, IBM...)
Attribute-based access control (ABAC) as being standardized by NIST (also here) and equally well implemented by vendors such as IBM, Oracle, and Axiomatics which is where I work.
Resource-based access control seems to be a model invented by Stormpath and supported by them only. It may be good but it will only work with their environment.
Role-based and Attribute-based access control are well accepted paradigms supported by NIST and other standardization bodies such as OASIS (where SAML and XACML were defined 10 years ago and are still supported today).
The question to you is: why is role-based access control not enough for you? Do you have a role explosion issue? Is it not expressive enough? Do you need to implement relationships between users, resources, and context?
ABAC and XACML can let you do that. I posted a simple video a while back on YouTube that deals with attribute-based access control. Have a look.
The bottom line is that RBAC and ABAC are standards that work across multiple applications and layers. Resource-based access control is specific to Apache Shiro only.
Does anyone have any tips as we develop an application that will require each user to be assigned a permission level. The permission level will determine what functionality is available to the user.
Any advice?
How would you (do you) employ such functionality in your application?
First you need to figure out what functionality you want to cover by your permission system, and in what detail:
Access to tables (List, CRUD)
Functions/Modules
Access on record level (=ACL)
Positive (grant) or Negative (revoke) semantics
What is the "admin" role allowed to do
If you want to restrict access to tables, you can easily set up an additional table containing all the table names, and grant select-list/select-record/insert/update/delete access to the roles/groups, as sketched by JV.
If you want to grant access to functions or modules, have a table of modules and grant execute to roles/groups.
Both functionality is equivalent to grants in SQL.
Access restriction on record level is much more complicated, as you need to model access rights on the status of a record (e.g. "public", "private", "released" in CMS apps), or have explicit permissions on each record.
If you want to implement a permission scheme equivalent to NTFS, you calculate the permission per record based on the group the user is assigned to, and have user-specific permissions that may override the group permissions, and revokes overriding grants.
My applications typically work on table+function / group level, which may be good enough, depending on your requirements.
This is the partial ER diagram for identity module in Turbogears, Python. It implements what you are looking forward to. Users are associated with groups and groups have associated permissions.
The two ways restricted feature availability can be implemented are:
(I prefer)In your controllers check the group to which the user belongs to and moderate your response to the View according to that. Thus View is just a renderer - no business logic.
The View gets the user details like groups and permissions and it decides what to display and what not to (MVC violated).
Read more about MVC (and Turbogears may be).
alt text http://jaivikram.verma.googlepages.com/temp.jpeg
It depends a lot of the language you use and the architecture of your application (web service ? client software ?).
For a server toy project, I though about assigning a minimum permission level to each command, and check it directly when a command network packet is received, triggering a permission error when the user hasn't a high enough level. I might not be suitable for another architecture.
It may be a bit of a dead end to pursue the concept of 'levels'. It may suit your current application, however a data model that consists of a mapping of roles to privileges is more general and suits most purposes.
Assign roles to users. A user may have more than one role, and their role(s) define the privileges they have. The concept is similar to groups, however 'role' is usually easily mapped directly to business logic (think of roles such as 'administrator', 'user', 'clerk', 'account manager', 'regional manager', etc). Privileges also map fairly directly to functions and data objects. You may also be able to map to implementations that use underlying platform access control (e.g. Java privileges).
In the controller code, you check (via their roles) that the user holds the required privilege to perform a function. It is also good practice to modify your views to hide functions that the user does not have the privileges to perform.
In your design you can visualise / document the access control system as a matrix (roles to privileges).