Tag Info

Hot answers tagged

27

RBAC (Role based access control) is based on defining a list of business roles, and adding each user in the system to one or more roles. Permissions and privileges are then granted to each role, and users receive them via their membership in the role (pretty much equivalent to a group). Applications will typically test the user for membership in a specific ...


8

Claims are a method of providing information about a user, and roles are a description of a user by way of which roles they belong. Claims are generally more useful because they can contain arbitrary data -- including role membership information. E.g. whatever is useful for the given application. Claim Based identities are more useful, but tend to be ...


5

As @SteveS said, RBAC is an authorization model whereas claims are a way of providing information about a user. It generalizes the notion of a role. In the past identity servers would simply provide applications the username and the list of roles/groups. Claims generalize this such that any user attribute can be passed on to the consuming application. The ...


5

It seems that you are conflating between RBAC and DAC (Discretionary Access Control): Deny Access is not typically employed in RBAC, but rather it comes from the DAC world. F.e. its common to see an NTFS ACL (Access Control List) with DENY in it. You might be trying to implement a merged model (see the example in my response here) - e.g. building an ACL ...


4

You could configure a modern Multi-Level Security (MLS) product to address the issue. These systems are designed for military grade data protection on shared infrastructure. Typically the systems use Role Based Access Control (RBAC), Discretionary Access Control (DAC), and Mandatory Access Control (MAC) based on security labels. The security labels ...


4

Have you looked at Claims Based Authentication? The idea is that attached to each authenticated user is a collection of claims, and each claim represents something about the user. When the user is authenticated a collection of claims is pulled down for the particular application in question and can contain an arbitrary set like "CanSubmitGoogleOrders" or ...


4

I think it highly depends on end use. Just off the top of my head and without knowing a ton about your app end user, have you thought about session based authentication? Basically do a check on their permissions and apply some type of identifier to their session. That way you could grant requests allowable permissions, which should be faster than checking ...


3

There are some non-canonical (or non-"standard") access control models (besides the well-known MAC, DAC, RBAC...), that are simply not well defined. As in, anyone can define or redefine them as they want, as long as the model makes sense. E.g. this post was the first time I heard that model called "Task based access control", though I use/employ/review it ...


3

This is a very good question, and it has been identified as one of the problems with RBAC. There is been a line of research on parameterized roles (the pdf can be found online), and more recently, the idea of relationship-based access control has emerged (see work of P. Fong et al, for instance this one). I'm not sure how much has been implemented though.


3

There is a similar pattern that Exchange 2010 is using; where the access model is limited using the "Scope" property that applies to the Binding layer. In this implementation, Scope is the "relation" between the authenticated user, and the OU that the "patient" is in. Exchange 2010 has a delegation model where groups of winrm Powershell cmdlets are ...


3

Beside ACLs another common approach is to use rules. So you don't define the rights on a per record level but based on characteristics of records. BaseRight: read postings Rules: postings with x upvotes, posting created by current user, all postings Those rules consists of a name and some program logic. They can be very flexible, for example fragments of ...


3

This is actually a well known problem, and unfortunately not many packaged solutions exist yet - at least, not really good ones. Role-Based Access Control is just a compromise - between scalable administration, and security. Often, this was a good choice, simply because the alternative was - well, there haven't really been many alternatives till now... ...


3

I'm not sure this is a well-known problem. If your default position is deny-to-all, and it should be, then rules should only state what each role can do. If a user/role has access to a resource under any rule at all, I would think that they should be allowed. You might have to re-think the way your roles are laid out. I think that in conflicts, the ...


2

I may be missing something, but isn't a fairly simple solution to use a concept like an "active role"? In other words, the user picks their active role from the list of roles to which they are assigned and then you only check ACL's against that single role.


2

It sounds like you want to have some records restricted to certain groups, and some (most?) records unrestricted. Since another way of saying unrestricted is 'everyone has access' it sounds like you need to add the concept of a group called 'everyone', which all users of the system belong to. Then you can explicitly or implicitly permission the ...


2

Attributes are claims. A claim is simply a statement by someone/something that a user has a given attribute. That someone is the issuer which could be an IdP or an internal bit of logic that gets data from the database. This gives you way more flexibility in how you design your systems as you can specify that a given task will always require a user with a ...


1

First, I think we should clarify vocabulary. DAC means discretionary access control, which means someone (to be defined) can decide who accesses what within the system, when MAC, mandatory access control, tends to relate to systems where access cannot be given within the system. In my understanding, neither DAC nor MAC implies a specific implementation. ...


1

You're suffering from the lack of richness in RBAC. What you really want to consider is attribute-based access control. For instance in this case, you could define rules such as: a user can post in a room he/she is assigned to a user with the role moderator can edit messages in a room he/she is a moderator in a user can edit their own messages... All ...


1

you want to use attribute-based access control which extends beyond role-based access control to include other attributes about users, resources, and more. In your example you have to create a role "MathDepartmentHead" if you use RBAC. But if you use ABAC you can write a rule as follows: A user with the role "department head" can do the action "view" on ...


1

I think this can be implemented using Capabilities. Every subject has a set of pairs (o,r) where o is the object and r are the rights. For example if Customer1 can read file1, and read-write on file2, you can have a Capability list like that: Customer1={(file1,{read}),(file2,{read,write})} If many Customers have the same rights you may use groups to limit ...


1

You may want to consider using what I have heard referred to as a hybrid Claims based access security. In this model basically each task is broken down and used as a profile to keep security easier to manage (although harder to initially implement). Basically setup tables akin to: Users --> Groups --> Profiles --> Rights | ...


1

I am not sure there is any getting around having a per resource permission table. Have a resource table that is indexed by a resource id. Have a role table indexed by a role id. Have a users table indexed by a user id. Have a permissions table that references the above keys. It adds some overhead but with the correct data types it should be quick to ...



Only top voted, non community-wiki answers of a minimum length are eligible