A Usage-based Authorization Framework for Collaborative Computing Systems Xinwen Zhang George Mason University Masayuki Nakae NEC Corporation Michael J. Covington Intel 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 users access Quality of access Resource constraints

Existing Approaches Grid-mapfile: Mapping users to local identities Not scalable Community Authorization Service (CAS): (Policy02) Centralized PDP, scalable Not dynamic and flexible, heavy infrastructure VOMS: (FGCS05) PDP in RP side Only persistent attributes from global attribute authorities PRIMA: (Grid03) 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. SACMAT01) Context-agent collecting environmental info (Zhang & Parasar, ICGC03) Context sensitive access control (Hulsebosch et al. SACMAT05)Hulsebosch User-presence-aware authorization (Noda et al. SACMAT06)

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.

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) Attributes can be updated as side-effects of a usage: pre, ongoing, and post updates Attribute Mutability Core models: preA 0, preA 1, preA 2, preA 3, onA x, preB x, onB x preC x onC x A real model may be a combination of core models. 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, …} (s,o,r)(P pre, P on, UP pre, UP on, UP post ) A UCON policy maps a permission (s,o,r) to a tuple (P pre, P on, UP pre, UP on, UP post ) P pre, P on, P pre, P on,: predicates of subject and object attributes and system attributes UP pre, UP on, Up post UP pre, UP on, Up post : pre, ongoing, and post updates (ATT a, ATT c, R, P, C) A UCON scheme is a tuple (ATT a, ATT c, R, P, C), where ATT a : subject and object ATT a : subject and object attribute names TT c ATT c : system attributes R R is a finite set of rights, P P is a finite set of predicates C C 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

Attribute Acquisition Push and pull modes of attribute acquisition:

Architecture A hybrid of push and pull Persistent attributes are pushed by users Mutable attributes are pulled by PDP from UM and AR

Architecture Policy query Decision enforcement

Attribute Mutability Update of attributes Subject attributes updated to AR Object attributes updated to UM

Decision Continuity Event-based ongoing decision checking Subject attribute update events 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 User platform: Windows XP AR: OpenLDAP UM: DB4Object database Communication channel: OpenSSL Policy: XACML PDP and attribute management: Suns XACML implementation Enforce location-based and task- based policies for software package view and update

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