Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange

Hot answers tagged

27

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 ...


18

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 ...


11

DAC is the way to go to let people manage the content they own. It might sound obvious, but for instance DAC is very good to let users of an online social network choose who accesses their data. It allows people to revoke or forward privileges easily and immediately. Reactive access control, Seeing further and Laissez-faire file sharing provide nice examples ...


9

These are 'levels' for the NIST RBAC Model, as described in: The NIST Model for Role-Based Access Control: Towards a Unified Standard.(pdf) They respectively refer to: Flat RBAC Hierarchical RBAC Constrained RBAC Symmetric RBAC Flat RBAC means just the base RBAC model. The NIST Model requires that the roles assigned to a user can be determined, as well as ...


6

Encryption is used to provide confidentiality of data that may or will be accessed by an untrusted entity. Access control is used to limit or otherwise control an entity's access to an object. Asking "when do we use them" is an open question. Access controls can be anything from a padlock on a gate to a permission set on a filesystem. They can be simple or ...


6

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 ...


6

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.


4

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 ...


4

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 ...


4

RBAC cannot directly stop a user from doing something evil if the user must be able to do an action with the potential for evil as part of the his job function. For example, if the senior staff member does have the need to move around money with junior staff budgets because he fixes allocations between the junior staff members - then he could very likely as ...


3

Encryption mechanisms can be used to achieve specific outcomes: Making some data illegible, with the ability for specific individuals to retransform it into a legible format later: this can be used to implement confidentiality within some technical limitations Providing an authentic signature related to a specific blob of data: this can be used to provide ...


3

Each system is used for a different overriding security requirement. The three main security requirements are confidentiality, integrity, and availability. MAC supports a security requirement of confidentiality more so than the others. DAC supports the security requirement of availability more so than the others. RBAC supports the security requirement of ...


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

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 ...


3

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 ...


3

Role Based Access Control is a well defined model, that comes with its own terminology. At minimum, RBAC has the following entities: A User has one or more Roles. A Role is a collection of Permissions. A Permission (or privilege) is the right to perform an Operation (or action) on a Resource (or object). So, from what you describe in your question, I ...


2

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 ...


2

In order to implement HIPAA and in particular HL7 scenarios such as the ones described here, it is worth considering attribute-based access control (ABAC) and XACML, the OASIS standard that implements ABAC.


2

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 ...


2

The best way to structure an ACL is as a bitmask which makes it easy to quickly determine complex access rights for a resource. The best way to store that might be a key-value store such as Redis or any object-caching technology that integrates well with your environment. The decision to go with NoSQL vs SQL would be more of a business or IT decision ...


2

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. ...


2

Quoting this SANS article: Static Separation of Duties defines role memberships that are mutually exclusive. For example, RBAC can ensure that users cannot be members of both the purchasing role and the approving role. That is how SSD ensures that the same person cannot purchase and approve the purchase. Dynamic Separation of Duties allows the same ...


2

Your data model looks like a graph. Contact --- assigned to --- File, and vice versa. So the assignments are links (edges) in the graph. I am assuming that there can also be multiple contacts assigned to a single file or multiple files assigned to a contact. How would you handle deleting a contact that is assigned to a file which is assigned to another ...


2

I am less used to angular frontends, but this as always been a question: should the control of user permissions be done client-side or server-side? The answer was (and IMHO still is) that client side and server side controls serve different purposes: client side controls help in customizing the UI to only present what the user is allowed to use. The ...


2

ID token and Access Token serve two different purposes in OIDC. ID Token = For ascertaining Identity of the user. Who the user is? What is their email address? Access Token = For ascertaining if the user is allowed to have access. If the Access Token signature is valid, then allow access. Typically contains the information needed to ascertain access (e.g. ...


1

These are two separate concepts, and I'll attempt to make an analogy. Imagine access control mechanisms are like locking windows and doors in a house. You have to make sure that all of them are locked down to create a secure house, but breaking them is still possible for entry. For some things in the house this level of security is all you need. But ...


1

I can suggest the following options based on provided information: Define data domain (North America, Europe, etc.) according to your criteria and grant roles within that domain only. E.g., grant Role 1 within data domain A or account S1. Simple enough, but depends on your data structure. Add additional conditions in ABAC style, i.e. grant or deny access ...


1

Authentication, authorization, and accounting (AAA) is a term for a framework for controlling access to computer resources, enforcing policies and auditing usage. RBAC (Role Based Access Control) is a way that dictates how a subject can access objects. Two other forms beside RBAC are the highly restrictive mandatory access control model (MAC) is compared to ...


1

It sounds like your following good security principles by establishing secure defaults, trying to keep it simple, and ensuring guests have least privilege. I think both of the two options are viable and should be left up to you, the programmer. Whatever you think is simpler and easier to manager long term is probably the right choice. If a visible to ...


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