Role-Based Access Control (RBAC) is a nondiscretionary access control mechanism which allows the central security policy
and as such is very suitable to large organizations environment. the concept of the rile is very close to the Unix concept
of a group with two important differences;

Classic Unix permissions model concept of group is a filesystem-centric, while the ocncept of role is operations centric concept.
A unix group is a set of users which are granted a certain rights for a set of objects of the filesystem (files and directories
that are owned by this group). A role is more process-oriented view, having more in common how sudo operates
on one hand and how Unix ACLs operate on another.

Group is limited to a predefined set of right (read, write, execute). Role concept is more dynamic and process oriented. It
imply that rights are set of operations on the object which are wider then file permission, and can be created and destroyed and
are not a static set (See Solaris RBAC implementation).

RBAC enables more precise implementation of the Principle of Least Privilege. Subjects may login with most of their roles deactivated,
and activate a role only when a particular right associated with the role is necessary.

With the past noise about SOX compliance one of the few things that would make sense was the implementation of RBAC under the sauce
of SOX compliance. Most of SOX activity resembled Y2K craze and also was equally useless, expensive and superficial
effort that benefited mainly large auditing firms and (to a lesser extent) companies with semi-useless or harmful security products.
But good managers have has a unique opportunity to play their cards more intelligently and persuade upper-level PHBs to implement RBAC
as panacea against all SOX-defined ills. Persuading higher level managers to implement RBAC under SOX-compliance sauce was actually
relatively easy as SOX did not even specify what are "adequate internal control", nor which solutions organizations must implement
in order to meet this particular requirement. In this case using RMAC as "adequate integral control" solution makes a lot of sense.

This opportunity to implement RBAC is now a water under the bridge but that does not mean that such opportunities will never arise
again. This page tries to point you to the relevant resources. Solaris 10 and 11 has RBAC built-in, but other commercial Unixes have
now implementation too (AIX 6 is one example).

Role-based access control (RBAC) was introduced in 1992 by David Ferraiolo and Rick Kuhn of the NIST. In April of 2004 the American
National Standards Institute approved Standard 359-2004: American National Standard for Information Technology—Role Based Access Control.
NIST maintains a Web site dedicated to RBAC at
http://csrc.nist.gov/rbac. There are two
key principles of role-based access control:

Granting of access is based on the user’s role rather than his or her identity. A user has access rights and privileges
based on the assigned role.

Roles define access rights and privileges based on job authority and responsibilities within a job function. Permissions
are grouped by role name.

From the point of view of security theory RBAC bases access control decisions on the functions a user is allowed to perform within
an organization. The users cannot pass access permissions on to other users at their discretion. This is
a fundamental difference between RBAC and DAC. That means that RBAC is in fact a form of mandatory access control, but
unlike a typical MAC environment it is not based on multilevel security requirements (clearances and security labels). As defined in
the TCSEC, MAC is:

A means of restricting access to objects based on the sensitivity (as represented by a label) of
the information contained in the objects and the formal authorization (i.e. clearance) of subjects to access information of such
sensitivity. [Orangebook]

RBAC can lower the cost and complexity of security administration of large servers. RBAC organize privileges into roles.

In large organizations, the application owners do not "own'' the information of the application for which he/she
is responsible. For these organizations, the corporation itself or even some government agency is the actual "owner'' of system objects
and application owner is simply a custodian.

The act of granting membership and specifying transactions for a role is loosely analogous to the process of clearing users
(granting membership)and the labeling (association of operational sensitivities) of objects.

Unlike MAC where the main focus is on capability: who can read what information within a role-based system, the principal concern
in RBAC is protecting the integrity of information: "who can perform what actions on what information''

A role can be thought of as a set of transactions that a user or set of users can perform within the context of an organization.
Membership in a role is granted and revoked by a system administrator.

Roles are group oriented; the simplest model of roles is probably Unix groups implementation

The key questions here are:

Can roles be hierarchical (in Unix groups the answer is no).

