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. ;-)
Related
I'm quite new to the entire auth design and am still trying to understand how to use keycloak for authentication and authorisation.
Currently from what I understand in order to have authorisation enabled for a client you will need to have it in confidential.
After which I am kind of stuck in terms of how to set which policy for which permission.
I have a few types resources but currently placing them all under a single client for simplicity sake.
For my use case I have a workspace for users. So each workspace can have multiple users with different roles of owner,editor,viewer. And within the workspace there are artifacts. So it is some what like designing an authorisation for Google drive.
Would like some advice on how best to design it.
One way I have thought of is using groups and each workspace is a group. Using it to assign users to each group as a way to use the group policy for permission.
The other is really by creating multiple policy and permission for each artifact/resource and adding user to each policy for each workspace.
Would like any advice on authorisation design or even where to begin reading.
After some research I have come to these conclusion.
Yes these can be done by keycloak though most likely shouldn't be done in keycloak itself for its design.
Keycloak itself will most likely be more suitable in terms of authenticating/authorising on services or infra level. So this use case of having user be able to access workspaces or artifacts will be better done in application level having a separated service to handle the permission itself.
That being said if it really needs to be done in keycloak the design that I thought of that is not so scalable is as follow.
Create a policy/user and each workspace/artifact as a single resource. Depending on how many types of access/fine grain control is needed for each type of resource create the scope for each (e.g workspace:view, workspace:edit...). Then create a permission for each resource&scope. This allows fine grain access of basically assigning user to permission of each resource through the user policy.
But of course this design has its flaws of the need of too many policies, permissions and resources so it is better to have keycloak just handle the authentication part and authorisation is just giving users the role to be able to access a service and through the service check if the user is authorised for a certain action.
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 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.
How do I configure a Shiro to use Active Directory Authentication, but in addition I want to map the usernames to custom roles. I can't seem to find any information on this. Can anyone give me any pointers?
To do Active Directory Authentication use the JndiLdapRealm
For the authorization override the method queryForAuthorizationInfo
Be aware that you probably get group from your AD so you have to provide your own mapping (group to role).
About this shiro reference manual say :
A RolePermissionResolver can be used by a Realm internally when needing to translate a role name into a concrete set of Permission instances.
This is a particularly useful feature for supporting legacy or inflexible data sources that may have no notion of permissions.
For example, many LDAP directories store role names (or group names) but do not support association of role names to concrete permissions because they have no 'permission' concept. A Shiro-based application can use the role names stored in LDAP, but implement a RolePermissionResolver to convert the LDAP name into a set of explicit permissions to perform preferred explicit access control. The permission associations would be stored in
another data store, probably a local database.
Hope this will help
I'm working on doing the same thing, but I'm pretty sure you have to write a custom AuthenticationStrategy. I wanted to authenticate against AD but use the INI to define roles, but I could not get it to behave properly enough to not accept authentication against either (even utilizing FirstSuccessfulStrategy). I didn't get to look into it too much, so maybe one of the Shiro guys who floats around can correct this, but i hit these issues today.
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