Janice Warner and Vijayalakshmi Atluri Rutgers University

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

Policies

Janice Warner and Vijayalakshmi AtluriRutgers University

Ravi MukkamalaOld Dominion

University

ICISSDecember 2005

December 2005 ICISS05-Warner, Atluri and Mukkamala

2

Objective

Map local RBAC policies to credential requirements for collaborations.

ProjectManager

Role

Subjects

Privilege

Credential Attributes:

- Project management certified

- Project Team member- 5+ years of experience


3

Why?• Today’s 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

B

P

V

Y

G

P – YP – V – BP – 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 publicizedAgreements 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 policyAny 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

Network (e.g., Internet)

DCBAC Architecture

Local User Interface

Local AccessControl (LAC)

Credential toLAC Mapper

Credential Filter

Local User Interface

Local AccessControl (LAC)

Credential toLAC Mapper

Credential Filter

Coalition Level Coalition Level

Local Services(shared and private)

Local Services(shared and private)

CoalitionService Registry

(CSR)

CoalitionAccess Point

(CAP)


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

Reqts Analyst SW Developer System Tester

Project Manager

Client Manager

Reqts Analyst- Skyco SW Developer - SkyCo System Tester-SkyCo

Project Manager – Code Red Project Manager – Blue Skies

Client Manager - SkyCo


13

Policies Set on Resource Types

Project Data(res_id=700)

Testing Methods (res_id=510)

Code Red(res_id=730)

… … …

Technology Reports(res_id=500)

HapSysResource Hierarchy

Lab Configuration(res_id= 514)

…

Blue Skies(res_id=710)

(res_id = 517)

Test Case Library Project Plan

(res_id = 722)Test Results(res_id = 729)

Market Data(res_id = 731)

Requirements(res_id = 735)


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 > LA > IA• Graph may be a

forest• Stores attributes as

nodes, number of users as weights, and attribute values as node labels.

ga1

w eight: 10value range:{BA, BS, MS}

ga2

w eight: 10value range:

{part-time,full-time}

ga3w eight: 10

value range:{2 ... 19}

ga4

w eight:7value range{MLK, CDC,

RAM}

la1

w eight 7value range:

{System Tester- Smith&co.}

ga1 - degreega2 - employment statusga3 - years of experiencega4 - certif icationla1 - rolela2 - groupla3 - of f iceia1 - nameia2 - e-mail address

la1



la2


{12345, 12399.}

la2


{12345, 12399.}

la3

w eight 3value range:{NWK, NYC}

la3

w eight 2value range:{NWK, HOL}

ia1

w eight 2value range:{DSlade.....}

ia1


{JCruz....}ia1

w eight 3value range:{EGiebel.....}


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


• 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


• 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 SelectionSuppose SkyCo asks Ellen Jones of Test-it-Sys to review the test results for project Blue Skies (red_id = 729)

ga1

w eight: 10value range:{BA, BS, MS}

ga2

w eight: 10value range:

{part-time,full-time}

ga3w eight: 10

value range:{2 ... 19}

ga4

w eight:7value range{MLK, CDC,

RAM}

la1



ga1 - degreega2 - employment statusga3 - years of experiencega4 - certif icationla1 - rolela2 - groupla3 - of f iceia1 - nameia2 - e-mail address

la1



la2


{12345, 12399.}

la2


{12345, 12399.}

la3

w eight 3value range:{NWK, NYC}

la3

w eight 2value range:{NWK, HOL}

ia1

w eight 2value range:{DSlade.....}

ia1


{JCruz....}ia1

w eight 3value range:{EGiebel.....}

Attributes selectedif largest attribute group strategy used

Attributes selectedif typical profile strategy used with = .5 x Up = 5.


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.

AttributeOntologyCredential

AttributeBase

InternalAttribute

Base


22

Step 3 – Transformation of Attributes• Three options exist for transforming identity and

local attributes into general attributes:1. 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).

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

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

Janice Warner and Vijayalakshmi Atluri Rutgers University

Documents

Transcript of Janice Warner and Vijayalakshmi Atluri Rutgers University