Janice Warner and Vijayalakshmi Atluri Rutgers University

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 Privilege Project Manager ICISS05-Warner, Atluri and Mukkamala

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. ICISS05-Warner, Atluri and Mukkamala

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 ICISS05-Warner, Atluri and Mukkamala

5. Extracting Policies Has Other Applications • Web Service Offers • Grid Computing • Privacy and Security Legislation Compliance • Role Mining ICISS05-Warner, Atluri and Mukkamala

6. Outline • Collaborative Sharing Model • Motivating Example • Policy Transformation Steps • Conclusions and Future Work ICISS05-Warner, Atluri and Mukkamala

7. What is a collaboration or coalition? P G • 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 Y V P – Y P – V – B P – B – G ICISS05-Warner, Atluri and Mukkamala

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. ICISS05-Warner, Atluri and Mukkamala

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. ICISS05-Warner, Atluri and Mukkamala

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

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. ICISS05-Warner, Atluri and Mukkamala

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 ICISS05-Warner, Atluri and Mukkamala

13. Lab Configuration Test Case Library Project Plan Test Results Market Data Requirements (res_id= 514) (res_id = 517) (res_id = 722) (res_id = 729) (res_id = 731) (res_id = 735) Policies Set on Resource Types HapSys Resource Hierarchy Technology Reports … Project Data (res_id=500) (res_id=700) Testing Methods Code Red Blue Skies (res_id=510) (res_id=710) (res_id=730) … … … ICISS05-Warner, Atluri and Mukkamala

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 ICISS05-Warner, Atluri and Mukkamala

15. Policy Transformation Steps • Identify potential required attributes to obtain privilege. • Apply selection strategies to select a subset of the identified attributes. • Transform LA and IA (if they were selected) into comparable credential attributes. ICISS05-Warner, Atluri and Mukkamala

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. ICISS05-Warner, Atluri and Mukkamala

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. ICISS05-Warner, Atluri and Mukkamala

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. ICISS05-Warner, Atluri and Mukkamala

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. ICISS05-Warner, Atluri and Mukkamala

20. Attributes selected if largest attribute group strategy used Attributes selected if typical profile strategy used with  = .5 x Up = 5. Example Attribute Selection Suppose SkyCo asks Ellen Jones of Test-it-Sys to review the test results for project Blue Skies (red_id = 729) ICISS05-Warner, Atluri and Mukkamala

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 ICISS05-Warner, Atluri and Mukkamala

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. ICISS05-Warner, Atluri and Mukkamala

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. ICISS05-Warner, Atluri and Mukkamala

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. ICISS05-Warner, Atluri and Mukkamala