What privileges can be assigned or revoked (in Unix group only regular RWX privileges.

What is the logging mechanism used for switching into the role and switching back to your original identity.

To date, these role based systems have been mainly developed for use by military and intelligence. Trusted Solaris was workhorse
of military since its Solaris 8. But the most robust implementation is provided by Solaris 10 which can be considered a classic implementation
of RBAC in Unix systems.

Despite long history there is no commonly agreed upon definitions or recognition of formal standards, although Solaris 10 implementation
serves as de-facto standard.

The Sarbanes-Oxley Act establishes a set of requirements
for financial systems, to deter fraud and increase corporate accountability. For information technology systems, regulators
may need to know who used a system, when they logged in and out, what accesses or modifications were made to what files, and what
authorizations were in effect. IT vendors responding to Sarbanes-Oxley requirements have adopted RBAC as central to
compliance solutions because RBAC was designed to solve this type of problem.

This document is merely a re-sorting of the “Principles” output from the NAC 2001 Fall conference,
which will hopefully act as a starting point to more comprehensive documentation. The conference material did not contain
all of the “principles” that may apply to RBAC, but there were also some good ideas expressed in the contents that were not “principles”
as well. This document re-sorts the conference document into “RBAC Principles” items and “Role Engineering Best Practices”
items for further discussion.

Definitions:Principle: A “principle”, as used in this context, is a constant (some might call a “rule”) that
defines a particular behavior or characteristic that any RBAC system must include, exhibit or comply with.

Best Practice: A “best practice” can be an insight based on experience, a recommendation based
on research, or even an opinion based on sound reasoning. In this case, certain “best practices” for role engineering or role
discovery were contained within the NAC conference “Principle” document.

Principles:1.
The RBAC system must delineate users, roles, and permissions.

2.
A user can be assigned to multiple roles.

3.
The system must support the notion of “Separation of Duty “ constraints.

4.
Must leverage existing standards to the extent possible.

5.
An inheritance model must be supported so that a role can inherit rights other roles .

6.
The permission with the least privilege applies, in cases where a user is assigned to multiple roles, and two or more roles
define a permission on the same object.

7.
The system must log changes to role assignments.

8.
The system must provide an aggregated view of all permissions assigned to a particular user.

9.
The system must provide a view of all users assigned to a particular permission.

110.
There must be an administrative interface to add/change/delete roles, permissions and users – as well as the assignments
of permissions to roles and roles to users.

111.
A role should be able to map to one or more “groups” on one or more target systems.

112.
”Users” can be people, applications, devices or functions.

Best Practices for Role Engineering:

1.
Roles are abstractions of system entitlements that consider two design criteria:

Consolidation of entities into meaningful groups that facilitate ease of administration.

Collections of permissions that are meaningful to specific user communities

2.
There are three basic approaches to role engineering:

“Bottom Up”: which derives roles from the groups and permissions defined on the existing systems
and platforms in the enterprise.

“Top Down”: which derives roles from an analysis of business function and organizational criteria,
typically from a “zero base” starting point.

“Hybrid”: which, as the name implies, derives roles using a combination of bottom up and top
down approaches.

3.
The top down approach typically is much more difficult to implement, because it will probably result in significant changes
to legacy group and permission models.

4.
The bottom up approach is typically easier to implement, because the RBAC system will overlay the legacy group and permission
models.

5.
A successful role definition approach will likely be a hybrid approach

6.
The objective of role modeling is to maximize flexibility with minimal administrative effort.

7.
Role engineering should consider how role and user administration is to be delegated. More decentralized models benefit
from more top down analysis.

8.
Top down role engineering will aggregate business processes into organizational parameters.

9.
A top down approach can only be successful with participation and buy-in from business units.

110.
A role typically maps to a group on a legacy system.

111.
Successful implementation of RBAC benefits from a cultural commitment to define common roles that supercede individual privileges.

112.
Roles do not have meaning unless they are used to define access privileges.

FAIR USE NOTICE This site contains
copyrighted material the use of which has not always been specifically
authorized by the copyright owner. We are making such material available
in our efforts to advance understanding of environmental, political,
human rights, economic, democracy, scientific, and social justice
issues, etc. We believe this constitutes a 'fair use' of any such
copyrighted material as provided for in section 107 of the US Copyright
Law. In accordance with Title 17 U.S.C. Section 107, the material on
this site is distributed without profit exclusivly for research and educational purposes. If you wish to use
copyrighted material from this site for purposes of your own that go
beyond 'fair use', you must obtain permission from the copyright owner.

ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no
less then 90 days. Multiple types of probes increase this period.

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.

Original materials copyright belong
to respective owners. Quotes are made for educational purposes only
in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains
copyrighted material the use of which has not always been specifically
authorized by the copyright owner. We are making such material available
to advance understanding of computer science, IT technology, economic, scientific, and social
issues. We believe this constitutes a 'fair use' of any such
copyrighted material as provided by section 107 of the US Copyright Law according to which
such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free)
site written by people for whom English is not a native language. Grammar and spelling errors should
be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development
of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info

Disclaimer:

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 author present and former employers, SDNP or any other organization the author may be associated with.We do not warrant the correctness
of the information provided or its fitness for any purpose.