What is a role ?

This is perhaps the most fundamental question that can be raised for role-based access control (RBAC). The concept of a role originated in social psychology and sociology long before the advent of computer. Even in the context of modern information systems, roles have significance beyond their application in security and access control.

RBAC considers role as a purely access control mechanism as opposed to the more complex organizational context in which roles arise.  that means that the role is always incomplete and is it difficult to get an accurate approximation of real organizational role in RBAC.

Roles and Unix Groups

Early timesharing operating systems introduced the notion of a group of users which can occur as a single entity in access control lists, thereby conferring the associated permissions to all members of the group. Groups have since become commonplace in operating systems, including the most recent ones. It is often perceived that groups can serve the same purpose as roles, and perhaps RBAC is simply inventing a new term for an old idea. There was extensive discussion of this issue

Are negative permissions useful for RBAC

Permissions are usually positive in that a permission confers the ability to do something. Negative permissions (or denials), on the other hand, deny abilities. Negative permissions are sometimes used in combination with positive permissions. A typical example is that a group of users is given a positive permission but some members of the group are given a corresponding negative permission so these users do not inherit the positive permission from the group. Negative permissions introduce several complications in determining whether or not a particular access is permitted. RBAC models can accommodate the useful aspects of negative permissions by means of constraints. The question is whether negative permissions are useful in RBAC as an alternative to constraints, or perhaps for some other purpose.

Should duties or obligations be considered part of RBAC?

Access control is concerned with whether or not operations invoked by active entities such as users should be permitted to occur. Duties (or obligations) on the other hand require a user (or other active agent) to perform some operations in the system.

Duties have not been part of traditional access control, but perhaps in context of RBAC they need to be considered. The general opinion at the workshop was in favor of keeping non-access control issues such as duties outside the scope of RBAC.

This is consistent with the discussion on question 1 above.

5. What is the relationship of RBAC to enterprise models?

It is anticipated that roles will arise naturally in enterprise models. However, the scope of roles in enterprise models extends beyond their use for access control (as discussed in context of questions 1 and 4 above). An enterprise model that incorporates roles would be useful in designing roles for access control purposes, but RBAC models have a much narrower scope than enterprise models.

What is the nature of permissions
 and operations mediated by RBAC?

The nature of permissions and operations mediated by RBAC depends on the nature of the system in which RBAC is embedded. Operating systems usually control permissions such as read, write and execute on files. RBAC is useful at the level of these primitive permissions. However, RBAC has potentially even greater benefit if it can be applied at the level of abstract application-oriented operations such as credit and debit operations on an account. Credit and debit both require read and write access to the account balance, so they cannot be distinguished if protection is provided only in terms of read and write. On the other hand, the credit and debit operations themselves must be programmed as part of the application. There are several techniques which allow the program implementing a credit (or debit) operation to execute with different permissions than directly available to the user who invokes that program. Operating systems and database management systems should provide facilities for application programmers to effectively build such application programs that embody abstract application-level operations and to protect these by means of RBAC.

What is the relationship between
roles and stored procedures?

Stored procedures are one technique by which application programs that implement abstract operations, such as credit or debit, can be executed with different permissions than the user invoking the operation (see discussion for question 6). Stored procedures usually execute with the permissions of the owner of the procedure. Would it be useful to allow stored procedures to be assigned roles from which they inherit permissions? How can a stored procedure base its access decisions onroles that the invoking user has activated?

Composite roles: should a user be allowed
 to take on multiple roles
 in a single session and if so, how?

Some systems allow a user to simultaneously take on multiple roles in a session, while others allow the user to assume only one role at a time. If multiple simultaneous roles are allowed, some systems turn on all roles of the user while others allow the user to select which roles are turned on in a particular session. (There is an analogous situation with respect to groups in operating systems.)

Systems implementations tend to hard-wire one of these alternatives. Sometimes a limited choice is provided between these options which must be selected when the system is installed. It was argued that systems should permit flexibility in this matter and allow constraints to be imposed as desired by the system owners.

Should a user be allowed
 to take on multiple simultaneous sessions?

Some systems allow a user to establish multiple simultaneous sessions, others do not. Multiple sessions are useful in modern computing systems where each session can be mapped to a different window on the user's display. From an access-control viewpoint, multiple sessions with different roles activated by the same user in different sessions support the principle of least privilege.

As for question 8, it was felt that systems should be flexible and allow constraints to be imposed if appropriate.10. How should roles be delegated? A user may choose to delegate one or more roles to another user. This might be for a limited period of time, such as a vacation, or under specified circumstances, such as when the former user is unavailable. Information systems should provide for flexibility in such matters otherwise users will perceive security to be a hindrance and bypass it. There may also be a need for a program to delegate roles to another program in order to obtain appropriate services on behalf of a user.

How do we enforce RBAC in information systems involving multiple organizations?

There are numerous issues that need to be addressed in this context. Most of the discussion at the workshop focused on the context of a single system. Inter-organizational issues will need to be considered as RBAC matures.

What is the relationship between RBAC and users, principals, subjects, and automated agents (all of which can potentially be members of a role)?

The access control literature distinguishes the notion of a user from that of a subject. An individual human user may be manifested in the system as multiple subjects each having different permissions. For example, a top-secret user may have a top-secret subject as well as an unclassified subject acting on the user's behalf. Similarly, an individual user may have different subjects depending upon the project the user is working on indifferent sessions. The term principal has been used in access control to include users and other intelligent agents.

Can roles be assigned to each of these access control entities?

Do we need to distinguish human users from automated agents for the purpose of RBAC?

How do we ensure that an individual human being does not appear as multiple users (so as to enforce strict separation of privileges)?

How do we use role classes, object classes, object instances, and role affiliations in designing effective RBAC?

This question addresses the issue of role engineering, that is, how do we define an appropriate set of roles for an organization. For example, the concept of a bank teller is a generic one that applies to many branches of a bank. Bank teller could be a role class and a role affiliation could be the assignment of a teller to a particular branch. Similarly, a particular kind of loan could be an object class with various instances corresponding to individual loan accounts.

Should RBAC encompass temporal and other dependencies between authorizations?

Temporal dependencies between authorizations arise when one step must be completed before the next can begin. For example, an employment verification is required prior to approval of a loan. Certain roles are authorized to perform employment verification and others to perform the loan approval. Nevertheless, for each loan these two steps must occur in sequence. Temporal dependencies of this nature are a common feature in business procedures. It's unclear are such dependencies inside the scope of RBAC or not.

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019