1. Attribute Based Access Control
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
Booz Allen Hamilton Standard Colors
Colors should be used in the color pairs whenever possible. Do not mix and match colors, use pairs together as shown.
Black, White and Gray can be used with any of the other colors.
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
Purple Pantone 2765
R 12
G 4
B 79
Green Pantone 357
R 15
G 67
B 24
Blue Pantone 2 88
R 11
G 31
B 101
Pantone Cool Gray 6
R 158
G 158
B 158
Black
Red Pantone 485
R 252
G 5
B 14
Yellow Pantone 3965
R 232
G 244
B 4
Aqua Pantone 319
R 126
G 204
B 189
White

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
Access
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
Automated search of data services using metadata. Pulls data of interest. Based on producer registered format and definitions, translates into needed structure.
Service Consumer
Data and applications available for use accessible via services. Metadata added to services based on producer’s format.
Service Provider
Describes content using metadata
Posts metadata in catalogs for discovery
Exposes data and applications as services
Searches metadata catalogs to find data services
Analyzes metadata search results found
Pulls selected data based on metadata understanding
Publish
Discover
Service Enabled Infrastructure
Messaging
Services
Data
Services
Transformation
Services
Monitoring
Services
Registry
Services
Security
Services

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
Op Contexts: e.g. thread level

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
Subjects
Roles
Permissions
Actions
Resources
Session
Contexts
Assignment
User
Permission
Sessions

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
S, R, and E are subjects, resources, and environments, respectively;
SAk (1  k  K), RAm (1  m  M), and EAn (1  n  N) are the pre- defined attributes for subjects, resources, and environments, respectively;
ATTR(s), ATTR(r), and ATTR(e) are attribute assignment relations for subject s, resource r, and environment e, respectively:

12. ABAC Policy Formulation (Cont’d)
We also use the function notation for the value assignment of individual attributes. For example:
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 e’s attributes:
Role(s) = “Service Consumer”
ServiceOwner(r) = “XYZ, Inc.”
CurrentDate(e) = “ ”
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 user’s 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 (Cont’d)
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 (Cont’d)
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 doesn’t 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 doesn’t 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
PDP
PEP
Subject
Resource
Subject AA
Resource AA
Environment AA
ABAC Policy
Authority
AA: Attribute Authority

22. Implementation Scenario – Applying ABAC to Secure Web Services
Service Provider
Attribute
& Policy
Services
Web
Service
SOAP Message
Handler
Policy
Store
Decision
Registry
Identity
SOAP
Client
SOAP Msg SA RA 1 3 2
Admin. EA

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
Based
Information
Security
Provisioning
Binding
Discovery
Monitor &
Feedback
Attribute Based
Access Control

26. Attribute Based Information Security (ABIS): A Reference Architecture
Data Service
Providers
App Service
Thick
Clients
Thin
Subject / Resource
Directories
Gateways
Other
Security
Domains
Policy Stores
Authentication Mechanisms
Web Portals
Certificates
Biometrics, …
Policy
Authorities
Environment
Attribute
Resource
Subject
Attribute Based Policy Enforcement
(XACML / SAML / WS-Security)
Integration Backplane
Monitoring &
Management
ABIS Platform … S D P R O
Public Key
Infrastructure
Decision
Engines

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
(703)