PRESENTATION Attribute Based Access Control A New Access

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 1

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

Service Oriented Architectures Access 4 Common perspective that Web services will do for system-to-system communications what HTTP/HTML did for the browser-based web 4 Web Services are modular XML-based applications using standards and technologies for distributed computing – Defined with WSDL – Invoked via SOAP Service Consumer Automated search of data services using metadata. Pulls data of interest. Based on producer registered format and definitions, translates into needed structure. Data and applications available for use accessible via services. Metadata added to services based on producer’s format. • Searches metadata catalogs to find data • Describes content using metadata • Posts metadata in catalogs for services • Analyzes metadata search results found • Pulls selected data based on metadata discovery • Exposes data and applications as understanding services Publish Service Enabled Infrastructure Messaging Services Data Services Transformation Services Registry Services Discover Security Services Published in UDDI – Service Provider Monitoring Services 3

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

Access Control Challenges under SOA 4 Disappearance of network, system, and enterprise boundaries – E. g. SOAP/HTTP access through conventional firewalls 4 Information access is more peer-to-peer – Decentralization of security information management 4 No a priori relationship between consumers and providers – E. g. dynamic discovery and binding to web services via UDDI 4 Need rich semantics to define tailored, dynamic, fine-grained access policies – Dynamic Qo. P parameters (E. g. consideration of threat level, transaction at hand, community of interest) 4 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 5

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

Discretionary vs. Mandatory Access Control Types 4 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] 4 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 Do. D systems 4 MAC and DAC are not mutually exclusive, and may be used in conjunction 7

Conventional Access Control Models 4 Identity Based Access Control (IBAC) – Access permissions are directly associated with a subject (e. g. ACLs) – Difficult to scale Session Contexts Permission Assignment Roles Session Roles User Sessio ns Subjects User Assignment 4 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) Actions Resources Permissions 4 Lattice Based Access Control (LBAC) [Sandhu 1993] – Implemented in the US defense sector to address MAC requirements 8

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

Attribute Based Access Control (ABAC) – Attributes Defined 4 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 4 Resource Attributes – Associated with a resource (web service, system function, or data) – E. g. Dublin Core metadata elements 4 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 10

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 predefined 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: 11

ABAC Policy Formulation (Cont’d) 4. We also use the function notation for the value assignment of individual attributes. For example: Role(s) = “Service Consumer” Service. Owner(r) = “XYZ, Inc. ” Current. Date(e) = “ 01 -23 -2005” 5. 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: The access control decision process in essence amounts to the evaluation of applicable policy rules in the policy store. 12

Policy Rule Examples 4 Modeling conventional RBAC rules: – “User with role ‘Manager’ may access the ‘Approve. Purchase’ web service” 4 Modeling richer access control semantics – “A resource may only be accessed by its owners” 4 Modeling mandatory access control – “Classified files can be accessed by users with equal or higher clearance” 13

Policy Evaluation 4 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) 4 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 4 Implementation aspects are work in progress and beyond the scope of this presentation – E. g. , complexity 14

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

Online Entertainment Store Example 4 Inspired by [Al-Kahtani & Sandhu 2003]: – Streams movies to customers for a flat monthly fee 4 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 4 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: 16

Online Entertainment Store Example (Cont’d) 4 Using ABAC: – Basic policy: No need to define explicit roles – Advanced policy: Only need to add a second rule and combine the two 17

Comparison with (Pure) RBAC Models 4 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 4 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] 18

Comparison with (Pure) RBAC Models (Cont’d) 4 RBAC usually needs centralized management of user-to-role and permissionto-role assignments – Not well suited for a highly distributed environment – Even more difficult when subject and resource belong to different security domains! 4 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 Current. Date(e) 4 RBAC doesn’t handle MAC – In ABAC, security labels can be treated naturally as attributes 19

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

ABAC Authorization Architecture 4 The XACML authorization architecture readily supports ABAC – Agnostic to the actual representation and formulation of policies Subject Resource PEP Subject AA Resource AA PDP ABAC Policy Authorit y Environmen t AA AA: Attribute Authority 21

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

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

Towards End-to-End Attribute Based Information Security 4 The ABAC policy and architecture models, though very powerful, only focus on authorization of requests from information consumers to providers 4 The end-to-end security architecture requires more than just the access control model 4 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 24

Attribute Management Lifecycle Methodology Attribute Provisioning Monitor & Feedback Attribute Binding Attribute Based Information Security Attribute Discovery Attribute Based Access Control 25

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

Conclusions 4 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 4 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 27

Questions Eric Yuan Associate Booz Allen & Hamilton Inc. 8251 Greensboro Drive Mclean, VA 22102 (703) 377 -1787 yuan_eric@bah. com 28