Eric Yuan, Jin Tong

1
PRESENTATION
Attribute Based Access Control A New Access
Control Approach for Service Oriented
Architectures (SOA)
Eric Yuan, Jin Tong New Challenges for Access
Control Workshop Ottawa, ON, Canada April 27, 2005
This document does not represent the official
opinions of BAH, nor does it bind the company to
any order or other contract unless explicitly
stated otherwise
2
Agenda

• Access Control Challenges under SOA
• Conventional Access Control Models
• Attribute Based Access Control (ABAC)
• Policy Model
• ABAC vs. RBAC
• Architecture Model
• Towards Attribute Based Information Security

3
Service Oriented Architectures

• Common perspective that Web services will do for
  system-to-system communications what HTTP/HTML
  did for the browser-based web
• Web Services are modular XML-based applications
  using standards and technologies for distributed
  computing
• Defined with WSDL
• Published in UDDI
• Invoked via SOAP

• Searches metadata catalogs to find data services
• Analyzes metadata search results found
• Pulls selected data based on metadata
  understanding

Service Enabled Infrastructure
4
Pre-SOA Access Control Solutions

• Heavy reliance upon perimeter-based security
• E.g., DMZ, firewalls, intrusion detection
• Assumption of system boundaries
• Network ownership (e.g. Intranet, VPN)
• Centralized security management
• Information access is mostly client-server
• Known users accessing known systems
• Static, coarsely grained
• E.g., User, Admin, Guest
• No consideration of operational contexts
• Focuses on single system / single enterprise
• Ad hoc approaches for inter-system security

5
Access Control Challenges under SOA

• Disappearance of network, system, and enterprise
  boundaries
• E.g. SOAP/HTTP access through conventional
  firewalls
• Information access is more peer-to-peer
• Decentralization of security information
  management
• No a priori relationship between consumers and
  providers
• E.g. dynamic discovery and binding to web
  services via UDDI
• Need rich semantics to define tailored, dynamic,
  fine-grained access policies
• Dynamic QoP parameters (E.g. consideration of
  threat level, transaction at hand, community of
  interest)
• Need a System of Systems view
• Fractal network

Under SOA, we need an access control model and
architecture that addresses these challenges to
achieve end-to-end information security
6
Agenda

• Access Control Challenges under SOA
• Conventional Access Control Models
• Attribute Based Access Control (ABAC)
• Policy Model
• ABAC vs. RBAC
• Architecture Model
• Towards Attribute Based Information Security

7
Discretionary vs. Mandatory Access Control Types

• DAC Restricting access to objects based on the
  identity and need-to-know of the user, process,
  and/or groups to which they belong
• Discretionary, in the sense that a subject is
  capable of passing certain access permission on
  to another subject NCSC-TG-004
• MAC Restricting access to objects based on
  fixed security attributes or labels assigned to
  users and to files or other objects.
• Mandatory, in the sense that controls cannot be
  modified by users or their programs Bell
  Lapadula
• Depends on system-enforced mechanisms that
  override the intentions of the resource owner
• Widely used in government and DoD systems
• MAC and DAC are not mutually exclusive, and may
  be used in conjunction

8
Conventional Access Control Models

• Identity Based Access Control (IBAC)
• Access permissions are directly associated with a
  subject (e.g. ACLs)
• Difficult to scale
• Role Based Access Control (RBAC) Sandhu 1993,
  NIST 2004
• Access permissions are based on the role(s) a
  subject is performing
• Better scalability and ease of use, but also has
  drawbacks (more later)
• Lattice Based Access Control (LBAC) Sandhu 1993
• Implemented in the US defense sector to address
  MAC requirements

9
Agenda

• Access Control Challenges under SOA
• Conventional Access Control Models
• Attribute Based Access Control (ABAC)
• Policy Model
• ABAC vs. RBAC
• Architecture Model
• Towards Attribute Based Information Security

10
Attribute Based Access Control (ABAC)
Attributes Defined

• Subject Attributes
• Associated with a subject (user, application,
  process) that defines the identity and
  characteristics of the subject
• E.g. identifier, name, job title, role
• Resource Attributes
• Associated with a resource (web service, system
  function, or data)
• E.g. Dublin Core metadata elements
• Environment Attributes
• Describes the operational, technical, or
  situational environment or context in which the
  information access occurs
• E.g. current date time, current threat level,
  network security classification

11
ABAC Policy Formulation

1. S, R, and E are subjects, resources, and
   environments, respectively
2. SAk (1 ? k ? K), RAm (1 ? m ? M), and EAn (1 ? n
   ? N) are the pre-defined attributes for subjects,
   resources, and environments, respectively
3. ATTR(s), ATTR(r), and ATTR(e) are attribute
   assignment relations for subject s, resource r,
   and environment e, respectively

12
ABAC Policy Formulation (Contd)

1. We also use the function notation for the value
   assignment of individual attributes. For
   example
2. In the most general form, a Policy Rule that
   decides on whether a subject s can access a
   resource r in a particular environment e, is a
   Boolean function of s, r, and es attributes

Role(s) Service Consumer ServiceOwner(r)
XYZ, Inc. CurrentDate(e) 01-23-2005
The access control decision process in essence
amounts to the evaluation of applicable policy
rules in the policy store.
13
Policy Rule Examples

• Modeling conventional RBAC rules
• User with role Manager may access the
  ApprovePurchase web service
