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
– Describe the interrelationship/interfaces between the
various components of the system
• Assign implementation responsibilities
• Discuss challenges/issues
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
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
General Idea: Information Management
• Three types of information necessary:
– Annotated dataset(s)
– Authentication information (users)
– Information on roles, purposes and the associated
concrete policies
Main Components
administrator interface
•User credentials for authentication
user interface
- authentication
- queries
- updates
Sparql to SQL
Translation Module
•
•
•
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
•Purpose and role hierarchy
•Assignment of concrete policies to accessing entities
CPRP
Module
CPRP DB
Annotation
Module
AAC API
•
CPRP API
PACEM API
AUTH API
- authentication
- queries
- updates
- manage datasets, annotations
- manage roles, users, purposes
- manage concrete policies (CP)
- assign CPs to accessing entities
Evaluation
Module
Update
Module
s
&a
p
o
label
type Person l1 ⊙l2
Student type class l2 ⊙l3
DB
•MonetDB
•Abstract access
control expressions
(quadruples)
Authentication (user & administrator)
administrator interface
•User credentials for authentication
user interface
AUTH API
- authentication
- queries
- updates
- manage datasets, annotations
- manage roles, users, purposes
- manage CPs
- assign CPs to accessing entities
- authentication
- queries
- updates
login, password
success/fail
AUTH DB
success/fail
login,
password
CPRP API
PACEM API
Sparql to SQL
Translation Module
AUTH
Module
•Purpose and role hierarchy
•Assignment of concrete policies to accessing entities
CPRP
Module
CPRP DB
Annotation
Module
AAC API
Evaluation
Module
Update
Module
s
&a
p
o
label
type Person l1 ⊙l2
Student type class l2 ⊙l3
DB
•MonetDB
•Abstract access
control expressions
(quadruples)
Querying (user) - assuming authentication is
successful
administrator interface
•User credentials for authentication
user interface
- authentication
- queries
- updates
user request
(accessing entity,
Sparql query)
result
(triples)
accessing entity
Sparql
Sparql to SQL
Translation Module
concrete policy
CPRP API
PACEM API
AUTH API
- authentication
- queries
- updates
- manage datasets, annotations
- manage roles, users, purposes
- manage CPs
- assign CPs to accessing entities
AUTH
Module
AUTH DB
•Purpose and role hierarchy
•Assignment of concrete policies to accessing entities
CPRP
Module
CPRP DB
result (triples)
The administrator can
see the abstract labels (no use
of concrete policy), and can also
query the datasets as a simple user
AAC API
SQL,
concrete policy
Annotation
Module
Evaluation
Module
Update
Module
s
&a
p
o
label
type Person l1 ⊙l2
Student type class l2 ⊙l3
DB
•MonetDB
•Abstract access
control expressions
(quadruples)
Updating Data (user) - assuming authentication is
successful
administrator interface
•User credentials for authentication
user interface
- authentication
- queries
- updates
user request
(accessing entity,
update)
Sparql
update
Sparql to SQL
Translation Module
AUTH
Module
AUTH DB
success/fail
accessing entity
concrete policy
CPRP API
PACEM API
AUTH API
- authentication
- queries
- updates
- manage datasets, annotations
- manage roles, users, purposes
- manage CPs
- assign CPs to accessing entities
•Purpose and role hierarchy
•Assignment of concrete policies to accessing entities
CPRP
Module
CPRP DB
success/fail
The administrator can
see the abstract labels (no use
of concrete policy), and can also
update the datasets as a simple user
AAC API
SQL update,
concrete policy
Annotation
Module
Evaluation
Module
Update
Module
s
&a
p
o
label
type Person l1 ⊙l2
Student type class l2 ⊙l3
DB
•MonetDB
•Abstract access
control expressions
(quadruples)
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)
Other Tasks
•
•
•
•
Register new user
Change login name/password
Remove user
…
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)
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