Upload
amelia-pierce
View
226
Download
1
Tags:
Embed Size (px)
Citation preview
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