1 eric yuan, jin tong new challenges for access control workshop ottawa, on, canada april 27, 2005...

28
1 Eric Yuan, Jin Tong New Challenges for Access Control Workshop Ottawa, ON, Canada April 27, 2005 PRESENTATION Attribute Based Access Control A New Access Control Approach for Service Oriented Architectures (SOA) 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

Post on 18-Dec-2015

213 views

Category:

Documents


0 download

TRANSCRIPT

1

Eric Yuan, Jin TongNew Challenges for Access Control Workshop

Ottawa, ON, CanadaApril 27, 2005

PRESENTATION

Attribute Based Access Control

A New Access Control Approach for Service Oriented Architectures (SOA)

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

Service Enabled Infrastructure

Publish

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

Discover

Access

• Searches metadata catalogs to find data services

• Analyzes metadata search results found• Pulls selected data based on metadata

understanding

Automated search of data services using metadata. Pulls data of interest. Based on producer registered format and definitions, translates into needed structure.

Service Consumer

MessagingServices

MonitoringServices

RegistryServices

SecurityServices

TransformationServices

DataServices

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

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

SubjectsSubjects RolesRoles

PermissionsPermissions

ActionsActions ResourcesResources

SessionContextsSessionContexts

User

Assig

nmen

t

Perm

issio

nAs

signm

ent

Sess

ion

Role

s

User

Sess

ions

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:

N

M

K

EAEAEAeATTR

RARARArATTR

SASASAsATTR

...)(

...)(

...)(

21

21

21

12

ABAC Policy Formulation (Cont’d)

4. We also use the function notation for the value assignment of individual attributes. For example:

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:

Role(s) = “Service Consumer”ServiceOwner(r) = “XYZ, Inc.”CurrentDate(e) = “01-23-2005”

))(),(),((

),,(_:

eATTRrATTRsATTRf

ersaccesscanXRule

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”

'')(

'')(

),,(_:

chaseApprovePurrName

ManagersRole

ersaccesscanRule

1

)()(

),,(_:

rOwnerIDsUserID

ersaccesscanRule

2

)()(

),,(_:

rtionClassificasClearance

ersaccesscanRule

3

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:

K

k )Range(SA1

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

}){)()((

)},{)()((

}),,{)()((

),,(_:

GmRatinguAge

GPGmRatinguAge

GPGRmRatinguAge

emuaccesscanR

13

131321

1321

1

213

2

RRemuaccesscanR

leaseReNewmMovieType

gularReuMemberType

emiumPruMemberType

emuaccesscanR

),,(_:

})'{')(

'')((

)'')((

),,(_:

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

PEPPEP

Subject Resource

Subject AA Resource AA

Environment AA

ABAC Policy

Authority AA: Attribute Authority

22

Implementation Scenario – Applying ABAC to Secure Web Services

Service ProviderService Provider

Attribute& PolicyServices

WebService

WebServiceSO

AP

Mes

sage

Han

dler

SOA

P M

essa

geH

andl

erPolicyStorePolicyStore

PolicyDecisionService

PolicyDecisionService

ServiceRegistryServiceRegistry

IdentityStore

IdentityStore

SOAPClient SOAP Msg

SA

RA

1 3

2

PolicyAdmin.Service

PolicyAdmin.Service

SA

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

AttributeBased

InformationSecurity

AttributeProvisioning

AttributeBinding

AttributeDiscovery

Monitor &Feedback

Attribute BasedAccess Control

26

Attribute Based Information Security (ABIS):A Reference Architecture

Data ServiceProviders

App ServiceProviders

ThickClients

ThinClients

Subject / ResourceDirectories

GatewaysOther

SecurityDomains

Policy Stores

Authentication Mechanisms

Web Portals Certificates Biometrics, …

PolicyAuthorities

EnvironmentAttribute

Authorities

ResourceAttribute

Authorities

SubjectAttribute

Authorities

Att

rib

ute

Bas

ed P

oli

cy E

nfo

rcem

ent

(XA

CM

L /

SA

ML

/ W

S-S

ecu

rity

)

Inte

gra

tio

n B

ackp

lan

eMonitoring &Management

ABIS Platform

…SDPRO

Public KeyInfrastructure

PolicyDecisionEngines

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

Booz Allen & Hamilton Inc.8251 Greensboro Drive

Mclean, VA 22102(703) 377-1787

[email protected]

Eric YuanAssociate