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


10

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


8

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.


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

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


5

The main disadvantage of RBAC is what is most often called the 'role explosion': due to the increasing number of different (real world) roles (sometimes differences are only very minor) you need an increasing number of (RBAC) roles to properly encapsulate the permissions (a permission in RBAC is an action/operation on an object/entity). Managing all those ...


4

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


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

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

While role-based access control (RBAC) is a major model for managing the authorizations, implementing RBAC has some limitations and consequences. One of the consequences is role explosion, where multiple versions (duplicates) of one role are required to separately manage access to distinct sets of data of the same class. Role-Centric Attribute-Based Access ...


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


2

Using groups for sudoers entries allows you to manage filesystem permissions (which by default are user- and group-based) in the same place as sudo rules. Using User_Alias instead of groups means all aspects of sudo rules are in the same place but makes it more difficult to manage sudo rules in the same space as filesystem permissions. So it's basically a ...


1

There are different issues with RBAC but like Jacco says, it all boils down to role explosions. RBAC is: identity-centric i.e. it focuses on the user identity, the user role, and optionally the user group typically entirely managed by the IAM team admin-time: roles and permissions are assigned at administration time and live for the duration they are ...


1

What they are referring to is a rule-set that is either extremely rigid, in the case of static, or a little more malleable, as is the case with dynamic. I will use the article's example to explain a little bit further: A static policy could require that no individual who can serve as payment initiator could also serve as payment authorizer. This ...


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