Talk:Role-based access control

Untitled

I have the impression that this article is about access to computer files, but why must it remain only an impression? The first sentence of an article titled "homology" may begin by saying "In mathematics, homology is....." or by saying "In biology, homology is.....", etc. This article should do the same thing, so that people not familiar with its field, whatever it is can tell what they're reading. -- Mike Hardy

The article is about Role based access control, a method of controlling operations on objects (including but not limited to computer files). But I agree that the article is unclear on this point. 155.101.224.65 (talk) 21:33, 17 June 2009 (UTC)

Standard terminology and diagrams?

The commonly accepted RBAC standard is the one that was produced NIST (National Institute of Standards and Technology [U.S. Government]). (This is ANSI [US] and INCITS [international] standard 359-004)

But there are differences between the terminology and diagrams of the article and the standard. (For example, in the standard a permission is an object and operation pair... The article's diagram matches up permission<->operation ... confusing to anybody that is used to the terminology and diagrams that the standard uses)

I think it would be nice to make the article agree with the official standards instead of inventing similar but different usages. 155.101.224.65 (talk) 21:31, 17 June 2009 (UTC)

I agree, the UML diagram is overly complicated. I think it would be better to show an example using users, roles, groups and resources. Oderbolz (talk) 14:17, 17 January 2018 (UTC)

empowerID advertisement

Deleted section on EmpowerID, it's an advertisement for a particular product, not an encylopdia entry. Moreover, even if the particular product was notable, it is only useable in certain environments, it's not about RBAC conceptually in general. Lacked any citations too, other than a link to the web page of the company/product advertised. — Preceding unsigned comment added by Jrochkind (talk • contribs) 04:26, 23 January 2011 (UTC)

RBAC vs. MAC vs. Models vs. Types

The article contains portions that seem to state RBAC is an alternative to DAC or MAC. But this is not the case. DAC and MAC simply state that the creator/owner of an object gets to decide how it can be used. Can they decide? DAC. Is the decision out of their hands? MAC. An access control model can be identified as one of those two types. Of course that is simplifying things a bit - some implementations of flexible MAC models can look like DAC, such as the unconfined_t as implemented in SELinux's standard Type Enforcement policy.

Additionally there were statements made stemming from the TCSEC days where MAC == BLP/Biba. This is not the case. There are numerous MAC models such as Type Enforcement, Clarks Wilson, Brewer and Nash, BLP, Biba, etc. Just as there are numerous DAC models like traditional user/group/other models and capabilities.

Sound-Mind (talk) 15:22, 4 February 2012 (UTC)

RBAC is the kind of term that's really only defined to contrast with something else, and I think there's some confusion about what that something else is.

In some places I think RBAC just refers to having a level of indirection (abstraction) between the individual person and the security policies, as opposed to tying the policies to individuals directly. In the weakest example this might mean attaching policies to a group structure, to ensure that the permissions available to an individual will automatically be updated when their group membership changes. In the stronger sense it might also involve letting the individuals switch between ("assume") different roles when performing different tasks, to more narrowly scope the level of access that they have enabled at any one time (ensuring that an accident in one task can not impact unrelated resources that the same individual accesses for other tasks.) The problem with tying policies directly to individuals is that it is inherently difficult to maintain (like spaghetti code whereas the indirection provides modularity). If permissions tie directly to individuals, it is complicated to try to audit whether any individuals have any permissions that they no longer require (because it requires maintaining detailed knowledge of what work is performed by which individuals), and individuals tend to gradually accrue more permissions as their work shifts over time (enlarging the potential impact radius from accidents or attacks).

Elsewhere (e.g. in AWS) RBAC is meant to contrast with ABAC, that is, whether access is controlled primarily by the identity of the agent versus primarily by the attributes of the resource. (I think any access control is necessarily selective concerning both principals and resources, so it's more a question of emphasis, or highlighting subtleties regarding the technical implementation capabilities.) Or by whether policy detail is configured via explicitly written rules vs by dispersed metadata tags. (RBAC and ABAC do not seem mutually exclusive.)

I've also seen RBAC used to distinguish AWS IAM roles from AWS IAM users, or rather, to distinguish other authorisation schemes vs long-lived secret credentials. (Long-lived credentials are undesirable because they intensify the hazard of credential leaks, and necessitate ongoing rotation maintenance. While IAM users can create long-lived access keys, in contrast, IAM roles tend to be exercised by only exposing transient keys which are automatically passed to particular EC2/EKS/Lambda/etc compute resources or are exchanged via other authentication technologies such as SSO or OIDC.) FWIW I think this is a misuse/confusion of the RBAC term. (In particular, note IAM policies can be granted to IAM users indirectly via their group memberships, and IAM roles can also be associated to specific individuals via SSO, so the terminology is not always aligned..)

Anytime a term is used primarily for X vs Z comparisons, having an article about X in its own right becomes problematic. (Because almost anything can be labelled X, if it is compared to something more intensely Z-like. Which leads to citing examples that do not make sense once removed from their original context, they don't form a consistent group, resulting in confusing articles. It's like using a loaded polemic term as the article name, and expecting there to be anything objective and self-contained to say about that in isolation, instead of just having an article about the debate.)

This article references MAC and DAC because that is what the introduction of the seminal paper on RBAC did, but the reference in this article is anachronistic. (As you say, MAC refers to the centralised hierarchical classification scheme where each resource has a confidentiality level and each individual has a clearance level, and DAC refers to the decentralised scheme whereby the creator/owner of a resource is delegated decision-making over which other individuals have access.) The original point was only that RBAC is different from both those preceding schemes, but this isn't useful because those two schemes are no longer well known today in the contexts where RBAC is encountered, and it's a semantic debate whether it was ever accurate (clearance levels are arguably roles, and decentralised grants might still be able to be issued to groups rather than specific individuals; today's well known access control examples such as POSIX filesystem permissions arguably contain or can support elements of all three schemes.) Cesiumfrog (talk) 13:48, 1 June 2024 (UTC)

Implementations

It would be useful to contain a list of notable implementations of RBAC, similar to how MAC and DAC pages do. Perhaps SELinux (when using roles) or AWS IAM would be a some good examples, but I dont know enough in this area to write the section?

82.5.138.247 (talk) 08:50, 26 April 2019 (UTC)

Role-related Cryptographic Technology?

Cryptography is an important security tool to protect data from illegal access, but it is usually aimed at the data resource, lack of systematic consideration. The integration of RBAC and cryptography can construct a more flexible and systematic security mechanism. On the one hand, this integration expands the application field of cryptography; on the other hand, it ensures that the RBAC-based IT system has cryptography security.

According to the existing researches, suggest appending a new section "Role-based cryptosystem" as follows:

Role-based cryptosystem is a secure system that uses cryptographic techniques to perform the role-based access control. In addition, several advanced features, such as role's or user's revocation, tracing, and anonymity, are implemented as well. A role-based cryptosystem should be a complete cryptosystem including Role-based Encryption (RBE), Role-Based Signature (RBS), and Role-Based Authentication (RBA).

References