 Copyright 2008 Digital Enterprise Research Institute. All rights reserved. Digital Enterprise Research Institute Uncle-Share: Annotation-Based Access Control for Cooperative and Social Systems Peyman Nasirifard and Vassilios Peristeras The 3rd International Symposium on Information Security (IS'08), Monterrey, Mexico, Nov , 2008

Digital Enterprise Research Institute Introduction Annotation-Based Access Control Use Case Scenario Prototype  Widget: Uncle-Share Conclusion and Future Work Outline

Digital Enterprise Research Institute Current Access Control Sharing data/resources:  Shared Workspaces (BSCW, NetWeaver, SharePoint, etc.)  Social Networking Sites (Flickr, YouTube, del.icio.us, etc.) Sharing needs access control Current approaches:  Access control lists ( contacts)  Role-based access control (root, admin, user)  Social-based access control (friends)

Digital Enterprise Research Institute Problems with Current Access Control Problems with current approaches:  Coarse-grained: – Private vs. Public, share with ‘friends‘  Fixed vocabulary, no flexibility  Access control at application not at resource level  Not context-aware To move from messaging to sharing:  Social-awareness based access-control

Digital Enterprise Research Institute Real-Life Access Control We share resources based on social relationships we attribute to people  We may share our credit card details with our parents, but not with our friends. We mentally annotate people, meaning of term may differ between people  parent, supervisor, friend, close friend, director, etc. Real life model can be applied to online model  Annotation-Based Access Control – more natural and flexible

Digital Enterprise Research Institute Annotation-Based Access Control Model

Digital Enterprise Research Institute Three Entities and Two Concepts A Person is an entity with the RDF type Person. A Person is connected to zero or more other Persons. A Person owns zero or more Resources. A Person defines zero or more Policies. An Annotation is a term or a set of terms that are connected together and aims to describe the Person. Each connection between Persons can be annotated with zero or more Annotations. A Resource is an entity with the RDF type Resource and is owned by (isOwnedBy) one or more Persons. Resources are in the form of URIs, URLs, and/or short messages. A Policy is an entity with the RDF type Policy. A Policy is defined by (isDefinedBy) one Person and belongs to (belongsTo) one Resource. A Policy has one Annotation and one Distance. A Distance is a numerical value which determines the depth that the Policy is valid. The depth is actually the shortest path among two Persons with consideration of Annotations.

Digital Enterprise Research Institute Meta-policies (Rules) Rule 1: A Person acquires access to a Resource, if and only if (iff) s/he meets all policies that have been defined by Resource owner for that Resource. It means that the Person has been already annotated with the Annotations which are defined in the Policies and s/he is also in the scope of the Policies (i.e. Distance criteria).  Multiple Policies that are defined by a Resource owner for a Resource are ORed, if they have different Distances, otherwise the Policies are ANDed. Rule 2: Only the Resource owner is eligible to define Policies for that Resource. Rule 3: If a Person acquires access to a Resource, s/he may copy/add the Resource to his/her Resources. In this case, s/he will be the Resource owner. (The original Resource owner will also keep the ownership as well.) Rule 4: A private Resource has zero or more Policies, whereas a public Resource has at least one Policy. Rule 5: The default Distance for Policies is one.

Digital Enterprise Research Institute Benefits of Annotation-Based Approach Close to real-life model Simple  We tried to keep the model as simple as possible – Resources have (currently) no annotations – The main focus of this model is annotating contacts rather than resources Flexible  Fixed terms & Open Vocabularie Semantics helps for further reasoning Distance among users may be calculated All relationships are private  Users can freely publish their realtionships

Digital Enterprise Research Institute Use Case Scenario

Digital Enterprise Research Institute Who Will Access What? Alice has access to her three resources and via Bob, because is accessible to the Bob's contacts that have been annotated as student and have maximum distance one to Bob and Alice fulfils this policy. Bob has access to his two resources and also two of Alice's resources: and Tom has access to which was shared via Bob to him and also which was shared via Alice to him. Mary will see the short message from Alice: I_need_to_talk_to_you_please.

Digital Enterprise Research Institute Prototype: Uncle-Share Widget Login: User login or registration, including full name, user name, and password. Person: User may add, modify, and annotate contact list. Resources: User may add resources (URI/short message) and assign them policies. Shared: User may see the resources that have been shared with him by others. The distance may be set in order to increase or decrease the scope of the shared resources. Settings: User and server configuration. Help: Provides a tutorial video and some technical and contact information regarding the platform.

Digital Enterprise Research Institute Features Widget  Can be embedded into any Web page or widget platform  Syndication, flexibility, portability, and customization. Service-Oriented-Architecture (SOA)  All functionalities are wrapped as services Ontology-based and RDF-based AJAX (i.e. No additional interations with the server) Suggest box  Suggests annotations to end users  Currently the suggestions come from the RELATIONSHIP ontology We used free and open source tools

Digital Enterprise Research Institute Embedded Widget (iGoogle and BSCW)

Digital Enterprise Research Institute Uncle-Share Architecture

Digital Enterprise Research Institute Uncle-Share Services Handle Object: This service enables end users to register themselves to the system and/or change their passwords. Handle Connection: This service enables end users to add connections between persons; persons and resources; and persons and policies. This service enables also end users to annotate those connections with closed and/or open terms. Get Connection: This service enables end users to get who/what is connected to a specific person. Get Registered Users: This service returns the list of the registered users. Get Social Network: This service returns the social network of authenticated user in RDF. Get Available Resources: This service returns the available resources to a specific person based on the Distance input.

Digital Enterprise Research Institute Extended Work: Experimental Evaluation We asked 16 people to participate in an experimental evaluation  Name at least 5 persons that they know  Assign at least 3 annotations for each of their contacts Results  8 participants confirmed that the task was pretty easy – They use various sorts of annotations: hasADog, likesHorrorMovies, laughALot, writePaperWith, goingOutWith, worksWith, discussIdeasWith, etc.  4 participants found its difficulty medium  4 participants found it difficult – They never annotate somebody on a paper or with a software tool, however they did it „mentally“ before – They tried to be over-cautious, as they were worried that their annotations might be further distributed (privacy issues)

Digital Enterprise Research Institute Comparisons and Evaluations Role-Based Access Control (RBAC), Generalized RBAC (G-RBAC), etc.  Roles and permissions are pre-defined by role engineers – Users get permissions through roles and/or role hierarchy  We do not have predefined roles and permissions  We have annotations – User-centric approch – May not be roles (from semantics point of view) – From RBAC perspective: Annotations can be seen as „user-defined“ roles.  We have graph-like connected people rather than hierarchy – Distance among two persons can be calculated and used  Semantics can be used for reasoning Logic-Based Access Control Frameworks (like PROTUNE)  Very powerful, but too complex for personal usage No Percentage for relationships (e.g. friend 80%)  We do not label our friendships and contacts with percentages in real-life

Digital Enterprise Research Institute Future Work Run an extended evaluation exercise in the context of the Ecospace IP project (Living Labs) Extend the model to include context-aware information  perhaps using micro-blogs (e.g. Twitter) Using the Open Social API to integrate the widget with existing social networking platforms, such as MySpace and Orkut Prioritizing policies Context-aware term recommendations  Based on statistics Social network analysis  Using this analysis in access control

 Copyright 2008 Digital Enterprise Research Institute. All rights reserved. Digital Enterprise Research Institute Thank you for your attention! 20 of 4 Peyman Nasirifard and Vassilios Peristeras Try Uncle-Share yourself: