A Usage-based Authorization Framework for Collaborative

Computing Systems

Xinwen ZhangGeorge Mason

University

Masayuki NakaeNEC Corporation

Michael J. CovingtonIntel Corporation

Ravi Sandhu George Mason

University and TriCipher Inc.

Collaborative Computing System A set of resources and their

providers Data, facilities services, etc.

A set of resource users Consumers

Virtual Organizations: Managing resources and providing

services for users

Collaborative Computing System Security problem: Control users’ accesses and

usage to the resources according to the policies of authorization and availability

Who can access what Who with specific attributes can access what Under what circumstances that a resource can be

accessed Time/location, presence/absence of some other users

How long/much/often of a user’s access Quality of access

Resource constraints

Existing Approaches Grid-mapfile:

Mapping users to local identities Not scalable

Community Authorization Service (CAS): (Policy’02) Centralized PDP, scalable Not dynamic and flexible, heavy infrastructure

VOMS: (FGCS’05) PDP in RP side Only persistent attributes from global attribute authorities

PRIMA: (Grid’03) Push-based approach Pre-issued privilege attributes, no dynamic privileges

Akenti: (TISSEC03) Extensively dependent on PKI Condition-based authorizations are not dynamic

Related Work Context-aware authorizations

Environment roles in RBAC (M. J. Covington et al. SACMAT’01)

Context-agent collecting environmental info (Zhang & Parasar, ICGC’03)

Context sensitive access control (Hulsebosch et al. SACMAT’05)

User-presence-aware authorization (Noda et al. SACMAT’06)

Why UCON Requirements in Collaborative Computing:

Dynamic user participation Consumable resources Context-aware authorization constraints For ad-hoc and pervasive collaborations with environmental

information ……

Previous work have shown policy specification flexibility of UCON

Can express identity-based, role-based, history-based, and context-aware policies

Can express dynamic constraints with application-specific attributes

Approach: OM-AM Closing the gap between informal objective (or policies,

requirements) and concrete implementation mechanisms.

What ?

How ?

Assurance

What ?

How ?

Assurance

Policy neutral

Sever-pull, user-pull, federated, etc

Secure cookies,digital certificates, SAML, etc.

RBAC96 model, ARBAC97, etc

RBAC System Usage Control System

Policy neutral

UCONABC model

Server-side RM,client-side RM, etc

DRM technologies,attribute certificates, trustec computing,

XrML, XACML, etc.

Outline Policy and Model:

UCON model for collaborative computing systems Express various policies in collaborative

computing systems with UCON Enforcement Architecture:

Attribute acquisition Attribute update

Implementation Mechanisms: Policy specification, attribute authenticity,

trusted update, secure communication Performance considerations

UCON Model (Park and Sandhu 2004)

Rights(R)

Authorizations

(A)

Subjects(S)

Objects(O)

Subject Attributes (SA) Object Attributes (OA)

Obligations(B)

Conditions(C)

UsageDecisions

Attributes can be updated as side-effects of a usage: pre, ongoing, and post updates Attribute Mutability

Core models: preA0, preA1, preA2, preA3, onAx, preBx, onBx preCx onCx

A real model may be a combination of core models.

before usage ongoing usage after usage

Continuity ofDecisions

pre-decision ongoing-decisions

pre-updates ongoing updates post-updates

Mutability ofAttributes

Three phases of a usage process Decision in first two phases

pre-decision: preA, preB, preC

ongoing-decisions: repeatedly check during ongoing usage phase

onA, onB, onC Decision Continuity

UCON Model for Collaborations Objects:

Resources: data, services, facilities, etc. Subjects:

Consumers Object attributes:

Persistent attributes: type, ownership, etc. Mutable attributes: usage status, inclusive/exclusive accesses,

access history, etc. Subject attributes:

Persistent attributes: role, group, domain name, etc. Mutable attributes: quota of a resource, access history, conflict

groups, credit System attributes:

General environmental/contextual info such as locations, time System configurations, loads, modes, etc.

UCON Model A state of a UCON system is an assignment of values to attributes.

Including subject attributes, object attributes, and system attributes Predicates: boolean expressions built from subject attributes, object

attributes, and system attributes in a single state. s.credit > $1000, o.label={s1, s2, …}

A UCON policy maps a permission (s,o,r)(s,o,r) to a tuple (P(Pprepre, P, Ponon, UP, UPprepre, UP, UPonon, , UPUPpostpost))

PPprepre, P, Ponon,,: predicates of subject and object attributes and system attributes UPUPprepre, UP, UPonon, Up, Uppostpost: pre, ongoing, and post updates

A UCON scheme is a tuple (ATT(ATTaa, ATT, ATTcc, R, P, C), R, P, C), where ATTATTaa: subject and object: subject and object attribute names ATTTTcc: system attributes RR is a finite set of rights, PP is a finite set of predicates CC is a finite set of policies

UCON Policies for Collaborations Consumable resource management

Available resource changes temporally Prevent some DoS attacks by constraining resource usage

Credit or reputation management Global credit/reputation

Task-based access control Control access to shared objects/resources according to task

status Integrity control in a collaborative task

Exclusive/inclusive collaborations An access needs the presence/concurrent involvement of subjects

with different attributes Obligations Context-based authorization

location, transaction info, etc.

Architecture Centralized AR for mutable

subject attributes Persistent subject attribute

authorities Internal or external For persistent attributes

Decentralized UM for object attributes

Decentralized PDP Support RP-level and VO-level

policies

GateKeeper

PDP

ExecutionEnvironment

1. ServiceRequests

with persistentattributes

Servicerequests

Access rights

2. Persistent attributes

Resource Provider(RP)

PEP

6. Privileges

User Platform

Proxy

JobManager

JobDispatch

VO Policies

Platform-specificKnowledge

(ex. grid-mapfile)

ClientAP

Sensors

Attribute Repository(AR)

UsageMonitor(UM)

ProcessInformation

5. ObjectAttributes

PersistentAttributes

DirectoryService

MutableAttributes

9. Subject or SystemAttribute Changes

3. MutableAttributeRequest

4. MutableAttributes

7. UpdatedAttributes(Subject)

8. UpdatedAttributes(Object)

Attribute Acquisition Push and pull modes of attribute

acquisition:

UserWorkstation

Architecture A hybrid of push and pull

Persistent attributes are pushed by users

GateKeeper

PDP

ExecutionEnvironment

1. ServiceRequests

with persistentattributes

Servicerequests

Access rights

2. Persistent attributes

Resource Provider(RP)

PEP

6. Privileges

User Platform

Proxy

JobManager

JobDispatch

VO Policies

Platform-specificKnowledge

(ex. grid-mapfile)

ClientAP

Sensors

Attribute Repository(AR)

UsageMonitor(UM)

ProcessInformation

5. ObjectAttributes

PersistentAttributes

DirectoryService

MutableAttributes

9. Subject or SystemAttribute Changes

3. MutableAttributeRequest

4. MutableAttributes

7. UpdatedAttributes(Subject)

8. UpdatedAttributes(Object)

Mutable attributes are pulled by PDP from UM and AR

Architecture Policy query

GateKeeper

PDP

ExecutionEnvironment

1. ServiceRequests

with persistentattributes

Servicerequests

Access rights

2. Persistent attributes

Resource Provider(RP)

PEP

6. Privileges

User Platform

Proxy

JobManager

JobDispatch

VO Policies

Platform-specificKnowledge

(ex. grid-mapfile)

ClientAP

Sensors

Attribute Repository(AR)

UsageMonitor(UM)

ProcessInformation

5. ObjectAttributes

PersistentAttributes

DirectoryService

MutableAttributes

9. Subject or SystemAttribute Changes

3. MutableAttributeRequest

4. MutableAttributes

7. UpdatedAttributes(Subject)

8. UpdatedAttributes(Object)

Decision enforcement

Attribute Mutability Update of attributes

Subject attributes updated to AR

GateKeeper

PDP

ExecutionEnvironment

1. ServiceRequests

with persistentattributes

Servicerequests

Access rights

2. Persistent attributes

Resource Provider(RP)

PEP

6. Privileges

User Platform

Proxy

JobManager

JobDispatch

VO Policies

Platform-specificKnowledge

(ex. grid-mapfile)

ClientAP

Sensors

Attribute Repository(AR)

UsageMonitor(UM)

ProcessInformation

5. ObjectAttributes

PersistentAttributes

DirectoryService

MutableAttributes

9. Subject or SystemAttribute Changes

3. MutableAttributeRequest

4. MutableAttributes

7. UpdatedAttributes(Subject)

8. UpdatedAttributes(Object)

Object attributes updated to UM

Decision Continuity Event-based ongoing decision checking

Subject attribute update events

GateKeeper

PDP

ExecutionEnvironment

1. ServiceRequests

with persistentattributes

Servicerequests

Access rights

2. Persistent attributes

Resource Provider(RP)

PEP

6. Privileges

User Platform

Proxy

JobManager

JobDispatch

VO Policies

Platform-specificKnowledge

(ex. grid-mapfile)

ClientAP

Sensors

Attribute Repository(AR)

UsageMonitor(UM)

ProcessInformation

5. ObjectAttributes

PersistentAttributes

DirectoryService

MutableAttributes

9. Subject or SystemAttribute Changes

3. MutableAttributeRequest

4. MutableAttributes

7. UpdatedAttributes(Subject)

8. UpdatedAttributes(Object)

Object attribute update events

System attributes change

Architecture Other Design Issues:

Authenticity of attribute values Concurrency control of updates

Prototype A collaborative software

development system RP: Debian GNU/Linux 2.4.18 User platform: Windows XP AR: OpenLDAP UM: DB4Object database Communication channel:

OpenSSL Policy: XACML PDP and attribute management:

Sun’s XACML implementation Enforce location-based and

task-based policies for software package view and update

mod_authz_ucon(PEP)

PDP

Subversion

1. Service requestwith a usercertificate

Access rights

2. User identity andservice request

Resource Provider

User Platform

Apache

JobDispatch

XACML

Subversion Client

Sensor

Attribute Repository

UsageMonitor

ProcessInformation

5. ObjectAttributes

OpenLDAPw/

OpenSSL

User Location/Object Attrs.

9. Updated attributes

3. LDAPrequest

4. LDAPresponse

7. Updatedattributes

User Certificate AR Certificate

RP Certificate

mod_dav_svn 6. Privilege

8. Updatedattributes

Servicerequest

Proxy

Location-based Policy Alice and Bob, from Corp. A

and B, form VO1 for a project.

Packages only can be viewed in either A or B

Task-based Policy A package is locked for

test by a user (tester)

Only tester can access or update it.

Performance Evaluation

Mainly on PDP Fetching subject attributes Fetching object attributes XACML policy interpretation Update of mutable attributes

only objects in our prototype Communication

Improvement on subject attribute acquisition:

Keep-alive connections with SSL

Attribute value cache

Conclusions A framework for collaborative computing

systems Following OM-AM framework

Policy/model: UCON Architecture:

Hybrid of push and pull modes Support attribute mutability and decision continuity

Prototype: XACML Location-based and task-based policies Performance study

Ongoing and Future Work Support obligations

Obligation monitoring and reporting mechanisms

Extend XACML to check obligation satisfactions

Support authorization delegations Attribute-based delegation model