240 likes | 395 Views
Annotation-Based Access Control. Peyman Nasirifard University College Dublin, Dublin, Ireland July 1st 2009. Outline. Access control in social platforms How we share resources in real-life Annotation-Based Access Control (patent pending) Prototype: Uncle-Share Scenario OR Live Demo
E N D
Annotation-Based Access Control Peyman NasirifardUniversity College Dublin, Dublin, Ireland July 1st 2009
Outline • Access control in social platforms • How we share resources in real-life • Annotation-Based Access Control (patent pending) • Prototype: Uncle-Share • Scenario OR Live Demo • Annotation-Based Access Control Add-on (Plug-in) • Discussions • Conclusion • Q and A
Access Control in Social Platforms • One of the key concepts of Web 2.0 platforms is „Sharing“ • Sharing needs access control • Problems with current approaches within social and cooperative platforms: • Coarse-grained: • Private vs. Public • Share with individuals • Groups • 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 terms may differ between people • parent, supervisor, friend, close friend, director, athletic, honest, etc. • Real-life model can be applied to online model • Annotation-Based Access Control • more natural and flexible
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: 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: Only the Resource owner is eligible to define Policies for that Resource. • Rule: A private Resource has zero or more Policies, whereas a public Resource has at least one Policy. • Rule: The default Distance for Policies is one.
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.
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 packages
Question Scenario or Live Demo?
Who Will Access 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
Mining Tags • Helping users to Tag people with their expertise • Our current approach uses log files of shared workspaces
Who is working with whom? • Helping users to find proxies • Our current approach uses log files of shared workspaces
HeyStaks • I am a fan of HeyStacks • There are some user interface and privacy issues • Out of scope of this presentation • There exist two (or three) main methods for sharing staks in HeyStaks • Users can select one or more buddies from their friend list to share a stak with them. • Users can enter the email addresses of other users to share a stak with them. • Maybe based on groups as well
HeyStaks • Enabling users to have friends (buddies). • Heystaks can also propose some friends: for example, users with the same email extensions can be friends together and so on. • Adding the feature to enable users to annotate those friends with desired terms. • Minining tags based on saved resources • Enabling users to define access control policies for staks based on annotations. • Main access control engine to control the access to resources (staks) based on previous annotations and policies.
Conclusion and Future Work • We presented Annotation-Based Access Control • Distance and Annotation are two important factors • Propagation of the policies • Widget-based prototype can be embedded into any platform • Some additional add-on • OrbiTeam (BSCW platform) is going to license it for evaluation purposes • Future Work • Recommendar system for people-tags • Helping users for determining the appropriate annotation and distance • Integrating this model with BSCW
Thank You! Q and A