An Attribute Graph Based Approach to Map Local Access Control Policies to Credential Based Access Control Policies

1
An Attribute Graph Based Approach to Map Local
Access Control Policies to Credential Based
Access Control Policies

• Janice Warner and Vijayalakshmi Atluri
• Rutgers University

Ravi Mukkamala Old Dominion University
ICISS December 2005
2
Objective

• Map local RBAC policies to credential
  requirements for collaborations.

Subjects

• Credential Attributes
• Project management certified
• Project Team member
• 5 years of experience

Role
Project Manager
Privilege
3
Why?

• Todays collaborations among organizations are
  increasingly
• Short-lived
• Dynamic
• Ad-hoc
• Need access control that is dynamic and efficient
  for such an environment
• Our proposal allows users, external to the
  organization, access to resources if they possess
  certain attributes similar to those possessed by
  internal users.

4
Two Alternatives

• Translate all collaborators policies into a
  common model
• Difficult
• Not dynamic
• Requires centralized processing
• Make policies interpretable with distributed
  control what we are striving for

5
Extracting Policies Has Other Applications

• Web Service Offers
• Grid Computing
• Privacy and Security Legislation Compliance
• Role Mining

6
Outline

• Collaborative Sharing Model
• Motivating Example
• Policy Transformation Steps
• Conclusions and Future Work

7
What is a collaboration or coalition?

• Group of independent entities that have resources
  they are willing to share under certain
  conditions.
• Dynamic and Ad-hoc members may leave and new
  members may join.
• Examples
• Natural Disaster government agencies,
  non-government organizations and private
  organizations 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

P
G
B
Y
V
P Y P V B P B G
8
Dynamic Coalition-Based Access Control Model
(DCBAC)

• Dynamic because
• Employs a Coalition Service Registry (CSR) where
  shared resources and coalition level policies are
  publicized
• Agreements do not need to established between
  coalition partners beforehand
• Computes credentials needed by external user from
  local access control policies through Mapper
  layer.
• Coalition access control policy determined
  through transformation of local access control
  policy
• Any resource could be shared at any time as long
  as the external party has the right credentials.

9
Principals of DCBAC

• Existing access control mechanisms within each
  coalition entity remain intact.
• Access rights are granted to subjects only if
  they belong to an organization recognized by the
  coalition.
• Subjects of a coalition entity must have
  credentials with attribute values comparable to
  those of local subjects.

10
DCBAC Architecture
Network (e.g., Internet)
Coalition Access Point (CAP)
Coalition Level
Coalition Level
Coalition Service Registry (CSR)
Credential Filter
Credential Filter
Credential to LAC Mapper
Credential to LAC Mapper
Local Access Control (LAC)
Local Access Control (LAC)
Local Services (shared and private)
Local Services (shared and private)
Local User Interface
Local User Interface
11
Motivating Example

• Consider HapSys, a software development company.
• They have parameterized roles allowing separation
  of permissions by client and/or project.
• One client, SkyCo would like to allow members
  from a third organization, Test-it-Sys, to review
  test results for project Blue Skies.
• HapSys allows this if a user from Test-it-Sys can
  provide appropriate credentials.

12
Motivating Example
Client Manager - SkyCo
Client Manager
Project Manager Code Red
Project Manager Blue Skies
Project Manager
Reqts Analyst- Skyco
SW Developer - SkyCo
System Tester-SkyCo
SW Developer
System Tester
Reqts Analyst
13
Policies Set on Resource Types
HapSys
Resource Hierarchy
Technology Reports
Project Data

(res_id500)
(res_id700)
Testing Methods
Code Red
Blue Skies
(res_id510)
(res_id730)
(res_id710)



14
User Attributes (A)

• Assume each user is associated with a set of
  attributes
• Identifier Attributes (IA) one to one
  correspondence between the attribute value and a
  user (e.g., e-mail address)
• General Attribute (GA) one to many
  correspondence between the attribute value and a
  set of users (e.g., academic degree)
• Local Attribute (LA) any general attribute for
  which values are valid only within an
  organization (e.g., department)
• A IA ? LA ? GA

15
Policy Transformation Steps

1. Identify potential required attributes to obtain
   privilege.
2. Apply selection strategies to select a subset of
   the identified attributes.
3. Transform LA and IA (if they were selected) into
   comparable credential attributes.

16
Step 1 Build Attribute Graph

• Used to determine sets of user attributes (and
  values) that might be associated with a privilege
• Assumes specific order among attributes
• GA gt LA gt IA
• Graph may be a forest
• Stores attributes as nodes, number of users as
  weights, and attribute values as node labels.

17
Step 2 Attribute Selection

• Conservative Strategy
• Require full collection of attributes held by all
  users assigned to role r with privilege p.
• Greater requirement than any single internal user
  and would likely result in no external user
  gaining access.

18
Step 2 Attribute Selection

• Largest Attribute Group Strategy
• Uses attribute graph Each path from root to
  leaf in any tree T ? AG represents the full set
  of attributes of one or more users in U.
• Longest path would have the next most
  conservative attribute requirement that is
  actually held by one or more users.
• But the longest path might be an exception so
  may not be the best choice.

19
Step 2 Attribute Selection

• Typical Profile Strategy
• Uses weights of attribute graph.
• Attributes chosen based on perceived importance
  of a user attribute.
• Attributes are considered critical if the weight
  of the attribute is greater than ?, a settable
  parameters.
• If more than one path in AG has nodes with
  weights greater or equal to ?, the sets of
  attributes in each path can be considered as a
  set of alternative attribute requirements.

20
Example Attribute Selection

• Suppose SkyCo asks Ellen Jones of Test-it-Sys to
  review the test results for project Blue Skies
  (red_id 729)

21
Step 3 Transformation of Attributes

• General attributes are attributes that can be
  held by any individual (inside or outside the
  organization)
• No transformation may be necessary
• But, may have problem of semantics
• Translation could be done using a terminological
  ontology.

Attribute
Credential
Internal
Ontology
Attribute
Attribute
Base
Base
22
Step 3 Transformation of Attributes

• Three options exist for transforming identity and
  local attributes into general attributes
• Require attribute External users may be
  required to present an id or group attribute of
  the correct form, but with no particular
  values.Any value in a valid credential would be
  accepted and stored (for audit or to build up an
  ontology).
• Modify attribute External users would be
  required to present an identity attribute for
  someone or something else, such as the person who
  delegated rights to them or the organization to
  which they belong.
• Ignore attribute Make privilege decision only
  on the basis of other attributes in selected set.

23
Conclusions

• Proposed an attribute graph based approach to
  enable secure sharing of information in a
  collaboration.
• Ensures that internal security policies are
  adhered to when providing access to users of
  external organizations.
• External users are provided access to resources
  if they possess attributes that are in some sense
  similar to those possessed by internal users.

24
Ongoing Work

• Data mining of logs, local policies, and other
  security related data to obtain
• Groupings of users with similar data requirements
  and attributes
• Groupings of resources
• From these groupings, collaborative properties
  may be derived.
• Resolving semantic heterogeneity between policies
  and credential attributes using ontologies.