Patterns for access control
E.B. Fernandez
Secure Systems Research Group - FAU
Access control models
• An access control model defines who can
access what and in what manner in a
system
• Some secure design methodologies start
from use cases and from them a
conceptual model is developed. Security
constraints are then defined in the
conceptual model. The most important
constraints are related to access control
Secure Systems Research Group - FAU
Many access control models
• There are many models for access control, mostly
variations of some basic models and it is confusing for a
software developer to select an appropriate model for her
application
• Access control models generally represent a few types of
security policies, e.g. “rights are assigned to roles”, and
provide a formalization of these policies using some ad hoc
notation
• Four basic access control models are commonly used and
they may be extended to include other aspects
• Access control models can be defined for different
architectural levels, including application, database
systems, operating systems, and firewalls
• Some of them apply to any type of systems while some are
specialized, e.g. for distributed systems.
Secure Systems Research Group - FAU
Model dimensions
• Access control models fall into two basic categories:
mandatory models (MAC), where users’ rights are defined
by administrators and data may be labeled to indicate its
sensitivity, and discretionary (DAC), where users may
administer the data items they create and own
• In a MAC model users and data are classified by
administrators and the system applies a setoff built-in rules
that users cannot circumvent
• In a DAC model, there is no clear separation of use and
administration; users can be owners of the data they create
and act as their administrators
• Orthogonal to this classification, there are several models
for access control to information that differ on how they
define and enforce their policies
Secure Systems Research Group - FAU
Basic models for access control
•
•
•
•
The Multilevel model organizes the data using security levels. This model
is usually implemented as a mandatory model where its entities are
labeled indicating their levels. This model is able to reach a high degree of
security, although it can be too rigid for some applications.
The Access Matrix describes access by subjects (actors, entities) to
protected objects (data, resources) in specific ways (access types). It is
more flexible than the multilevel model and it can be made even more
flexible and precise using predicates and other extensions. It is
intrinsically a discretionary model in which users own the data objects
and may grant access to other subjects. This model is usually
implemented using Access Control Lists (lists of the subjects that can
access a given object) or Capabilities (tickets that allow a process to
access some objects).
Role-Based Access Control (RBAC), collects users into roles based on
their tasks or functions and assigns rights to each role. RBAC has been
extended and combined in many ways.
Attribute-Based Access Control (ABAC). This model controls access
based on properties of subjects or objects. It is used in environments
where some subjects may not be pre-registered
Secure Systems Research Group - FAU
Many variants
• While these basic models may be useful for
specific domains or applications, they are not
flexible enough for the full range of policies
present in some of these applications
• A large variety of ad hoc RBAC variations that
have been proposed; most of which add
specialized policies to a basic RBAC
• For example, some models have added content or
context-dependent access, delegation, role
hierarchies, task-based access, and relationships
between role entities
• All these models effectively incorporate a set of
built-in access control policies and cannot handle
situations not considered by these policies
Secure Systems Research Group - FAU
Confusion for the designer
• All these models present a bewildering set of options to the
designer, who has problems deciding which model to use
• The result in practice is that only basic models are used
and the power of more advanced models is thus lost
• We try to clarify this panorama here through the use of
patterns
• We use pattern diagrams to make clear the pattern space
and help in their selection
• A subproduct is the analysis of which patterns are available
for use and which need to be written
• Pattern maps are also useful to perform semi-automatic
model transformations
Secure Systems Research Group - FAU
What is a pattern?
• A requirement for a pattern is that the solution it
describes has been used in at least three real
systems
• This is consistent with the idea of patterns as
best practices
• However, a pattern can also describe solutions
that have not been used (or have been used only
once) but appear useful for several situations
• Because of this, we include here both types:
good practices patterns and useful solutions
patterns
• We consider more important their genericity
Secure Systems Research Group - FAU
Structure of models
• Access control models have two aspects: a
definition of a set of rules specifying the valid
accesses (some of them may be implicit), and an
enforcement mechanism that intercepts access
requests from users or processes and
determines if the request is valid
• The main difference between models is on the
way they define their rules, so it makes sense to
separate the enforcement mechanism
• For each type of models we provide separate
patterns for rules and only one pattern for
enforcement.
Secure Systems Research Group - FAU
Organizing the models
• Pattern diagrams can help the designer in
the selection of an appropriate model
• Starting from a basic Authorization
(Access Matrix) pattern we can add
elements
• The basic access matrix defines rights for
individual subjects to access resources
Secure Systems Research Group - FAU
Access matrix authorization rules
• Basic rule ( s, o, t ) , where s is a subject
(active entity), t is an access type, and o is
an object
• Extended rule ( s, o , t , p, f) , where p is a
predicate (access condition or guard) and
f is a copy flag
• This, and the other models, can be
described by patterns
Secure Systems Research Group - FAU
Authorization/Access Matrix
Subject
*
isAuthorizedFor
id
name
ProtectionObject
id
name
Right
accessType
checkRights
Secure Systems Research Group - FAU
*
Patterns derived from the Access
Matrix
Basic
Authorization
CopyFlag
condition
Content-based
Authorization
s =Role
s or o =attribute values
Delegatable
Authorization
Basic
RBAC
authorizer
ABAC
session
Session-based
RBAC
Secure Systems Research Group - FAU
Explicitly
Granted
Authorization
session
session
Access Session
session
Session-based
ABAC
Reference Monitor
• Each request for resources must be
intercepted and evaluated for authorized
access
• Abstract concept, implemented as
memory access manager, file permission
checks, CORBA adapters, etc.
Secure Systems Research Group - FAU
Reference monitor pattern
Subject
makesRequestTo
*
*
Reference
Monitor
exists
*
Set_of_
Authorization_
*
Rules
Request
prot_Object
access_type
Secure Systems Research Group - FAU
*
Concrete
Reference
Monitor
Authorization
Analyze elements of the access matrix
• Understand function of each element:
subject, object, access type
• Consider administrative approaches (MAC
and DAC)
• Start from a general pattern that defines
structure of authorization rules: PolicyBased Access Control
Secure Systems Research Group - FAU
XACML
Evaluator
XACML
Policy
MAC
Policy-based
Access Control
Policy
ACL
DAC
Ref.Monitor
Cap
Access
Matrix
Predicate
Access matrix
Copy Flag
Access matrix
Predicate +
copy flag
access matrix
Secure Systems Research Group - FAU
RBAC
ABAC
Session
NIST
• We can expand each branch of the big
pattern to focus on some specific aspects
and analyze better the pattern
relationships
• The initial pattern diagram could have
been obtained in this way
Secure Systems Research Group - FAU
Policies and sessions
Policy
Model
Policy
Rule
rule
structure
AC model
Reference
Monitor
enforces
specializes
Policy-Based
Access Control
Session-Based
Reference Monitor
session
Access
Session
Secure Systems Research Group - FAU
Growing models from simpler models
• Each pattern can be augmented with new features
to produce a new variety of models
• The next figure shows the basic RBAC pattern,
where users are assigned to roles and roles are
given rights
• The NIST standard adds the concept of session
and a simple role hierarchy
• The next figure shows a model of RBAC beyond
the NIST standard where in addition we have
object/resource hierarchies where the hierarchies
are recursive (described by the Composite
pattern)
Secure Systems Research Group - FAU
Basic RBAC pattern
User
*
MemberOf
*
Role
*
Authorization_rule
*
ProtectionObject
id
id
id
name
name
name
Right
access_type
predicate
copy_flag
checkRights
Secure Systems Research Group - FAU
NIST model with composite hierarchies
Role
User
ProtectionObject
roleID
{Subset}
*
addUser
removeUser
objectID
*
* MemberOf
addRole
removeRole
addUserToRole
removeUserFromRole
*
AuthorizationRule
*
*
userID
addObject
removeObject
*
Right
*
1
accessType
checkRights
CompositeRole
SimpleRole
WorksOn
CompositeObject
*
Session
*
createSession
endSession
Secure Systems Research Group - FAU
SimpleObject
A more advanced RBAC model
MemberOf
Group
*
User
*
*
MemberOf
*
*
Role
*
1
AuthorizationRule
*
*
*
Right
Composite
Simple
Role
Role
Activated
From
Subset
*
WorksOn
*
Secure Systems Research Group - FAU
Session
AdminRole
AdminRight
ProtectionObject
Distributed systems
•
•
•
•
•
•
•
The nature of distributed systems implies that a subject does not need to
be known in advance by the system in order to request access to a
resource
The use of credentials including attributes may be sufficient to trust a
subject.
In the next diagram, traditional models, such as the Access Matrix and
RBAC (Role-Based Access Control), are represented along with AttributeBased Access control and Policy-Based Access control
All of the models use a Reference Monitor to enforce access decisions
ACL (Access Control List) and Capability are implementation-oriented
patterns; they implement the Access Matrix or RBAC model
For web services, XACML (eXtensible Access Control Markup Language)
Access Control Evaluation implements the Attribute-Based Access
control pattern and the Policy-Based Access control pattern, and the
XACML Policy Language implements the Policy-Based Access control
pattern
The SAML Authorization Assertion is a kind of Capability.
Secure Systems Research Group - FAU
Patterns for distributed systems
Secure Systems Research Group - FAU
More complex models
• With these basic units we can compose more complex,
implementation-oriented AC systems
• Policy-based access control defines access evaluation
based on general policies stored in some repository
• Depending on the objects, rights are defined by
administrators or users, the policies may define a MAC or
DAC model, respectively
• Policy-based access control uses a reference Monitor for
its enforcement functions and a Policy pattern that defines
the general structure of each policy
• Policy-based access control may be specialized to
implement models such as the Access Matrix, RBAC, or
ABAC by convenient adaptation of the policy structure.
Secure Systems Research Group - FAU
Policy-Based access control
• The Policy-Based Access Control pattern decides if a
subject is authorized to access an object according to
policies defined in a central policy repository.
• Context : We consider centralized or distributed systems
with a large number of resources (objects). A large number
of subjects may access those objects. Some rules are
defined to control access to objects. The rules defined by
the organization are typically designed by different actors
(technical, organizational, legal, etc), and each set of rules
designed by a specific policy designer can concern
overlapping sets of objects and/or subjects. We assume
that access requests come from authenticated subjects.
Secure Systems Research Group - FAU
Secure Systems Research Group - FAU
Models through analogies
• We can build security models through
analogies when two standards or
regulations have similar types of policies
• We can convert a HIPAA model into a
Sarbanes/Oxley model
Secure Systems Research Group - FAU
Doctor.LoginrID =
MedicalRecord.doctorID
Right
read
modify
<<role>>
Doctor
1
MedicalRelationship
custodian
InChargeOf
*
*
MedicalRecord
1
*
patientID: Integer
dateOfBirth: Date
name: String
address: String
age: Integer
sex:{male, female}
1
Right
read
authorizeUse
doctorID: Integer
dateOfBirth: Date
name: String
address: String
age: Integer
sex:{male, female}
Patient
0..*
1..*
Patient
LoginID: Integer
custodian
1
LoginID: Integer
<<role>>
Doctor
read
modify
forAll(p: PatientID->
notify(self.Log.accessor)
Patient.patientID =
MedicalRecord.patientID
*
TreatmentHistory
medications:String
procedures:string
Outpatient
Log
accessor: String
period: String
date: Date
accesType
Secure Systems Research Group - FAU
Inpatient
Moving to SOX
• The Patient record can become a Financial
record, the Patient becomes an Investor,
the doctor is now a Broker
• This approach simplifies the task of
building pattern catalogs and makes it
easier for users to remember what
patterns to use in a given situation.
Secure Systems Research Group - FAU
A SOX model
Role
for own investor
.
name: String
Right
read
invest
FinancialInstitution
Broker
brokerID: Integer
name: String
specialty: String
loginID: String
1
MedicalRelationship
custodian
InChargeOf
*
*
FinancialRecord
Investor
investorID: Integer
name: String
loginID: string
1..*
1
captureInfo
exchangeInfo
0..*
notify investor
.
Right
for own Record
.
name
address
ID number
1
read
invest
read
authorizeUse
contact Investor
*
Log
FinancialAccount
accountNumber
Secure Systems Research Group - FAU
1
accessor: String
period: String
date: Date
accesType: enum
Conclusions
• We can navigate the pattern diagram because patterns are
composable, i.e. adding a feature (perhaps embodied by
another pattern) produces a new pattern with extra features
• Using this approach we could not only clarify the
relationships of AC models but it lead us also to discover
the need for new security patterns: Subject, Object, Labeled
security, DAC, MAC
• In order to apply this approach one needs:
A good catalog of security patterns to let designers find
the required solution to each security restriction
A classification of patterns according to their security
concerns and architectural level
Secure Systems Research Group - FAU