Copyright 2008 Digital Enterprise Research Institute. All rights reserved. Digital Enterprise...

Copyright 2008 Digital Enterprise Research Institute. All rights reserved.

Digital Enterprise Research Institute www.deri.ie

An Annotation-based Access Control Model and Tools for Collaborative

Information Spaces

Peyman Nasirifard, Vassilios Peristeras, Stefan Decker

[email protected]


Introduction Annotation-Based Access Control Use Case Scenario Collaboration Vocabulary (CoVoc) Prototypes

Widget: Uncle-Share Visualization based on CoVoc terms: Who-With-Whom

Conclusion and Future Work

Outline


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 (email contacts) Role-based access control (root, admin, user) Social-based access control (friends)


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


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


Annotation-Based Access Control Model


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.


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

Rule 2: Only the Resource owner is eligible to define Policies for that Resource.

Rule 3: A private Resource has zero or more Policies, whereas a public Resource has at least one Policy.

Rule 4: The default Distance for Policies is one.


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 Vocabularies (See following slides) Semantics helps for further reasoning Distance among users may be calculated All relationships are private

Users can freely publish their realtionships


Use Case Scenario


Who will see what?

Alice has access to her three resources and www.resource5.com via Bob, because www.resource5.com 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: www.resource1.com and www.resource2.com.

Tom has access to www.resource4.com which was shared via Bob to him and also www.resource2.com which was shared via Alice to him.

Mary will see the short message from Alice: I_need_to_talk_to_you_please.


Collaboration Vocabulary

CoVoc: A vocabulary for describing collaborations and e-Professionals (mainly researchers)

Five main categories An e-Professional (researcher) collaborates in different projects An e-Professional (researcher) participates in different events like

conferences and workshops and publishes various stuff An e-Professional (researcher) may be part of the university board An e-Professional (researcher) can be involved in industry An e-Professional (researcher) has various online (social) activities

For each category, we proposed some terms writeDeliverableWith, hadCoffeeBreakWith, supervisor, CEO,

readNewsOf We built RDF schema for CoVoc

Extensible for future needs


Prototypes

Enabling our approach Evalute it We used free and open source tools

Annotation-Based Access Control Uncle-Share

Mashups for helping users to find appropriate contacts Who-With-Whom


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 (URL/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.


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

RDF triples to store data (Sesame) AJAX

No additional interations with the server Suggest Box

Suggests annotations to end users


Embedded Widget (iGoogle and BSCW)


Uncle-Share Architecture


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 (Covoc) 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 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.


Who-With-Whom: A mashup

Social Network Visualization based on CoVoc terms Based on GraphGear (Flash) Fetches data from RDF store (e.g. Uncle-Share)

Helps users to choose/come up with appropriate persons that should be granted access to resources

Part of DERI collaboration network: collaboratesWith (see below)


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-cetnric approch– May not be roles (from semantics point of view)– From RBAC perspective: Annotations are „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


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 could be further distributed (privacy issues)


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 and other APIs to integrate it with existing CWE platforms. embed the uncle-share widget into social networking sites, such as MySpace

or Orkut Prioritizing policies Context-aware term recommendations

Based on statistics Statistical evalutation of CoVoc terms usage

Further refinement of the terms More mashups based on user annotations Social network analysis

Using this analysis in access control

Copyright 2008 Digital Enterprise Research Institute. All rights reserved.


Thank you for your attention!

23 of 4

Peyman Nasirifard, Vassilios Peristeras, Stefan Decker

[email protected]

Try them yourself:http://

epeyman.googlepages.com/

Copyright 2008 Digital Enterprise Research Institute. All rights reserved. Digital Enterprise...

Documents

Transcript of Copyright 2008 Digital Enterprise Research Institute. All rights reserved. Digital Enterprise...