Author: olamy
Date: Tue Jan 15 18:01:09 2013
New Revision: 1433557
URL: http://svn.apache.org/viewvc?rev=1433557&view=rev
Log:
Apache Redback Main site deployment
Modified:
archiva/site-content/redback/configuration.html
archiva/site-content/redback/rbac/introduction.html
Modified: archiva/site-content/redback/configuration.html
URL:
http://svn.apache.org/viewvc/archiva/site-content/redback/configuration.html?rev=1433557&r1=1433556&r2=1433557&view=diff
==============================================================================
--- archiva/site-content/redback/configuration.html (original)
+++ archiva/site-content/redback/configuration.html Tue Jan 15 18:01:09 2013
@@ -211,7 +211,7 @@ pageTracker._trackPageview();</script>
<property name="registry"
ref="registry#commons-configuration"/>
</bean>
-</pre></div></div><div class="section"><h3>Configuration Options<a
name="Configuration_Options"></a></h3><div class="section"><h4>Application
Configuration<a
name="Application_Configuration"></a></h4><ul><li>application.timestamp=EEE d
MMM yyyy HH:mm:ss
Z</li><li>application.url=http://myurl.mycompany.com<ul><li>Set the application
base URL. The default is to derive it from the HTTP
request</li></ul></li></ul></div><div class="section"><h4>JDBC Setup<a
name="JDBC_Setup"></a></h4><p>By default Redback uses Apache Derby for
persistence of user and role information. This can be configured with the
following
options.</p><ul><li>jdbc.driver.name=org.apache.derby.jdbc.EmbeddedDriver</li><li>jdbc.url=jdbc:derby:$<a
name="plexus.home">plexus.home</a>/database;create=true</li><li>jdbc.username=sa</li><li>jdbc.password=</li></ul><p>By
default Redback uses Apache Derby for persistence of user and role
information. This can be configured with the following
options.</p><p><b>Note:</b> If
you are using MySQL as your database, the database will not be populated if
the encoding is initially set to UTF-8. As a workaround, set the database to
UTF-8 encoding after it has been populated. See <a class="externalLink"
href="http://jira.codehaus.org/browse/REDBACK-267";> REDBACK-267</a> for more
details.</p></div><div class="section"><h4>Email Settings<a
name="Email_Settings"></a></h4><ul><li>email.jndiSessionName=java:comp/env/mail/Session</li><li>email.smtp.host=localhost</li><li>email.smtp.port=25</li><li>email.smtp.ssl.enabled=false</li><li>email.smtp.tls.enabled=false</li><li>email.smtp.username=</li><li>email.smtp.password=</li><li>email.from.address=$<a
name="user.name">user.name</a>@localhost<ul><li>All emails sent by the system
will be from the following
address</li></ul></li><li>email.from.name=Unconfigured
Username</li><li>email.validation.required=true<ul><li>If all email addresses
(from new user registration) require an account validation email. </li></ul>
</li><li>email.validation.timeout=2880<ul><li>Timeout (in minutes) for the key
generated for an email validation to remain valid.</li><li>2880 minutes = 48
hours</li></ul></li><li>email.validation.subject=Welcome</li><li>email.feedback.path=/feedback.action<ul><li>Get
the Feedback to use for any outgoing emails.</li><li>Feedback path starts with
a "/" it is appended to the end of the value provided in
application.url. This value can be in the format/syntax of
"/feedback.action" or even
"mailto:[email protected]"</li></ul></li></ul></div><div
class="section"><h4>Auto Login Settings<a
name="Auto_Login_Settings"></a></h4><ul><li>security.rememberme.enabled=true</li><li>security.rememberme.timeout=525600<ul><li>Timeout
in minutes ( 525600 minutes = 1 year
)</li></ul></li><li>security.signon.timeout=30<ul><li>Single Sign
On</li><li>Timeout is in minutes</li></ul></li></ul></div><div
class="section"><h4>Default Username Values<a name="Default_U
sername_Values"></a></h4><ul><li>redback.default.admin=admin<ul><li>name for
the admin user, by default this is 'admin' and can not easily be changed after
the fact at this point. However any number of people may be assigned full
administrator roles.</li></ul></li><li>redback.default.guest=guest (currently
guest is an hardcoded value so not possible to configure it)<ul><li>name of the
guest user</li></ul></li></ul></div><div class="section"><h4>Security
Policies<a
name="Security_Policies"></a></h4><ul><li>security.policy.password.encoder=</li><li>security.policy.password.previous.count=6</li><li>security.policy.password.expiration.enabled=true</li><li>security.policy.password.expiration.days=90</li><li>security.policy.password.expiration.notify.days=10</li><li>security.policy.allowed.login.attempt=10</li><li>security.policy.strict.enforcement.enabled=true<ul><li>turn
off the perclick enforcement of various security policies, slightly more
heavyweight since it will ensure tha
t the User object on each click is up to
date</li></ul></li><li>security.policy.strict.force.password.change.enabled=true<ul><li>forces
the user to change their password immediately should their account be flagged
for a password
change.</li></ul></li><li>security.policy.unlockable.accounts<ul><li>can be
specified multiple times to ensure that password policies never lock the
specified account(s) (eg. security.policy.unlockable.accounts=guest
)</li></ul></li></ul></div><div class="section"><h4>Password Rules<a
name="Password_Rules"></a></h4><ul><li>security.policy.password.rule.alphanumeric.enabled=false</li><li>security.policy.password.rule.alphacount.enabled=true</li><li>security.policy.password.rule.alphacount.minimum=1</li><li>security.policy.password.rule.characterlength.enabled=true</li><li>security.policy.password.rule.characterlength.minimum=1</li><li>security.policy.password.rule.characterlength.maximum=24</li><li>security.policy.password.rule.musthave.enabled=true</
li><li>security.policy.password.rule.numericalcount.enabled=true</li><li>security.policy.password.rule.numericalcount.minimum=1</li><li>security.policy.password.rule.reuse.enabled=true</li><li>security.policy.password.rule.nowhitespace.enabled=true</li></ul></div><div
class="section"><h4>LDAP settings<a name="LDAP_settings"></a></h4><p>Ldap can
be used as a readonly user manager, however the role assignment is still
managed entirely within the given database store. This should be fixed in the
future sometime but likely not before ldap is switched over as the default user
and role store
entirely.</p><ul><li>ldap.user.store.enabled=false</li><li>ldap.bind.authenticator.enabled=false</li></ul><div
class="section"><h5>ldap options for configuration via properties file<a
name="ldap_options_for_configuration_via_properties_file"></a></h5><ul><li>ldap.config.hostname=</li><li>ldap.config.port=</li><li>ldap.config.base.dn=</li><li>ldap.config.context.factory=</li><li>ldap.config.bin
d.dn=</li><li>ldap.config.password=</li><li>ldap.config.authentication.method=</li><li>ldap.config.groups.class=
object class for groups (default:
groupOfUniqueNames)</li><li>ldap.config.groups.base.dn= basedn for
groups</li><li>ldap.config.groups.base.dn= dn with list of groups
dc=archiva,dc=apache,dc=org</li><li>ldap.config.groups.role.*(ldap
group)=*(role) (mapping ldap group <i>-</i> redback role) (example:
ldap.config.groups.role.archiva-admin=Archiva System
Administrator)</li></ul></div></div><div class="section"><h4>User Manager
Implementation(s) to use<a
name="User_Manager_Implementations_to_use"></a></h4><ul><li>user.manager.impl=cached
(since 1.4-M4: Archiva support more than one value comma
separated)<ul><li>valid values for realistic usage are 'cached' and then
further configuring the cached instance to use another underlying user manager
like ldap or the jdo one which is used by default. Placing 'ldap' here will
check with the ldap system for a fair amount of ch
ecks and would likely be a performance
issue</li></ul></li></ul></div></div></div>
+</pre></div></div><div class="section"><h3>Configuration Options<a
name="Configuration_Options"></a></h3><div class="section"><h4>Application
Configuration<a
name="Application_Configuration"></a></h4><ul><li>application.timestamp=EEE d
MMM yyyy HH:mm:ss
Z</li><li>application.url=http://myurl.mycompany.com<ul><li>Set the application
base URL. The default is to derive it from the HTTP
request</li></ul></li></ul></div><div class="section"><h4>JDBC Setup<a
name="JDBC_Setup"></a></h4><p>By default Redback uses Apache Derby for
persistence of user and role information. This can be configured with the
following
options.</p><ul><li>jdbc.driver.name=org.apache.derby.jdbc.EmbeddedDriver</li><li>jdbc.url=jdbc:derby:$<a
name="plexus.home">plexus.home</a>/database;create=true</li><li>jdbc.username=sa</li><li>jdbc.password=</li></ul><p>By
default Redback uses Apache Derby for persistence of user and role
information. This can be configured with the following
options.</p><p><b>Note:</b> If
you are using MySQL as your database, the database will not be populated if
the encoding is initially set to UTF-8. As a workaround, set the database to
UTF-8 encoding after it has been populated. See <a class="externalLink"
href="http://jira.codehaus.org/browse/REDBACK-267";> REDBACK-267</a> for more
details.</p></div><div class="section"><h4>Email Settings<a
name="Email_Settings"></a></h4><ul><li>email.jndiSessionName=java:comp/env/mail/Session</li><li>email.smtp.host=localhost</li><li>email.smtp.port=25</li><li>email.smtp.ssl.enabled=false</li><li>email.smtp.tls.enabled=false</li><li>email.smtp.username=</li><li>email.smtp.password=</li><li>email.from.address=$<a
name="user.name">user.name</a>@localhost<ul><li>All emails sent by the system
will be from the following
address</li></ul></li><li>email.from.name=Unconfigured
Username</li><li>email.validation.required=true<ul><li>If all email addresses
(from new user registration) require an account validation email. </li></ul>
</li><li>email.validation.timeout=2880<ul><li>Timeout (in minutes) for the key
generated for an email validation to remain valid.</li><li>2880 minutes = 48
hours</li></ul></li><li>email.validation.subject=Welcome</li><li>email.feedback.path=/feedback.action<ul><li>Get
the Feedback to use for any outgoing emails.</li><li>Feedback path starts with
a "/" it is appended to the end of the value provided in
application.url. This value can be in the format/syntax of
"/feedback.action" or even
"mailto:[email protected]"</li></ul></li></ul></div><div
class="section"><h4>Auto Login Settings<a
name="Auto_Login_Settings"></a></h4><ul><li>security.rememberme.enabled=true</li><li>security.rememberme.timeout=525600<ul><li>Timeout
in minutes ( 525600 minutes = 1 year
)</li></ul></li><li>security.signon.timeout=30<ul><li>Single Sign
On</li><li>Timeout is in minutes</li></ul></li></ul></div><div
class="section"><h4>Default Username Values<a name="Default_U
sername_Values"></a></h4><ul><li>redback.default.admin=admin<ul><li>name for
the admin user, by default this is 'admin' and can not easily be changed after
the fact at this point. However any number of people may be assigned full
administrator roles.</li></ul></li><li>redback.default.guest=guest (currently
guest is an hardcoded value so not possible to configure it)<ul><li>name of the
guest user</li></ul></li></ul></div><div class="section"><h4>Security
Policies<a
name="Security_Policies"></a></h4><ul><li>security.policy.password.encoder=</li><li>security.policy.password.previous.count=6</li><li>security.policy.password.expiration.enabled=true</li><li>security.policy.password.expiration.days=90</li><li>security.policy.password.expiration.notify.days=10</li><li>security.policy.allowed.login.attempt=10</li><li>security.policy.strict.enforcement.enabled=true<ul><li>turn
off the perclick enforcement of various security policies, slightly more
heavyweight since it will ensure tha
t the User object on each click is up to
date</li></ul></li><li>security.policy.strict.force.password.change.enabled=true<ul><li>forces
the user to change their password immediately should their account be flagged
for a password
change.</li></ul></li><li>security.policy.unlockable.accounts<ul><li>can be
specified multiple times to ensure that password policies never lock the
specified account(s) (eg. security.policy.unlockable.accounts=guest
)</li></ul></li></ul></div><div class="section"><h4>Password Rules<a
name="Password_Rules"></a></h4><ul><li>security.policy.password.rule.alphanumeric.enabled=false</li><li>security.policy.password.rule.alphacount.enabled=true</li><li>security.policy.password.rule.alphacount.minimum=1</li><li>security.policy.password.rule.characterlength.enabled=true</li><li>security.policy.password.rule.characterlength.minimum=1</li><li>security.policy.password.rule.characterlength.maximum=24</li><li>security.policy.password.rule.musthave.enabled=true</
li><li>security.policy.password.rule.numericalcount.enabled=true</li><li>security.policy.password.rule.numericalcount.minimum=1</li><li>security.policy.password.rule.reuse.enabled=true</li><li>security.policy.password.rule.nowhitespace.enabled=true</li></ul></div><div
class="section"><h4>LDAP settings<a name="LDAP_settings"></a></h4><p>Ldap can
be used as a readonly user manager, however the role assignment is still
managed entirely within the given database store. This should be fixed in the
future sometime but likely not before ldap is switched over as the default user
and role store
entirely.</p><ul><li>ldap.user.store.enabled=false</li><li>ldap.bind.authenticator.enabled=false</li></ul><div
class="section"><h5>ldap options for configuration via properties file<a
name="ldap_options_for_configuration_via_properties_file"></a></h5><ul><li>ldap.config.hostname=</li><li>ldap.config.port=</li><li>ldap.config.base.dn=</li><li>ldap.config.context.factory=</li><li>ldap.config.bin
d.dn=</li><li>ldap.config.password=</li><li>ldap.config.authentication.method=</li><li>ldap.config.groups.class=
object class for groups (default:
groupOfUniqueNames)</li><li>ldap.config.groups.base.dn= basedn for
groups</li><li>ldap.config.groups.base.dn= dn with list of groups
dc=archiva,dc=apache,dc=org</li><li>ldap.config.groups.role.*(ldap
group)=*(role) (mapping ldap group <i>-</i> redback role) (example:
ldap.config.groups.role.archiva-admin=Archiva System
Administrator)</li></ul></div></div><div class="section"><h4>User Manager
Implementation(s) to use<a
name="User_Manager_Implementations_to_use"></a></h4><ul><li>user.manager.impl=cached
(since 1.4-M4: Archiva support more than one value comma
separated)<ul><li>valid values for realistic usage are 'cached' and then
further configuring the cached instance to use another underlying user manager
like ldap or the jdo one which is used by default. Placing 'ldap' here will
check with the ldap system for a fair amount of ch
ecks and would likely be a performance issue</li></ul></li></ul></div><div
class="section"><h4>RBAC Manager Implementation(s) to use<a
name="RBAC_Manager_Implementations_to_use"></a></h4><ul><li>rbac.manager.impl=cached
(since 1.4-M4: Archiva support more than one value comma
separated)</li></ul></div></div></div>
</div>
</div>
Modified: archiva/site-content/redback/rbac/introduction.html
URL:
http://svn.apache.org/viewvc/archiva/site-content/redback/rbac/introduction.html?rev=1433557&r1=1433556&r2=1433557&view=diff
==============================================================================
--- archiva/site-content/redback/rbac/introduction.html (original)
+++ archiva/site-content/redback/rbac/introduction.html Tue Jan 15 18:01:09 2013
@@ -199,7 +199,7 @@ pageTracker._trackPageview();</script>
<div id="bodyColumn" >
- <!-- Licensed to the Apache Software Foundation (ASF) under one
--><!-- or more contributor license agreements. See the NOTICE file --><!--
distributed with this work for additional information --><!-- regarding
copyright ownership. The ASF licenses this file --><!-- to you under the
Apache License, Version 2.0 (the --><!-- "License"); you may not use this file
except in compliance --><!-- with the License. You may obtain a copy of the
License at --><!-- --><!-- http://www.apache.org/licenses/LICENSE-2.0 --><!--
--><!-- Unless required by applicable law or agreed to in writing, --><!--
software distributed under the License is distributed on an --><!-- "AS IS"
BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY --><!-- KIND, either express or
implied. See the License for the --><!-- specific language governing
permissions and limitations --><!-- under the License. --><!-- NOTE: For help
with the syntax of this file, see: --><!-- http://maven.apache.org/guides/mi
ni/guide-apt-format.html --><div class="section"><h2>An Introduction to Role
Based Access<a name="An_Introduction_to_Role_Based_Access"></a></h2><p>This
introduction provides background information on Role-Based Access Control
(RBAC), a technical means for controlling access to computer resources. While
still largely in the demonstration and prototype stages of development, RBAC
appears to be a promising method for controlling what information computer
users can utilize, the programs that they can run, and the modifications that
they can make. Only a few off-the-shelf systems that implement RBAC are
commercially available; however, organizations may want to start investigating
RBAC for future application in their multi-user systems. RBAC is appropriate
for consideration in systems that process unclassified but sensitive
information, as well as those that process classified
information.</p></div><div class="section"><h2>What is Role-Based Access
Control<a name="What_is_Role-B
ased_Access_Control"></a></h2><p>Access is the ability to do something with a
computer resource (e.g., use, change, or view). Access control is the means by
which the ability is explicitly enabled or restricted in some way (usually
through physical and system-based controls). Computer- based access controls
can prescribe not only who or what process may have access to a specific system
resource, but also the type of access that is permitted. These controls may be
implemented in the computer system or in external devices.</p><p>With
role-based access control, access decisions are based on the roles that
individual users have as part of an organization. Users take on assigned roles
(such as doctor, nurse, teller, manager). The process of defining roles should
be based on a thorough analysis of how an organization operates and should
include input from a wide spectrum of users in an organization.</p><p>Access
rights are grouped by role name, and the use of resources is restrict
ed to individuals authorized to assume the associated role. For example,
within a hospital system the role of doctor can include operations to perform
diagnosis, prescribe medication, and order laboratory tests; and the role of
researcher can be limited to gathering anonymous clinical information for
studies.</p><p>The use of roles to control access can be an effective means for
developing and enforcing enterprise-specific security policies, and for
streamlining the security management process.</p></div><div
class="section"><h2>Users and Roles<a name="Users_and_Roles"></a></h2><p>Under
the RBAC framework, users are granted membership into roles based on their
competencies and responsibilities in the organization. The operations that a
user is permitted to perform are based on the user's role. User membership into
roles can be revoked easily and new memberships established as job assignments
dictate. Role associations can be established when new operations are
instituted, and
old operations can be deleted as organizational functions change and evolve.
This simplifies the administration and management of privileges; roles can be
updated without updating the privileges for every user on an individual
basis.</p><p>When a user is associated with a role:</p><p>the user can be given
no more privilege than is necessary to perform the job. This concept of least
privilege requires identifying the user's job functions, determining the
minimum set of privileges required to perform that function, and restricting
the user to a domain with those privileges and nothing more. In less precisely
controlled systems, this is often difficult or costly to achieve. Someone
assigned to a job category may be allowed more privileges than needed because
is difficult to tailor access based on various attributes or constraints. Since
many of the responsibilities overlap between job categories, maximum privilege
for each job category could cause unlawful access.</p></div><di
v class="section"><h2>Roles and Role Hierarchies<a
name="Roles_and_Role_Hierarchies"></a></h2><p>Under RBAC, roles can have
overlapping responsibilities and privileges; that is, users belonging to
different roles may need to perform common operations. Some general operations
may be performed by all employees. In this situation, it would be inefficient
and administratively cumbersome to specify repeatedly these general operations
for each role that gets created. Role hierarchies can be established to provide
for the natural structure of an enterprise. A role hierarchy defines roles that
have unique attributes and that may contain other roles; that is, one role may
implicitly include the operations that are associated with another
role.</p><p>In the healthcare situation, a role Specialist could contain the
roles of Doctor and Intern. This means that members of the role Specialist are
implicitly associated with the operations associated with the roles Doctor and
Intern without
the administrator having to explicitly list the Doctor and Intern operations.
Moreover, the roles Cardiologist and Rheumatologist could each contain the
Specialist role.</p><p>Role hierarchies are a natural way of organizing roles
to reflect authority, responsibility, and competency:</p><p>the role in which
the user is gaining membership is not mutually exclusive with another role for
which the user already possesses membership. These operations and roles can be
subject to organizational policies or constraints. When operations overlap,
hierarchies of roles can be established. Instead of instituting costly auditing
to monitor access, organizations can put constraints on access through RBAC.
For example, it may seem sufficient to allow physicians to have access to all
patient data records if their access is monitored carefully. With RBAC,
constraints can be placed on physician access so that only those records that
are associated with a particular physician can be accessed.</
p></div><div class="section"><h2>Roles and Operations<a
name="Roles_and_Operations"></a></h2><p>Organizations can establish the rules
for the association of operations with roles. For example, a healthcare
provider may decide that the role of clinician must be constrained to post only
the results of certain tests but not to distribute them where routing and human
errors could violate a patient's right to privacy. Operations can also be
specified in a manner that can be used in the demonstration and enforcement of
laws or regulations. For example, a pharmacist can be provided with operations
to dispense, but not to prescribe, medication.</p><p>An operation represents a
unit of control that can be referenced by an individual role, subject to
regulatory constraints within the RBAC framework. An operation can be used to
capture complex security-relevant details or constraints that cannot be
determined by a simple mode of access.</p><p>For example, there are differences
between t
he access needs of a teller and an accounting supervisor in a bank. An
enterprise defines a teller role as being able to perform a savings deposit
operation. This requires read and write access to specific fields within a
savings file. An enterprise may also define an accounting supervisor role that
is allowed to perform correction operations. These operations require read and
write access to the same fields of a savings file as the teller. However, the
accounting supervisor may not be allowed to initiate deposits or withdrawals
but only perform corrections after the fact. Likewise, the teller is not
allowed to perform any corrections once the transaction has been completed. The
difference between these two roles is the operations that are executed by the
different roles and the values that are written to the transaction log
file.</p><p>The RBAC framework provides administrators with the capability to
regulate who can perform what actions, when, from where, in what order, an
d in some cases under what relational circumstances:</p><p>only those
operations that need to be performed by members of a role are granted to the
role. Granting of user membership to roles can be limited. Some roles can only
be occupied by a certain number of employees at any given period of time. The
role of manager, for example, can be granted to only one employee at a time.
Although an employee other than the manager may act in that role, only one
person may assume the responsibilities of a manager at any given time. A user
can become a new member of a role as long as the number of members allowed for
the role is not exceeded.</p></div><div class="section"><h2>Advantages of
RBAC<a name="Advantages_of_RBAC"></a></h2><p>A properly-administered RBAC
system enables users to carry out a broad range of authorized operations, and
provides great flexibility and breadth of application. System administrators
can control access at a level of abstraction that is natural to the way t
hat enterprises typically conduct business. This is achieved by statically and
dynamically regulating users' actions through the establishment and definition
of roles, role hierarchies, relationships, and constraints. Thus, once an RBAC
framework is established for an organization, the principal administrative
actions are the granting and revoking of users into and out of roles. This is
in contrast to the more conventional and less intuitive process of attempting
to administer lower-level access control mechanisms directly (e.g., access
control lists [ACLs], capabilities, or type enforcement entities) on an
object-by-object basis.</p><p>Further, it is possible to associate the concept
of an RBAC operation with the concept of "method" in Object
Technology. This association leads to approaches where Object Technology can be
used in applications and operating systems to implement an RBAC
operation.</p><p>For distributed systems, RBAC administrator responsibilities
can
be divided among central and local protection domains; that is, central
protection policies can be defined at an enterprise level while leaving
protection issues that are of local concern at the organizational unit level.
For example, within a distributed healthcare system, operations that are
associated with healthcare providers may be centrally specified and pertain to
all hospitals and clinics, but the granting and revoking of memberships into
specific roles may be specified by administrators at local sites.</p></div><div
class="section"><h2>Status of Current RBAC Activities<a
name="Status_of_Current_RBAC_Activities"></a></h2><p>Several organizations are
experimenting with the inclusion of provisions for RBAC in open consensus
specifications. RBAC is an integral part of the security models for Secure
European System for Applications in a Multi-vendor Environment (SESAME)
distributed system and the database language SQL3. In addition, the Object
Management Group's (OMG) C
ommon Object Request Broker Architecture (CORBA) Security specification uses
RBAC as an example of an access control mechanism which can be used with the
distributed Object Technology defined by the OMG. (See reference
below.)</p><p>CSL has been developing and defining RBAC and its applicability
cooperatively with industry, government, and academic partners. In conjunction
with Dr. Ravi Sandhu of George Mason University and Seta Corporation, CSL is
defining RBAC and its feasibility. We are working with Dr. Virgil Gligor and
his associates at the University of Maryland and with the National Security
Agency (NSA) to develop a formal reference model for RBAC to provide a safe,
effective, and consistent mechanism for access control. This effort is also
implementing RBAC on NSA's Synergy Platform, a secure platform based on the
Mach Operating System. CSL is also developing a demonstration of RBAC use in
healthcare. The access policy used in this demonstration is based on a draft
consensus policy for patient record access developed in the United Kingdom. In
conjunction with the Internal Revenue Service (IRS), CSL is defining roles and
operations suitable for the IRS environment. In conjunction with the Veterans
Administration (VA), CSL is studying the applicability of RBAC to VA
systems.</p><p>Based on current research and experience, RBAC appears to fit
well into the widely varying security policies of industry and government
organizations.</p><p>For additional information on Role-Based Access Control
see:</p><p>http://waltz.ncsl.nist.gov/rbac/</p><p>or contact David Ferraiolo,
[email protected], (301) 975-3046.</p></div><div
class="section"><h2>References<a name="References"></a></h2><p>Department of
Defense, "Trusted Computer Security Evaluation Criteria," DoD
5200.28-STD, 1985.</p><p>David F. Ferraiolo and D. Richard Kuhn,
"Role-Based Access Controls," Proceedings of the 15th NIST-NSA
National Computer Security Conference, B
altimore, Maryland, October 13-16, 1992.</p><p>David F. Ferraiolo, Dennis M.
Gilbert, and Nickilyn Lynch, "An Examination of Federal and Commercial
Access Control Policy Needs," Proceedings of the 16th NIST-NSA National
Computer Security Conference, Baltimore, Maryland, September 20-23,
1993.</p><p>ISO/IEC 9075, (Working Draft) Database Language SQL - Part 2:
Foundation, Document ISO/IEC JTC1/SC21 N9463, March 1995.</p><p>A. Griew and R.
Currell, "A Strategy for Security of the Electronic Patient Record,"
Institute for Health Informatics, Aberystwyth, Draft Version 2.1, March 8,
1995.</p><p>David F. Ferraiolo, Janet A. Cugini, and D. Richard Kuhn,
"Role-Based Access Control (RBAC): Features and Motivations," 11th
Annual Computer Security Applications Proceedings, 1995.</p><p>John Barkley,
"Application Engineering in Health Care," Proceedings of the 2nd
Annual CHIN Summit, 1995.</p><p>CORBA Security Draft, Object Management Group
(OMG)
Document Number 95-9-1, September 1995.</p><p>John Barkley, "Implementing
Role-Based Access Control using Object Technology," First ACM Workshop on
Role-Based Access Control, Gaithersburg, Maryland, November 30-December 1,
1995.</p><p>T. Parker and D. Pinkas, "SESAME Technology Version 3:
Overview,"</p><p>http://www.esat.kuleuven.ac.be/cosic/sesame/doc-txt/overview.txt</p><p>Background
material in a text box in the paper document:</p><p>Access control technology
has evolved from research and development efforts supported by the Department
of Defense (DoD). This research has resulted in two fundamental types of access
control: Discretionary Access Control (DAC) and Mandatory Access Control (MAC).
While initial research and applications addressed preventing the unauthorized
access to classified information, recent applications have applied these
policies to commercial processing environments.</p><p>DAC permits the granting
and revoking of access control pri
vileges to be left to the discretion of the individual users. A DAC mechanism
allows users to grant or revoke access to any of the objects under their
control. As such, users are said to be the owners of the objects under their
control. However, for many organizations, the end users do not own the
information for which they are allowed access. For these organizations, the
corporation or agency is the actual owner of system objects as well as the
programs that process them. Access priorities are controlled by the
organization and are often based on employee functions rather than data
ownership.</p><p>MAC, as defined in the DoD's Trusted Computer Security
Evaluation Criteria (TCSEC), 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."</p><p>These policies
for access control are
not particularly well suited to the requirements of government and industry
organizations that process unclassified but sensitive information. In these
environments, security objectives often support higher-level organizational
policies which are derived from existing laws, ethics, regulations, or
generally accepted practices. Such environments usually require the ability to
control actions of individuals beyond just an individual's ability to access
information according to how that information is labeled based on its
sensitivity.</p></div>
+ <!-- Licensed to the Apache Software Foundation (ASF) under one
--><!-- or more contributor license agreements. See the NOTICE file --><!--
distributed with this work for additional information --><!-- regarding
copyright ownership. The ASF licenses this file --><!-- to you under the
Apache License, Version 2.0 (the --><!-- "License"); you may not use this file
except in compliance --><!-- with the License. You may obtain a copy of the
License at --><!-- --><!-- http://www.apache.org/licenses/LICENSE-2.0 --><!--
--><!-- Unless required by applicable law or agreed to in writing, --><!--
software distributed under the License is distributed on an --><!-- "AS IS"
BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY --><!-- KIND, either express or
implied. See the License for the --><!-- specific language governing
permissions and limitations --><!-- under the License. --><!-- NOTE: For help
with the syntax of this file, see: --><!-- http://maven.apache.org/guides/mi
ni/guide-apt-format.html --><div class="section"><h2>An Introduction to Role
Based Access<a name="An_Introduction_to_Role_Based_Access"></a></h2><p>This
introduction provides background information on Role-Based Access Control
(RBAC), a technical means for controlling access to computer resources. While
still largely in the demonstration and prototype stages of development, RBAC
appears to be a promising method for controlling what information computer
users can utilize, the programs that they can run, and the modifications that
they can make. Only a few off-the-shelf systems that implement RBAC are
commercially available; however, organizations may want to start investigating
RBAC for future application in their multi-user systems. RBAC is appropriate
for consideration in systems that process unclassified but sensitive
information, as well as those that process classified
information.</p></div><div class="section"><h2>What is Role-Based Access
Control<a name="What_is_Role-B
ased_Access_Control"></a></h2><p>Access is the ability to do something with a
computer resource (e.g., use, change, or view). Access control is the means by
which the ability is explicitly enabled or restricted in some way (usually
through physical and system-based controls). Computer- based access controls
can prescribe not only who or what process may have access to a specific system
resource, but also the type of access that is permitted. These controls may be
implemented in the computer system or in external devices.</p><p>With
role-based access control, access decisions are based on the roles that
individual users have as part of an organization. Users take on assigned roles
(such as doctor, nurse, teller, manager). The process of defining roles should
be based on a thorough analysis of how an organization operates and should
include input from a wide spectrum of users in an organization.</p><p>Access
rights are grouped by role name, and the use of resources is restrict
ed to individuals authorized to assume the associated role. For example,
within a hospital system the role of doctor can include operations to perform
diagnosis, prescribe medication, and order laboratory tests; and the role of
researcher can be limited to gathering anonymous clinical information for
studies.</p><p>The use of roles to control access can be an effective means for
developing and enforcing enterprise-specific security policies, and for
streamlining the security management process.</p></div><div
class="section"><h2>Users and Roles<a name="Users_and_Roles"></a></h2><p>Under
the RBAC framework, users are granted membership into roles based on their
competencies and responsibilities in the organization. The operations that a
user is permitted to perform are based on the user's role. User membership into
roles can be revoked easily and new memberships established as job assignments
dictate. Role associations can be established when new operations are
instituted, and
old operations can be deleted as organizational functions change and evolve.
This simplifies the administration and management of privileges; roles can be
updated without updating the privileges for every user on an individual
basis.</p><p>When a user is associated with a role:</p><p>the user can be given
no more privilege than is necessary to perform the job. This concept of least
privilege requires identifying the user's job functions, determining the
minimum set of privileges required to perform that function, and restricting
the user to a domain with those privileges and nothing more. In less precisely
controlled systems, this is often difficult or costly to achieve. Someone
assigned to a job category may be allowed more privileges than needed because
is difficult to tailor access based on various attributes or constraints. Since
many of the responsibilities overlap between job categories, maximum privilege
for each job category could cause unlawful access.</p></div><di
v class="section"><h2>Roles and Role Hierarchies<a
name="Roles_and_Role_Hierarchies"></a></h2><p>Under RBAC, roles can have
overlapping responsibilities and privileges; that is, users belonging to
different roles may need to perform common operations. Some general operations
may be performed by all employees. In this situation, it would be inefficient
and administratively cumbersome to specify repeatedly these general operations
for each role that gets created. Role hierarchies can be established to provide
for the natural structure of an enterprise. A role hierarchy defines roles that
have unique attributes and that may contain other roles; that is, one role may
implicitly include the operations that are associated with another
role.</p><p>In the healthcare situation, a role Specialist could contain the
roles of Doctor and Intern. This means that members of the role Specialist are
implicitly associated with the operations associated with the roles Doctor and
Intern without
the administrator having to explicitly list the Doctor and Intern operations.
Moreover, the roles Cardiologist and Rheumatologist could each contain the
Specialist role.</p><p>Role hierarchies are a natural way of organizing roles
to reflect authority, responsibility, and competency:</p><p>the role in which
the user is gaining membership is not mutually exclusive with another role for
which the user already possesses membership. These operations and roles can be
subject to organizational policies or constraints. When operations overlap,
hierarchies of roles can be established. Instead of instituting costly auditing
to monitor access, organizations can put constraints on access through RBAC.
For example, it may seem sufficient to allow physicians to have access to all
patient data records if their access is monitored carefully. With RBAC,
constraints can be placed on physician access so that only those records that
are associated with a particular physician can be accessed.</
p></div><div class="section"><h2>Roles and Operations<a
name="Roles_and_Operations"></a></h2><p>Organizations can establish the rules
for the association of operations with roles. For example, a healthcare
provider may decide that the role of clinician must be constrained to post only
the results of certain tests but not to distribute them where routing and human
errors could violate a patient's right to privacy. Operations can also be
specified in a manner that can be used in the demonstration and enforcement of
laws or regulations. For example, a pharmacist can be provided with operations
to dispense, but not to prescribe, medication.</p><p>An operation represents a
unit of control that can be referenced by an individual role, subject to
regulatory constraints within the RBAC framework. An operation can be used to
capture complex security-relevant details or constraints that cannot be
determined by a simple mode of access.</p><p>For example, there are differences
between t
he access needs of a teller and an accounting supervisor in a bank. An
enterprise defines a teller role as being able to perform a savings deposit
operation. This requires read and write access to specific fields within a
savings file. An enterprise may also define an accounting supervisor role that
is allowed to perform correction operations. These operations require read and
write access to the same fields of a savings file as the teller. However, the
accounting supervisor may not be allowed to initiate deposits or withdrawals
but only perform corrections after the fact. Likewise, the teller is not
allowed to perform any corrections once the transaction has been completed. The
difference between these two roles is the operations that are executed by the
different roles and the values that are written to the transaction log
file.</p><p>The RBAC framework provides administrators with the capability to
regulate who can perform what actions, when, from where, in what order, an
d in some cases under what relational circumstances:</p><p>only those
operations that need to be performed by members of a role are granted to the
role. Granting of user membership to roles can be limited. Some roles can only
be occupied by a certain number of employees at any given period of time. The
role of manager, for example, can be granted to only one employee at a time.
Although an employee other than the manager may act in that role, only one
person may assume the responsibilities of a manager at any given time. A user
can become a new member of a role as long as the number of members allowed for
the role is not exceeded.</p></div><div class="section"><h2>Advantages of
RBAC<a name="Advantages_of_RBAC"></a></h2><p>A properly-administered RBAC
system enables users to carry out a broad range of authorized operations, and
provides great flexibility and breadth of application. System administrators
can control access at a level of abstraction that is natural to the way t
hat enterprises typically conduct business. This is achieved by statically and
dynamically regulating users' actions through the establishment and definition
of roles, role hierarchies, relationships, and constraints. Thus, once an RBAC
framework is established for an organization, the username administrative
actions are the granting and revoking of users into and out of roles. This is
in contrast to the more conventional and less intuitive process of attempting
to administer lower-level access control mechanisms directly (e.g., access
control lists [ACLs], capabilities, or type enforcement entities) on an
object-by-object basis.</p><p>Further, it is possible to associate the concept
of an RBAC operation with the concept of "method" in Object
Technology. This association leads to approaches where Object Technology can be
used in applications and operating systems to implement an RBAC
operation.</p><p>For distributed systems, RBAC administrator responsibilities
can
be divided among central and local protection domains; that is, central
protection policies can be defined at an enterprise level while leaving
protection issues that are of local concern at the organizational unit level.
For example, within a distributed healthcare system, operations that are
associated with healthcare providers may be centrally specified and pertain to
all hospitals and clinics, but the granting and revoking of memberships into
specific roles may be specified by administrators at local sites.</p></div><div
class="section"><h2>Status of Current RBAC Activities<a
name="Status_of_Current_RBAC_Activities"></a></h2><p>Several organizations are
experimenting with the inclusion of provisions for RBAC in open consensus
specifications. RBAC is an integral part of the security models for Secure
European System for Applications in a Multi-vendor Environment (SESAME)
distributed system and the database language SQL3. In addition, the Object
Management Group's (OMG) Co
mmon Object Request Broker Architecture (CORBA) Security specification uses
RBAC as an example of an access control mechanism which can be used with the
distributed Object Technology defined by the OMG. (See reference
below.)</p><p>CSL has been developing and defining RBAC and its applicability
cooperatively with industry, government, and academic partners. In conjunction
with Dr. Ravi Sandhu of George Mason University and Seta Corporation, CSL is
defining RBAC and its feasibility. We are working with Dr. Virgil Gligor and
his associates at the University of Maryland and with the National Security
Agency (NSA) to develop a formal reference model for RBAC to provide a safe,
effective, and consistent mechanism for access control. This effort is also
implementing RBAC on NSA's Synergy Platform, a secure platform based on the
Mach Operating System. CSL is also developing a demonstration of RBAC use in
healthcare. The access policy used in this demonstration is based on a draft c
onsensus policy for patient record access developed in the United Kingdom. In
conjunction with the Internal Revenue Service (IRS), CSL is defining roles and
operations suitable for the IRS environment. In conjunction with the Veterans
Administration (VA), CSL is studying the applicability of RBAC to VA
systems.</p><p>Based on current research and experience, RBAC appears to fit
well into the widely varying security policies of industry and government
organizations.</p><p>For additional information on Role-Based Access Control
see:</p><p>http://waltz.ncsl.nist.gov/rbac/</p><p>or contact David Ferraiolo,
[email protected], (301) 975-3046.</p></div><div
class="section"><h2>References<a name="References"></a></h2><p>Department of
Defense, "Trusted Computer Security Evaluation Criteria," DoD
5200.28-STD, 1985.</p><p>David F. Ferraiolo and D. Richard Kuhn,
"Role-Based Access Controls," Proceedings of the 15th NIST-NSA
National Computer Security Conference, Ba
ltimore, Maryland, October 13-16, 1992.</p><p>David F. Ferraiolo, Dennis M.
Gilbert, and Nickilyn Lynch, "An Examination of Federal and Commercial
Access Control Policy Needs," Proceedings of the 16th NIST-NSA National
Computer Security Conference, Baltimore, Maryland, September 20-23,
1993.</p><p>ISO/IEC 9075, (Working Draft) Database Language SQL - Part 2:
Foundation, Document ISO/IEC JTC1/SC21 N9463, March 1995.</p><p>A. Griew and R.
Currell, "A Strategy for Security of the Electronic Patient Record,"
Institute for Health Informatics, Aberystwyth, Draft Version 2.1, March 8,
1995.</p><p>David F. Ferraiolo, Janet A. Cugini, and D. Richard Kuhn,
"Role-Based Access Control (RBAC): Features and Motivations," 11th
Annual Computer Security Applications Proceedings, 1995.</p><p>John Barkley,
"Application Engineering in Health Care," Proceedings of the 2nd
Annual CHIN Summit, 1995.</p><p>CORBA Security Draft, Object Management Group
(OMG) D
ocument Number 95-9-1, September 1995.</p><p>John Barkley, "Implementing
Role-Based Access Control using Object Technology," First ACM Workshop on
Role-Based Access Control, Gaithersburg, Maryland, November 30-December 1,
1995.</p><p>T. Parker and D. Pinkas, "SESAME Technology Version 3:
Overview,"</p><p>http://www.esat.kuleuven.ac.be/cosic/sesame/doc-txt/overview.txt</p><p>Background
material in a text box in the paper document:</p><p>Access control technology
has evolved from research and development efforts supported by the Department
of Defense (DoD). This research has resulted in two fundamental types of access
control: Discretionary Access Control (DAC) and Mandatory Access Control (MAC).
While initial research and applications addressed preventing the unauthorized
access to classified information, recent applications have applied these
policies to commercial processing environments.</p><p>DAC permits the granting
and revoking of access control priv
ileges to be left to the discretion of the individual users. A DAC mechanism
allows users to grant or revoke access to any of the objects under their
control. As such, users are said to be the owners of the objects under their
control. However, for many organizations, the end users do not own the
information for which they are allowed access. For these organizations, the
corporation or agency is the actual owner of system objects as well as the
programs that process them. Access priorities are controlled by the
organization and are often based on employee functions rather than data
ownership.</p><p>MAC, as defined in the DoD's Trusted Computer Security
Evaluation Criteria (TCSEC), 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."</p><p>These policies
for access control are n
ot particularly well suited to the requirements of government and industry
organizations that process unclassified but sensitive information. In these
environments, security objectives often support higher-level organizational
policies which are derived from existing laws, ethics, regulations, or
generally accepted practices. Such environments usually require the ability to
control actions of individuals beyond just an individual's ability to access
information according to how that information is labeled based on its
sensitivity.</p></div>
</div>
</div>
