1 / 13

Privacy-Aware Access Control Framework: Architecture

Privacy-Aware Access Control Framework: Architecture. Giorgos Flouris, Irini Fundulaki ICS-FORTH. Motivation. Build a demonstrator for the privacy-aware access control framework Incorporate work by FORTH and KIT Use it for both access control and privacy

gunda
Download Presentation

Privacy-Aware Access Control Framework: Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Privacy-Aware Access Control Framework:Architecture Giorgos Flouris, Irini Fundulaki ICS-FORTH

  2. Motivation • Build a demonstrator for the privacy-aware access control framework • Incorporate work by FORTH and KIT • Use it for both access control and privacy • Describe the interrelationship/interfaces between the various components of the system • Assign implementation responsibilities • Discuss challenges/issues

  3. General Idea: Users, Roles, Purposes • Several users (authenticated via login/password) • Role-based access control • Each user may take one or more roles • Each role may be attributed to one or more users • At least two roles • Administrator: is able to perform all foreseen tasks • can authenticate, query & update data/roles/users/concrete policies/datasets/authorizations • Simple user: can authenticate, query & update data • Several “simple user” roles (e.g., secretary, professor in a university scenario - nurse, doctor, lab technician in a hospital scenario) • Purpose necessary for privacy • accessing entity: a user associated with a specific role and purpose

  4. General Idea: Datasets and Annotations • Dataset: set of triples • Access Control: • Authorizations (SPARQL queries, abstract tokens) • Annotated Dataset: the application of authorizations to the dataset results to labeled triples (quadruples) • Scenarios (with respect to the number of datasets) • Simple: just one annotated dataset • Complex: • Several datasets • Each associated with several different sets of authorizations • User/administrator can determine which annotated dataset is accessed • Presenting simple version

  5. General Idea: Information Management • Three types of information necessary: • Annotated dataset(s) • Authentication information (users) • Information on roles, purposes and the associated concrete policies

  6. PACEM API Sparql to SQL Translation Module AAC API Annotation Module Evaluation Module • MonetDB • Abstract access control expressions (quadruples) DB Update Module Main Components • administrator interface • authentication • queries • updates • manage datasets, annotations • manage roles, users, purposes • manage concrete policies (CP) • assign CPs to accessing entities AUTH API • User credentials for authentication • user interface • authentication • queries • updates • Privacy-aware Access Control Enforcement Module (PACEM API) • Authentication Module (AUTH API) • Concrete Policy, Role, Purpose (CPRP API) • Abstract Access Control Module (AAC API) AUTH Module AUTH DB CPRP API • Purpose and role hierarchy • Assignment of concrete policies to accessing entities CPRP Module CPRP DB

  7. PACEM API Sparql to SQL Translation Module AAC API Annotation Module Evaluation Module • MonetDB • Abstract access control expressions (quadruples) DB Update Module Authentication (user & administrator) • administrator interface • authentication • queries • updates • manage datasets, annotations • manage roles, users, purposes • manage CPs • assign CPs to accessing entities AUTH API • User credentials for authentication • user interface • authentication • queries • updates AUTH Module AUTH DB success/fail success/fail login, password CPRP API • Purpose and role hierarchy • Assignment of concrete policies to accessing entities CPRP Module login, password CPRP DB

  8. PACEM API Sparql to SQL Translation Module AAC API Annotation Module Evaluation Module • MonetDB • Abstract access control expressions (quadruples) DB Update Module Querying (user) - assuming authentication is successful • administrator interface • authentication • queries • updates • manage datasets, annotations • manage roles, users, purposes • manage CPs • assign CPs to accessing entities AUTH API • User credentials for authentication • user interface • authentication • queries • updates AUTH Module AUTH DB user request (accessing entity, Sparql query) result(triples) CPRP API • Purpose and role hierarchy • Assignment of concrete policies to accessing entities accessing entity CPRP Module Sparql concrete policy CPRP DB result (triples) SQL,concrete policy The administrator can see the abstract labels (no use of concrete policy), and can also query the datasets as a simple user

  9. PACEM API Sparql to SQL Translation Module AAC API Annotation Module Evaluation Module • MonetDB • Abstract access control expressions (quadruples) DB Update Module Updating Data (user) - assuming authentication is successful • administrator interface • authentication • queries • updates • manage datasets, annotations • manage roles, users, purposes • manage CPs • assign CPs to accessing entities AUTH API • User credentials for authentication • user interface • authentication • queries • updates AUTH Module AUTH DB user request (accessing entity, update) success/fail CPRP API • Purpose and role hierarchy • Assignment of concrete policies to accessing entities accessing entity CPRP Module Sparql update concrete policy CPRP DB success/fail SQL update,concrete policy The administrator can see the abstract labels (no use of concrete policy), and can also update the datasets as a simple user

  10. Administrator’s Tasks • Authentication, query, update • As in user, except that administrator has full rights • Administrator can also see the annotation tags (abstract and/or concrete) • Management of system information (add, delete, modify): • Datasets • Authorizations of datasets • On-demand annotation of datasets • Roles, users, purposes, assignment of users to roles etc • Role and purpose hierarchies • Concrete policies • Association of concrete policies to accessing entities • Simple to implement (details omitted)

  11. Other Tasks • Register new user • Change login name/password • Remove user • …

  12. Responsibilities (to be discussed/verified) • FORTH • Interface (part of PACEM) • AAC Module (annotation, evaluation, update) • CPRP API, CPRP Module (definition of CPs, add, delete, modify, manage CPs) • KIT • Sparql to SQL module (part of PACEM) • AUTH API, AUTH Module (management of user credentials) • CPRP Module (purposes, roles, assignment of users to roles, assignment of CPs to accessing entities, management of purpose and role hierarchies, management of conflicts in CP assignments)

  13. Some Issues on Purpose/Role Hierarchies • How do CPs “propagate” along purpose/role hierarchies? • Missing CP assignments • What’s the CP of an accessing entity, if it has no explicit or implicit assignments? • Multiple CP assignments • What’s the CP of an accessing entity, if it has several explicit and/or implicit assignments? • Conflicting CPs for the same role, or for roles that belong to the same hierarchy

More Related