1 / 25

A Usage-based Authorization Framework for Collaborative Computing Systems

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. Collaborative Computing System.

colby
Download Presentation

A Usage-based Authorization Framework for Collaborative Computing Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related