Expressions of Expertness
The Virtuous Circle of Natural
Language for Access Control Policy Specification
Philip Inglesant
M Angela Sasse - University College London
David Chadwick
Lei Lei Shi - University of Kent, Canterbury, UK
Symposium On Usable Privacy and Security
Carnegie Mellon University 25 July 2008
What do we mean by “Expressions of
Expertness”?
Need: Non-security specialists to express
access control in formal terms
•Grid
They
are experts
concerning
theircomputing
own resources:
computing
– similar
to cluster
–
they know
who should
betogether
given access to what to
linked
computers
working
do which action
Systems can be distributed geographically
But struggle to express this in formal terms which
the administrative
computer can interpret
Across
domains
• Only the user knows what they “really want”
SOUPS 2008
Page 2 of 14
Access control and authorization
• “Access control is the ability to
permit or deny the use of a particular resource
by a particular entity” - Wikipedia
• AuthZ is more important than AuthN but has been
studied less
• Authorization is inherently complex but, for
usability, “complexity is the enemy of success” Karat Brodie & Karat 2005
SOUPS 2008
Page 3 of 14
The Context of this research: PERMIS
PERMIS is an integrated AuthZ infrastructure
Open source
Works with Grid, Apache Web servers, .Net, and others
• PERMIS makes access control decisions …
• … as defined by your access control policies
• … written in XML
SOUPS 2008
Page 4 of 14
Role Based Access Control
RBAC
permissions are always
Policy
positive,
although there can be
specification
Actions
RBAC permissions are
always positive
constraints.
Permissions
not
Delegated
granted are implicitly denied –
Permissions
to do actions
on
resources
are
assignment
“Deny all, except …”
assigned to roles,
Users
Roles not users
Permissions
Assignment of Roles to Users by Administrators
User
Permission
in (remote)
Domains
assignment
assignment
PERMIS allows you to delegate
Resources
→ RBAC model presents conceptual
difficulties
the ability to assign roles to
Role/Attribute Administrators
SOUPS 2008
Page 5 of 14
Overcoming conceptual difficulties: existing
approaches
• PERMIS Editor: GUI-based approach
– Conceptual Design - metaphors to match users’ mental
models
– Prominent warning: “this is DENY ALL, EXCEPT”
• Controlled natural language approaches
– Fundamentally – reduce distance between user’s
intentions  their expression
– SPARCLE – for privacy and other policies
– Virtuous Circle – input and output of AuthZ policies
SOUPS 2008
Page 6 of 14
Our approach:
Controlled natural
language based
on an ontology
Controlled natural
language may be more
“natural” and less
ambiguous than full
natural language
Requests and
responses between
user and computer
The user does
not have to Permissions,
know about actions,
resources, roles,
the
& other entities,
computer’s and relations
world
between them
SOUPS 2008
User’s world
Computer’s
world
X.509_PMI_RBAC_
Policy
OID=".091007.1"
> ....
Page 7 of 14
Carrying out our approach
• Phase 1: Interviews and focus groups
– 45+ Resource owners in Grid computing
– How do they think about their AuthZ requirements?
– How do they express them?
• Phase 2: Design of ontology and controlled
language processing
– From findings of Phase 1
– Keep it open but above all easy
– Basic building blocks – users construct policies
according to their needs
SOUPS 2008
Page 8 of 14
Example
Print is an action.
Printers are a type of resource.
Printer has print.
HP Laserjet 1 is a printer.
Manager and staff are roles.
Manager is superior to staff.
Staff can print on HP Laserjet 1.
Manager can print on all printers.
David and John are administrators.
David can assign manager to all users.
John can assign staff to users from
DepartmentCS.
SOUPS 2008
read is an action.
write is an action.
records are a type of resource.
records has read and write.
name, dobs, addresses,
postcodes are a resource.
analyst and clerk are roles.
analysts can read from dob
and postcode.
…
Page 9 of 14
Evaluation: can users express their real
world intentions?
• Lab-based observations: 17 target users
• Neutral or application-specific scenarios
• Recorded and analysed for time and number of
tries, classes of problem and comments
→ How usable is the basic interface? Are users
daunted by the blank screen?
→ Can users understand the building blocks and
use them to construct workable policies?
SOUPS 2008
Page 10 of 14
Overall results
• Not daunted by controlled natural language
interface
• Time and tries are higher than we would like:
– mean 24:27 minutes in 4.47 tries
• Largely overcomes conceptual difficulties
– No tendency to “deny” access to resources
But:
• Problems with features of controlled natural
language
• Difficulties constructing from the “building blocks”
SOUPS 2008
Page 11 of 14
The underlying mechanism makes itself felt
• Not quite natural language
– Having to declare elements
– Prepositions after verbs
• Using the building blocks
Clerks,
Owners
and
are roles.
– classes
andainstances
Address
is
typeAnalysts
of resource.
… instead
of
Name,
DoB, Address
and Postcode are
→
Underlying
not match the users’
Field
is a model
type does
of resource.
resources.
expectation
Address
is a field.
Clerks
can
write
totoare
Name,
DoB,can
Address
and
→ What
doPrinters
they
need
know?
How
we
a type
of
resource.
from
overcome the problems?
Postcode.
HP Laserjet 1 is a printer.
Owners can read all fields.
SOUPS 2008
Page 12 of 14
What do they need to know? How can they
know it?
• More informative timely feedback
– Line by line parsing
– Don’t silently fix problems – only the user knows what
they “really want”
– Drop-down boxes to disambiguate
• 2-way street between GUI and controlled
language
– An integrated interface
SOUPS 2008
Page 13 of 14
Review and conclusions
• Need: expression of formal AuthZ by non-experts
• Question: Is controlled natural language is more
“natural” than GUI?
• Design and evaluation of controlled language
• Can users express access control needs?
– Overall: well understood and usable, but – Underlying mechanisms make themselves felt
• Meeting the needs of the user in their own terms
– Feedback
– Integrated interface
SOUPS 2008
Page 14 of 14
p.inglesant@cs.ucl.ac.uk
http://www.cs.ucl.ac.uk/staff/P.Inglesant/
Human Centred Systems Group
http://hornbeam.cs.ucl.ac.uk/hcs/
Information Systems Security Group
http://www.cs.kent.ac.uk/research/groups/iss/
SOUPS 2008
SPARCLE
PERMIS
Privacy policies (although
other types envisioned)
Protects data items in an
organisation
Authorization policies by
resource owners
Protects any collection of
resources, actions and roles
Supports a generic privacy
control
Supports PERMIS with
delegation of authorities
Bespoke privacy model
Role Based Access Control
Based on predefined User
Categories, Actions, etc
Based on formal OWL
ontology
SOUPS 2008
Users cannot see the whole of the Database; what they can see depends on
their roles:
Clerks in Dept A can
add and change date of
birth, name, address
and postcode
Process
owners
cannot
change any
data but can
read it all
Name
Date of Birth
Address
Postcode
Department A
Database
Department B
SOUPS 2008
Analysts
can see
only
DoB and
Postcode
When Clerks
and Process
owners join
Department A
…
… John
assigns their
roles to them
Department A
Department B
When Analysts join
Department B,
Anne assigns their
roles to them
SOUPS 2008