A Usage-based Authorization Framework for Collaborative Computing Systems

1. A Usage-based Authorization Framework for Collaborative Computing Systems Xinwen Zhang George Mason University Masayuki Nakae NEC Corporation Ravi Sandhu George Mason University and TriCipher Inc. Michael J. Covington Intel Corporation

2. 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

3. 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

4. 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

5. 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)

6. 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

7. Approach: OM-AM • Closing the gap between informal objective (or policies, requirements) and concrete implementation mechanisms.

8. 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

9. 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 (Park and Sandhu 2004) • 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.

10. 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.

11. 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) to a tuple (Ppre, Pon, UPpre, UPon, UPpost) • Ppre, Pon,: predicates of subject and object attributes and system attributes • UPpre, UPon, Uppost: pre, ongoing, and post updates • A UCON scheme is a tuple (ATTa, ATTc, R, P, C), where • ATTa: subject and object attribute names • ATTc: system attributes • R is a finite set of rights, • P is a finite set of predicates • C is a finite set of policies

12. 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.

13. 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

14. Attribute Acquisition • Push and pull modes of attribute acquisition:

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

16. Architecture • Policy query • Decision enforcement

17. Attribute Mutability • Update of attributes • Subject attributes updated to AR • Object attributes updated to UM

18. Decision Continuity • Event-based ongoing decision checking • Subject attribute update events • Object attribute update events • System attributes change

19. Architecture • Other Design Issues: • Authenticity of attribute values • Concurrency control of updates

20. 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

21. 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

22. Task-based Policy • A package is locked for test by a user (tester) • Only tester can access or update it.

23. 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

24. 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

25. Ongoing and Future Work • Support obligations • Obligation monitoring and reporting mechanisms • Extend XACML to check obligation satisfactions • Support authorization delegations • Attribute-based delegation model