ICDCIT04

Views:
 
Category: Entertainment
     
 

Presentation Description

No description available.

Comments

Presentation Transcript

Automatic Enforcement of Access Control Policies Among Dynamic Coalitions: 

Vijayalakshmi Atluri MSIS Department and CIMIC Rutgers University - USA Automatic Enforcement of Access Control Policies Among Dynamic Coalitions

Coalition Resource Sharing: 

Coalition Resource Sharing Dynamic and Ad-hoc – members may leave and new members may join Examples: Natural Disaster: government agencies (e.g., local police and fire departments), non-government organizations (e.g., Red Cross) and private organizations (e.g. Doctors without Borders) may share data about victims, supplies and logistics. Homeland Security: Information collected by various governmental agencies shared for comprehensive data mining Virtual Enterprises: Collaboration between companies

Current Sharing Approaches are Either Administratively Prohibitive or Insecure: 

Current Sharing Approaches are Either Administratively Prohibitive or Insecure Current Approaches: User ids given to each external member of the coalition and access control is provisioned on these ids. Problem: administratively burdensome and requires explicit revocation upon coalition termination or when user is no longer affiliated with coalition entity Single access id provided to each external coalition entity Problem: Fine-grained access control is not possible Resources are copied to external coalition member Problem: Updates are difficult and may result in uncontrolled sharing

Translation of coalition level policies to implementation level : 

Translation of coalition level policies to implementation level Need to transform higher level (coalition level) security policies on data sharing among agencies to implementation level and vice versa percolation of low level details to organization level Agreements between agencies A and B (coalition level) are not at the level that specify fine-grained access control policies E.g., “a user Alice of agency B can access a file on immigrants of agency A.” Trivial solution: form teams (workgroups) comprising of employees at the corresponding levels of both agencies not practical and scalable, may result in delays

Translation of coalition level policies to implementation level (continued): 

Translation of coalition level policies to implementation level (continued) Develop a formal model enables handshaking of relevant information by appropriate levels of the agencies similar to the layers in the TCPIP network protocol will enable the implementation level details be piggy-backed as the access control policy percolates to the coalition level, The coalition level policies trickle down to the implementation level

Principles of Our Model: 

Principles of Our Model Principle 1: Existing access control mechanisms within each entity should remain intact. Principle 2: A common access control model will best facilitate automation of policy decisions. Principle 3: Administration of the coalition access control model should be decentralized and remain in the hands of the resource users.

Layered CBAC Model: 

role segment user-object request Layered CBAC Model User-Object Level Role Level Coalition Level user-object request Entity A Entity B User-Object Level Role Level Coalition Level

Essential Formalisms: 

Essential Formalisms Objects (OBJS) Each belongs to an object type which have object-type ids (ot_id) and attributes. Described by the triple (ot_id, obj_id, obj-attr-values) Permissions can be assigned on individual objects or object types to allow for aggregation. Credentials (c) An instance of a credential type (ct) Described by a 4-tuple (ct_id, c_id, user_id, user-profile) User-profile is a set of attributes values for the user

Essential Formalisms: 

Essential Formalisms Coalition (C) Described by a tuple (coalition_id, E) where E = {e1, e2, …} is a set of coalition entities that have unique identifiers. Coalition Level Policy Specification (p) p = (coalition_id, source_entity_id, destination_entity_id, source_object_type) One or more p can apply to a coalition C Statement of object types allows the policy to be stated at a more abstract level, facilitating the dynamic addition of new objects w/o having to change p

Mapping Credentials to Objects: 

Mapping Credentials to Objects Each subject is associated with one or more credentials. The credentials associated with a role r is the union of all the credentials associated with the subjects assigned to a role r. At the destination, the credentials associated with a role rd assigned to the requesting user ud are extracted to submit with the request for the object. The set of required credential attributes to access an object (obj) is defined as the credentials associated with a role r that has permission to access obj. At the source, the required credential attributes for the requested object are compared against the submitted credentials.

Policy Translation: 

Policy Translation Key Idea: Users are not mapped to a specific role at the source entity. Instead, their credential attributes are matched with those required to access an object. Algorithm User requests access to remote object. (user-object level) User’s potential local role set is identified. (role level) Credentials associated with local roles are extracted. (role level) Request message containing the credentials are sent to the object source based on policy p. (coalition level) Credential attributes necessary to access object extracted from examining local source roles that have permission and compared with destination credentials. (role level) If destination credentials are sufficient, access to object is permitted. (user-object level)

Example Scenario: 

Example Scenario Dr. Roberts, a member of Doctors Without Borders, wishes to access data on infection diseases in the area of an earthquake (Turkey) in a database maintained by the International Red Cross. Dr. Roberts is a member of the internal role “doctor” He has a credential “medical-doctor” which has attributes: affiliation: Doctors without Borders speciality: Immunology

Object Hierarchy: 

Object Hierarchy

Objects Relevant to the Coalition: 

Objects Relevant to the Coalition

Example Scenario: 

Example Scenario Role Interpreter User-Object Access Controller Doctors Without Borders International Red Cross Coalition-level Policy interpreter Role Interpreter User-Object Access Controller Coalition-level Policy interpreter

CBAC System Architecture: 

CBAC System Architecture Collaborative Interface Credential Issuer Entity 1 Existing Systems (DBs, File systems, Workflow systems) Role Hierarchy Object Hierarchy Entity 1 Coalition Control System RBAC Module RBAC Module Entity 2 Existing Systems (DBs, File systems, Workflow systems) Role Hierarchy Object Hierarchy Entity 2 Coalition Control System

CBAC Components: 

CBAC Components Role Hierarchy Identifies objects in the object db that can be accessed by defined roles. Specifies credentials that are to be associated with the role. Indicates actions allowed on the objects or actions specifically denied Tracks roles granted to coalition members and roles received from coalition members

CBAC Components: 

CBAC Components Object Hierarchy DB: Contains description of resources that can be externally shared within coalitions Is arranged in a hierarchy so that permissions can be given at different levels Stores attributes of objects including object types, keywords, concepts. Includes the physical location of objects Contains conditions on sharing with external organizations

Future Research: 

Future Research Shared Ownership of Objects Formation of Coalitions Based on Published Policies Rather than High Level Agreements Separation of Duty and other Constraints Delegation Implementation

authorStream Live Help