• Modeling richer access control semantics
• A resource may only be accessed by its owners
• Modeling mandatory access control
• Classified files can be accessed by users with
  equal or higher clearance

14
Policy Evaluation

• Given attribute assignments, the evaluation of
  policy rules may be boiled down to the evaluation
  of First Order Logic expressions, or its simpler,
  computationally more attractive subsets (e.g.
  Description Logic, Horn Logic)
• Natural marriage with Semantic Web technologies
  for attribute and policy representations
• E.g., attribute assignments as OWL axioms
• Existing inference engines / reasoners may be
  readily leveraged
• Implementation aspects are work in progress and
  beyond the scope of this presentation
• E.g., complexity

15
Agenda

• Access Control Challenges under SOA
• Conventional Access Control Models
• Attribute Based Access Control (ABAC)
• Policy Model
• ABAC vs. RBAC
• Architecture Model
• Towards Attribute Based Information Security

16
Online Entertainment Store Example

• Inspired by Al-Kahtani Sandhu 2003
• Streams movies to customers for a flat monthly
  fee
• Access Control Requirements
• Basic requirement access control is based on
  users age and the movies content ratings (R,
  PG-13, G)
• Advanced requirement Suppose the store
  introduces membership classes (Premium, Regular)
  and would like to enforce a new policy that only
  Premium users can view New Releases
• Using RBAC
• Basic policy Need to create roles such as Adult,
  Juvenile, Child
• Advanced policy Roles and permissions need to be
  doubled (e.g., Adult Premium, Adult Regular, )
• I.e., given K subject attributes, total roles
  could be

17
Online Entertainment Store Example (Contd)

• Using ABAC
• Basic policy No need to define explicit roles
• Advanced policy Only need to add a second rule
  and combine the two

18
Comparison with (Pure) RBAC Models

• Inherent limitation in RBAC is the single
  dimension of roles
• Finer-grained access control policies often
  involve multiple subject and object attributes
• As more attributes are involved, number of roles
  and permissions needed to encode these attributes
  will grow exponentially, thereby making User
  Assignments and Permission Assignments difficult
  to manage
• Various research work has tried to extend the
  basic RBAC model, however most are constrained by
  the inherent limitations of RBAC
• Rule-based RBAC Al-Kahtani Sandhu 2003,
• Inclusion of subject-resource relationship
  Barkley,Beznosov Uppal 1999
• Use-condition policies specified by stakeholders
  Johnston et al. 1998 Thompson et al. 1999

19
Comparison with (Pure) RBAC Models (Contd)

• RBAC usually needs centralized management of
  user-to-role and permission-to-role assignments
• Not well suited for a highly distributed
  environment
• Even more difficult when subject and resource
  belong to different security domains!
• RBAC doesnt consider environment attributes
  explicitly
• E.g., continuing with the previous example,
  suppose an additional requirement states Regular
  customers in general may not watch new releases,
  but may be allowed in promotional periods
• In ABAC, a new rule can be easily added,
  involving an environment attribute CurrentDate(e)
• RBAC doesnt handle MAC
• In ABAC, security labels can be treated naturally
  as attributes

20
Agenda

• Access Control Challenges under SOA
• Conventional Access Control Models
• Attribute Based Access Control (ABAC)
• Policy Model
• ABAC vs. RBAC
• Architecture Model
• Towards Attribute Based Information Security

21
ABAC Authorization Architecture

• The XACML authorization architecture readily
  supports ABAC
• Agnostic to the actual representation and
  formulation of policies

AA Attribute Authority
22
Implementation Scenario Applying ABAC to
Secure Web Services
23
Agenda

• Access Control Challenges under SOA
• Conventional Access Control Models
• Attribute Based Access Control (ABAC)
• Policy Model
• ABAC vs. RBAC
• Architecture Model
• Towards Attribute Based Information Security

24
Towards End-to-End Attribute Based Information
Security

• The ABAC policy and architecture models, though
  very powerful, only focus on authorization of
  requests from information consumers to providers
• The end-to-end security architecture requires
  more than just the access control model
• To utilize ABAC to its full potential, we need a
  systematic methodology around how attributes are
  managed throughout their life cycle
• Attribute definition and provisioning
• Cryptographic mechanisms to bind attributes to
  subjects and objects they describe
• Discovery mechanisms for attribute definitions
  and attribute assignments
• A feedback loop through which attribute usage
  can be monitored and audited

25
Attribute Management Lifecycle Methodology
26
Attribute Based Information Security (ABIS)A
Reference Architecture
27
Conclusions

• The ABAC model brings many advantages over
  traditional identity or role based models
• Intuitive to model and manage real-world access
  control policies
• More flexible and more powerful to represent
  complex, fine-grained access control semantics,
  which is especially suitable for the dynamic SOA
  / web services environment
• Management of security information is spread over
  a number of Attribute and Policy Authorities,
  possibly across organizational boundaries
  suitable for large-scale information sharing
• Reduces overall system complexity, allowing
  different system components (user directory,
  service registry, policy server, etc.) to focus
  on their respective administrative tasks
• To utilize the ABAC model to its full potential,
  many aspects of the entire attribute management
  life cycle needs to be considered, such as
  attribute provisioning, binding, discovery, and
  feedback loop
• All are potential research and engineering topics
  to be explored

28
Questions
Eric Yuan Associate
Booz Allen Hamilton Inc. 8251 Greensboro
Drive Mclean, VA 22102 [phone] yuan_eric_at_b
ah.com