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.
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.
I have a very complex requirements to implement the roles and permissions in my asp.net mvc 4 application. I know about ASP.NET Identity authentication but that does not fit into my requirements.
I have 15-20 controllers in my applications which have their respective views, some of views have partial views which are being handled in Jquery code and loaded from there.
Now I have below requirements:
1)Some of controller are accessible to a perticular role(s) only.
1) Some of views in a controller are accessible to a perticular role(s) only.
2) In a view for a Grids only some of columns and actions like Edit/Create/Delete are accessible to a perticular role(s) only.
I am thinking to implement checks on controller , actions and views on the basis of role but that can lead into a problem when I have multiple roles and custom roles in future. What can be best way to implement this kind of solutions. Any suggestions will be appreciated.
Every time you have "complex" authorization requirements, it's a pretty good indication that "identity-centric" access control is not enough. What's identity-centric? Authorization that relies on user metrics (identity, role, group) only.
Also, in your question, you list the fact that you do not know what the future holds. You do not know what other custom roles you need to implement.
All this means you need to extend your existing RBAC implementation with attribute-based access control (abac). ABAC gives you 3 interesting elements which you do not have in RBAC:
A policy language. You can express complex authorization challenges using this policy language (either of xacml or alfa). In particular you can express things like Permit if user department==record department.
An architecture: the architecture identifies key components with specific responsibilities. For instance, you have a Policy Decision Point (PDP) which produces authorization decisions. You have a Policy Enforcement Point (PEP) which is the piece that sits in front of or inside your application. The PEP protects the application.
a Request / Response scheme between the PEP and the PDP. The standard format is a Yes/No question as shown in the diagram below. JSON can be used to encode the requests.
From your point of view, you have two options. Either:
Implement claims-based authorization. This is available OOTB in .NET
Bring in XACML. I'm not sure .NET has any native libraries but there are SDKs out there.
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've been reading about Azure's Access Control Service and claims-based authorization in general for a while now, and for whatever reason, I still don't see the rationale behind moving from role/permission-based authorization to a claims-based model. The models seem similar to me (and they probably are), except that the list of what the client can and can't do comes from a third party and is wrapped up in some sort of token, instead of from some sort of database that the server has to query. What's the advantage of getting a third party (the token issuer) involved?
I fully understand the advantages of outsourcing authentication to a third party. It allows apps to not have to create new users all the time, worry about storing passwords, etc. when they can just push that off to some other service that already has the infrastructure set up. It's essentially the DRY principle for authentication.
However, in my mind, that same logic doesn't work for authorization. Each app has its own resources it has to protect, and therefore its own rules for authorizing users to perform certain actions. The infrastructure seems simple enough that each app could create it on its own (a table mapping users to roles, and possibly another mapping roles to permissions), and even if you wanted to outsource it, it seems that the claims-based model is doing something more complicated than that.
The only partial explanation I've seen comes from Building a Claims-Based Security Model in WCF, and it gives two main advantages to claims-based auth: more flexibility, and someone to "vouch" that the information in a claim is correct. When would you need either of those?
Claims-based authorization seems to be gaining popularity, so I assume there must be some good rationale for it; I just haven't figured out what that is yet. Can someone please provide a concrete example of a situation where claims-based auth works better than role-based, and why it works better in that case?
(EDIT: I missed a third benefit listed in the article: supporting single sign-on/federation. But doesn't authentication deal with that on its own without getting authorization involved?)
I guess the main promise of a benefit from federated security / claims-based system would be one fewer area you have to deal with different systems.
Imagine a site where you have local users authenticating with Windows credentials, a bunch of internet users using username/password, others using certificates, and maybe another group of users with biometric authentication.
In today's system, you have to set up and deal with all different kinds of authentication schemes and their different ways of doing things. That can get pretty messy.
The promise of a federated security solution would be to handle all those chores for you - the STS (security token server) would handle all different kinds of authentication systems for you, and present to you a uniform and trusted set of claims about a caller - no matter from where and on which path he's arriving at your site.
Of course, just examining and reacting to a single set of claims rather than having to understand four, five, ten different and disparate authentication systems looks like a really compelling promise to me!
The purpose of claims based authorization is to allow fine grained access control based on Boolean expressions that evaluate characteristics of the accessing entity and the resource. This reduces or eliminates the need to provision groups. As with federated identity, claims also provide a vehicle for an Identity provider to manage their users wile allowing a resource provider to gate users access to assets.
Note: Claims can be used within a single enterprise and provide the following benefits:
1) Access grants and revocations do not require provisioning or de-provisioning
2) Thus changes are instantaneous
3) Resource owners can define the scope and requirements for access rather than having admins create groups manage group memberships - this moves the access control decisions into the hands of the folks best suited to make such decisions (the data owner)
4) This results in fewer groups being required and fewer member in the groups
5) There can be issues creating a single group to accommodate a large community having access (for
example all full time employees can read a HR policy) - Claims avoids this problem
6) Audit is more informative - the reason a grant or deny took place is clearly visible
7) Claims support dynamic attributes, such as 2-factor authentication, time of day, or network restrictions
There are a lot more reasons, but those ones come to mind. There will shortly be a video at www.cionsystems.com that showcases this (disclaimer - I work there and recorded the video - I still need to post it) Also, for reference, claims aware apps and platforms include SharePoint 2010 on, Windows 2012 (file shares), Azure, many SaaS services (Facebook and Salesforce)
Also, with claims you can blend information from multiple sources (say Facebook and your local AD) etc. - which is increasingly important
Not sure if the rules allow this, but feel free to ping me with your questions or comments. I'll happily edit the post to make any corrections or add pertinent info.
Claims can come from AD, databases tables, SAML, OAuth, algorithms, XACML or any other trusted provider. Harnessing claims requires a bit of kit - with apps and platforms evolving rapidly in this space.
All the Best,
Paul
Claims-based access control also helps build up attribute-based access control and policy-based access control. If you standardize on a set of pre-agreed claims that can be assigned to users based on their other attributes (e.g. a US manager can have claim U_M; a European manager can have claim E_M).
In an attribute-based and policy-based environment, it's possible to achieve fine-grained authorization (also known as fine-grained entitlements) using XACML.
In this case, you can have authorization that depends on who the user is (claims) but also what they want to do (resource information) and under which circumstances (context).
CBAC with XACML will let you express rules like:
managers can edit notes they created themselves or notes that their
direct reports created.
Role based security is a limited security model
Authorization is:
Based on role membership only
Claims based security is much more flexible and expressive
Authorisation can be:
Based on role membership
Based on Age
Based on Geographic Location
Based on an account balance
Based on a size
Based on pre-defined securtiy levels
Based on any combination of the above
When implementing an RBAC model using an LDAP store (I'm using Apache Directory 1.0.2 as a testbed), some of the actors are obviously mappable to specific objectClasses:
Resources - I don't see a clear mapping for this one. applictionEntity seems only tangentially intended for this purposePermissions - a Permission can be viewed as a single-purpose Role; obviously I'm not thinking of an LDAP permission, as they govern access to LDAP objects and attributes rather than an RBAC permission to a ResourceRoles - maps fairly directly to groupOfNames or groupOfUniqueNames, right?Users - person
In the past I've seen models where a Resource isn't dealt with in the directory in any fashion, and Permissions and Roles were mapped to Active Directory Groups.
Is there a better way to represent these actors? How about a document discussing good mappings and intents of the schema?
RBAC is not RBAC is not RBAC and RBAC on paper is difficult, but nearly impossible to implement in a real-life.
Everyone has their own "idea" of RBAC and most everyone uses different terms for every thing associated with RBAC. Generally from an LDAP implementation perspective you seldom have all the "pieces parts" to do a proper implementation within LDAP.
The "pieces parts" in simple terms are:
S = Subject = A person or automated agent or Users
P = Permissions = An approval of a mode of access to a Target Resource
T = Target Resources = The Object to which you want to assign permissions
The Role, at minimum, needs to associate a Permission and a User.
The Target Resource could be outside of LDAP entirely. So it could be an Application on a Tomcat server or simply the right to read "other" entries within the LDAP Server.
So typically the best you will do within LDAP is to setup an object which has a list of users and if there are some resources that are within LDAP, assigne the proper directory permissions for those target resources.
Then there is the little problem implementation.
We have now need a Policy for implementation of our Role. So our role, we will call it USER-READ-ONLY, is not useful without a policy on how it is to be used.
In our case, we could just say the USER-READ-ONLY Role can read anything in our Organization.
So we now have a Policy. Where is this policy stored? The Digital representation of a Policy is stored in the "Policy information Point" or PIP.
How do we interpret the Policy Supplied from the PIP? Policies are interpreted by the Policy Decision Point (PDP).
Who decides if a Subject (user) can access a resource? The Policy Enforcement Points (PEP).
Putting all this policy stuff together we end up with the digital representation of the Policy is provided by the policy Information Point to the policy Decision Point which then passes the decision to the Policy Enforcement Point where the access is permitted or denied.
So in our RBAC story, where is the PIP, the PDP, and the PEP?
Well if the Target Resource is in the LDAP directory, then it is the LDAP directory that is the PIP (which we probably hardcoded and is not abstracted, the PIP likewise and the PEP too, and that was easy.
But if it is our Tomcat Application, it MUST be a method within the Tomcat Application that can interrupt knows must use a method to say "I have this Subject (user) and he wants access to this Target Resource (inventory) to perform this Permission (READ-ONLY)".
Sure there are some standards for all this stuff. (Google XAML, RFC3198, ISO10181-3, NIST) but they are Standards with wide gaps for practical implementations.
So keep in mind REAL implementations of RBAC is hard.
Sure IMHO, we should know about RBAC, study the papers and make it a strategic direction, but the real life implementation across a broad base of vendors and applications, well we are just not there yet.
-jim
Check out Fortress which is a real-life, open source implementation of ANSI RBAC (INCITS 359) that uses LDAP. http://iamfortress.org/
and yes it was fairly difficult to implement but we've been working on this problem for over 10 years. ;-)