31 December 2020

POLITECNICO DI TORINORepository ISTITUZIONALE

Authorisation in Context: Incorporating Context-Sensitivity into an Access Control Framework / Shamal, Faily; John, Lyle;Ivan, Fléchais; Atzeni, Andrea; Cameroni, Cesare; Hans, Myrhaug; Ayse, Göker; Robert, Kleinfeld. - ELETTRONICO. -(2014), pp. 189-194. ((Intervento presentato al convegno HCI'14: 28th Int. BCS Human Computer Interaction Conference2014 tenutosi a Southport (UK) nel 9-12 September 2014.

Original

Authorisation in Context: Incorporating Context-Sensitivity into an Access Control Framework

Publisher:

PublishedDOI:10.14236/ewic/hci2014.21

Terms of use:openAccess

Publisher copyright

(Article begins on next page)

This article is made available under terms and conditions as specified in the corresponding bibliographic description inthe repository

Availability:This version is available at: 11583/2601758 since:

Authorisation in Context: IncorporatingContext-Sensitivity into an Access Control

Framework

Shamal FailyBournemouth University

sfaily@bournemouth.ac.uk

John Lyle, Ivan FlechaisUniversity of Oxford

firstname.lastname@cs.ox.ac.uk

Andrea Atzeni, Cesare CameroniPolitecnico di Torino

firstname.lastname@polito.it

Hans MyrhaugAmbieSense Ltd

hans@ambiesense.com

Ayse GokerAmbieSense Ltd / City University London

ayse@ambiesense.com

Robert KleinfeldFraunhofer FOKUS

robert.kleinfeld@fokus.fraunhofer.de

With sensitive information about ourselves now distributed across personal devices, people need to makeaccess control decisions for different contexts of use. However, despite advances in improving the usabilityof access control for both developers and users, we still lack insights about how the intentions behind policydecisions in different contexts of use are shaped. In this paper, we describe how context was incorporatedinto an access control framework using a study of how context influences access control decision making.We describe how the main recommendations arising from this study were used to build context into a policyeditor for this access control framework.

HCI-Security, Access Control, Policy, Affinity Diagram

1. INTRODUCTION

Personal information is no longer locked down inspecific locations, where access control can besuccinctly described. Instead, information about ourhabits or preferences is now dissipated across avariety of devices, such as mobile phones, cars,and smart TVs. Because our relationship with thesetechnologies is still inchoate, many unansweredquestions remain about how developers shouldbuild end-user access control management toolsfor these device federations, especially given thevariety of physical and social contexts in which thesecollections of devices are used.

Improving the usability of policy authoring tools forboth developers and users has been a popular lineof HCI-Security research in recent years. Althoughpast work has cast light on some of the challengesin using and developing policy management tools,reflecting on the pervasiveness of mobile andweb applications uncovers further challenges. Forexample, consider the scenario below:

Alice is on her way to meet Justin, an old schoolfriend. Alice’s directions to Justin’s house areconfusing; to avoid getting lost she requests Justin’sGPS location, and her in-car navigation computer to

picks the best route. Justin receives the permissionrequest and, seeing that Alice is running late,authorises Alice to view his location. A few dayslater, Alice is visiting friends in London and againuses a navigation app to find the best route to theirproposed meeting place. However, because Justin’slocation was the last she used, the application startsto route towards him instead. By coincidence, Justinis also in London, and Alice follows the seemingly-plausible directions. Alice arrives at her destinationand is shocked to find Justin walking out of a buildingthat, to Justin’s embarrassment, she recognisesas one of central London’s seedier establishments.Alice’s application, recognising that she has reachedher destination, then automatically checks her intoher new location via Foursquare.

This scenario highlights several of these aforemen-tioned challenges. First, the situations where suchtools might be used are as much about enablingfreedom of action as they are applying constraints.Many policy tools have been implicitly designedfor organisational settings where a certain degreeof compliance with organisational norms can beexpected. When people make personal use of ap-plications, the values and norms influencing policydecisions may be shaped around personal freedomrather than information security compliance. Second,

© The Authors. Published byBCS Learning and Development Ltd.Proceedings of HCI 2014, Southport, UK

189

Authorisation in Context: Incorporating Context-Sensitivity into an Access Control FrameworkFaily et al.

our access control decisions are influenced not onlyby the objects and different (human or machine) sub-jects, but also by the contexts within which objectsand subjects interoperate. People may make accesscontrol decisions for devices on the move when thecontext of enforcement is at home, and vice-versa.Third, presenting the ability to react to all variables ina context leads to complexity overload. Too many ortoo few options may lead to habituation, and thereis already evidence that such habituation leads tomalware being inadvertently installed on devices.Yet, at the same time, there are few examples of howthese challenges might be addressed. Designersneed insights about how to tackle the process ofinitially deriving a context sensitive policy, and howsuch policies might evolve as people’s understandingof their contexts of use develops.

These challenges suggest that designing policy toolsto meet the security and privacy expectations ofend-users, without compromising their freedom ofaction, is easier said than done. Consequently, itwould be useful to understand how people developthese expectations in realistic situations. By doingso, we can elicit concepts that influence this decisionmaking process, and help developers build tools thathelp policy authors make context-sensitive accesscontrol decisions wherever they are. To this end, thispaper describes how context was incorporated intoan access control framework. We briefly describerelated work in HCI-Security towards addressingthe problem this paper addresses, before describinghow three factors influencing the elicitation andcategorisation of context-sensitive security policieswere elicited. We conclude by illustrating theimplications of these factors for the design of policymanagement tools using a policy editor for thisaccess control framework.

2. RELATED WORK

(Zurko and Simon 1996)’s seminal work on user-centered security was, in part, motivated by the needfor usable least-privilege access control. Since thistime, the HCI-Security community has taken a keeninterest in closing what (Norman 1988) describesas the gulf of execution between the intentions ofusers, and the system’s means of implementingthem. Studies into enterprise policy managementtools have gone some way towards closing this gap.In particular, work by (Reeder et al. 2007) identifiedseveral general policy authoring challenges thatneed to be addressed by policy management tooldevelopers; these include enforcing consistent use ofterminology, making the concept of default rules andtheir rationale clearer, and facilitating the grouping ofobjects.

(Kelley et al. 2011) highlighted the difficulties peoplehave devising a priori categories of objects thatremain useful when making policy decisions. Earlierwork on evaluating privacy preference tools identifiedsimilar problems between a priori policy specificationand usage (Lederer et al. 2004). Because they needto understand the privacy implications of situateduse, Lederer et al. argue that users prefer to carryout actions with imperfect default settings, ratherthan semi-intuitively configuring data on an a prioribasis. The idea that people work off a general accesscontrol policy and vary this by different contexts wasalso identified by (Smetters and Good 2009).

Because much of this related work is framed fromthe perspective of using policy authoring tools, therehas been comparatively little work on how theintentions behind policy decisions are formulated,and how these might be influenced. To glean anunderstanding of these intentions, it is useful toobserve how people formulate and decide policyrelated actions using both scenarios and contextsspecific to their day-to-day lives. To understand whatthese concepts and factors might be then examininghow ordinary users respond to contrived, non-specific usage scenarios is not sufficient. Instead, weneed to examine how representative stakeholdersmake access control decisions based on contexts ofuse that are meaningful to them.

3. APPROACH

3.1. Contextual access control in webinos

webinos is a software infrastructure for running webapps across mobile, PC, home media, and in-car de-vices (Fuhrhop et al. 2012). Its software architectureincludes policy management components for facili-tating cross-device access control (Lyle et al. 2012).Because webinos policy management is based onthe XACML attribute-based access control model, itis theoretically possible to make fine-grained accesscontrol decisions based on environment attributes.Unfortunately, while the use cases upon which thesecomponents were based describe the flow of databetween end users and system components, theseare generic and framed in terms of whether or notusers can access device features via applicationsrunning on different devices, rather than where thesedevices might be located.

As part of the project, a collection of personas– behavioural specifications of archetypical users(Cooper et al. 2007) – were developed to providea voice for users and developers impacted bywebinos. While useful for envisaging perceptionsthese stakeholders might have about webinos, itwas unclear how their expectations about access

190

Authorisation in Context: Incorporating Context-Sensitivity into an Access Control FrameworkFaily et al.

control might change in line with subtle changes inphysical or social contexts within which webinos-enabled apps might be used. Without knowing theseexpectations, it would be difficult to formativelyevaluate tools for creating and managing context-sensitive access control policies. When it becameapparent that team members had difficulty evenenvisaging user interfaces for context-sensitivepolicy management, we decided to explore theimpact of the concept of context on webinos policyspecification and management.

3.2. Methodology

To understand how representative users wouldexperience access control decisions across multipledevices and contexts, we ran nine persona-basedparticipatory design workshops; each workshop wassituated around the characteristics and activities of aparticular persona. Following discussions within theproject team, we were interested in three particularrepresentative users. The first of these was a webapplication developer (Jimmy). webinos would notbe successful if developers did not adopt it, so theirstake in access control decisions would be critical.The second persona (Clara) represented younger,teenaged users, because we felt such users weremore likely to adopt new technology. The final personrepresented the parent of a young child (Helen); thispersona represented users that had made lifestylechoices making them sensitive to security & privacyconcerns. These personas are described in moredetail by (webinos Consortium 2011).

Workshop participants were recruited based on howclosely they matched the characteristics of the threedifferent personas. Participants were presented witha scenario meaningful to them, and asked to elicitand categorise types of data that would need tobe subject to access control. For example, Helenworkshops were structured around making decisionsabout the security and privacy implications of anetworked in-car entertainment system being usedby her young son while on a long car journey to seeher parents.

Each workshop involved 3-4 participants, and lastedapproximately 1.5 hours. The participatory designactivity revolved around an affinity diagrammingexercise. Affinity diagramming involves participantseliciting and organising data items, and consolidatingthese into groups that are meaningful to participants.As such, affinity diagramming allows participantsto understand and make sense of data subject toaccess control without constraining thinking aroundany specific tool or technology.

The affinity diagramming exercise followed aspecific structure. After introducing the scenario and

providing a brief overview of affinity diagramming,each session was divided into three stages.

In the first stage (object clustering), participantsspent 20 minutes eliciting data objects subjectto access control, writing these on post-it notes,and affixing the notes to a wall or whiteboard;these object post-it notes were then grouped undercategories the participants found useful for makingaccess control decisions.

In the second stage (subject clustering), participantswere required to elicit people (subjects) thatshould or should not have access to the objectselicited in the first stage. Red and green post-it notes designated parts of whiteboard wheredenied and allow objects are organised respectively.The participants then re-categorised the objectsdepending on what each subject should be allowedor denied access to; this stage took 30 minutes.

After a 10 minute break, participants spent 20minutes on the final stage (context clustering). Thisinvolved identifying different contexts associated withthe scenario and, for selected subjects, repeatingthe subject clustering stage based on each context.Following this stage, the participants walked throughthe affinity diagrams created, after which a shortdebrief session was held to find out how theparticipants found the exercise.

Audio and visual data was captured for eachworkshop. Following each workshop, the workshoporganiser prepared a short report summarising theevent’s outcome and the main themes emergingfrom the affinity diagrams and the associateddiscussions.

We devised this approach because team memberswere already familiar with affinity diagrammingfrom their previous work developing personas. Thisprevious work also helped them recruit suitableparticipants, based on the workshops they wereorganising; these workshops were held in the UK,Italy, and Germany. Because the experiments wereconcerned with the subjects’ behaviour rather thanthe affinity diagrams themselves, both the scenarioscould be explained and sessions run in the locallanguage, as only the session report needed tobe written in English. The report structure guidedparticipants towards the sort of observations thatneeded to be made, and subsequent telephoneconferences helped validate the research beingcarried out because it gave team members anopportunity to present and discuss their results.

191

Authorisation in Context: Incorporating Context-Sensitivity into an Access Control FrameworkFaily et al.

4. RESULTS

Once all the sessions had been completed, theworkshop reports and transcripts were subject toopen and axial coding (Corbin and Strauss 2008)by team members with experience in qualitativedata analysis. From this coding exercise, 14 refinedthematic concepts were identified. On investigatingthe relationships between these concepts and theirgrounding in the empirical data, we identified threemain factors that influenced the elicitation andcategorisation of context-sensitive access controlpolicies: shared working contexts, pre-existingbiases, and expectation based decision making.

4.1. Shared working contexts

Although not formally acknowledged by the partici-pants, each workshop appeared to elicit and cate-gorise data within the frame of a working context.The ability of participants to frame data was medi-ated by three factors.

The first of these were the nuances in the workingcontext; examples of these range from varying thetime-frame of a working context through to changingthe family relationship of subjects in a context.Exploring these shed new light on pre-existingobjects, but also led to considerable discussion,slowing down the rate of progress.

The second factor was general fatigue. Framing andre-framing objects and categories within a workingcontext was time-consuming. In some cases, arigorous exploration of objects and subjects inthe working context left participants so tired thatcontexts were specified around pre-existing subjectsor locations closely related to the working context.

The third factor was the use of supporting tools- in particular sketches and check-lists. Sketcheswere used in one workshop as a supplement tothe context clustering affinity diagramming to explainparticular subtleties of a context. Mental checklistsand matrices were in a number of workshops tocheck the relevance of concepts, or validate aconcept’s inclusion under a particular category.

Although primarily used for concept elicitation andcategorisation, framing was also useful for identifyingconcepts and categories forming the basis ofinnovation within the general domain. Examplesincluded the elicitation of commercialisation andregulatory concepts that might foster improvedsecurity and privacy.

4.2. Pre-existing biases

The ability of participants to frame conceptsand categories was influenced by pre-existing

biases. In some cases, biases led to restrictivethinking about concepts because of pre-existingdomain knowledge. This was most obvious in theJimmy workshops, which centred on specifyingpolicies for a training course website. Pre-existingknowledge about how the website was used,or assumptions about how hardware was setupappeared to unnecessarily dismiss objects asdisallowed to particular subjects and context. Pre-existing biases were most evident when consideringthe implicit working context during object andsubject clustering. Sometimes, these biases werere-enforced by participants when discussions weregrounded around a particular frame; these frameswere based on anecdotal experiences of theworking context or when prompted by the facilitatingworkshop organiser.

As well as restricting thinking, biases and groundingalso facilitated the elicitation of concepts whichmight otherwise have been missed. In almost allworkshops, grounded discussions around particularworking concepts led to the identification of conceptswhich were missed during the initial context-freeobject clustering stage.

4.3. Expectation-based decision making

The ability to frame concepts was also influenced byexpectations held about the behaviour of particularsubjects. Some of these were formed by pre-existing biases because participants felt they wereproxy users for subjects under discussion. Inothers, participants espoused opinions they believedsubjects might find important, irrespective of whetherthey found it important. For example, in one ofthe Clara workshops, participants proposed DigitalRights Management restrictions that they felt contentproviders would find useful. In some workshops,participants felt confident enough in their knowledgeof subject expectations that concepts would bemoved between allowed and denied sections of thewhite board or wall by category and, in some cases,categories would be elicited before concepts, andsubsequent concepts grouped by static, pre-existingcategories.

Expectations were important for envisaging theimpact of policy decisions but, in certain cases,this also led to scope creep when participantknowledge of subjects or the domain appearedto be deficient. One of the factors contributing toscope creep was generalisation about the problemdomain; this arose due to lack of knowledgeor only a superficial treatment of concepts. Theother contributing factor was generalisation dueto perceived lack of relevance. Examples of thisincluded collectively grouping “interface” or “service”technology because they seemed equally relevant

192

193

Authorisation in Context: Incorporating Context-Sensitivity into an Access Control FrameworkFaily et al.

It was assumed that the definition of context usedby the requestor and resource owner is shared.However, personas would name environmentsusing short phrases based on the workshop, e.g.Peter’s home. Not only would these environmentnames be different for the same context that twopersonas would share but, developers discoveredthe spaces have been implicitly disallowed in theimplementation. This was only identified when itwas observed that requests that should have beenallowed were denied.

5.2. Use supplemental tools for policy creationand management

Additional tools are needed not only for editing poli-cies, but also for creating supplemental information.The workshop results showed that techniques suchas sketches, matrices, and checklists were useful.Previous work in the HCI-Security literature has alsofound that, if supplemented with contextual infor-mation about policy rules, matrices improve speedand accuracy when viewing and changing policiesover traditional policy management tools (Reeder2008). Based on both the literature and the workshopresults, subject/object matrix controls for editing ac-cess control policies should support supplementalinformation to allow policy editors to reconstruct theframe used by policy developers when creating theadditional policy. This supplemental information mayinclude multi-dimension matrix cells such as (Reeder2008), or additional controls to allow the attachmentof image files or design rationale. With this in mind,interfaces for editing specific permissions were aug-mented to allow additional textual rationale to beappended to rules.

6. CONCLUSION

In this paper, we have presented three factors influ-encing the elicitation and categorisation of context-sensitive security and privacy policies. Rather thanviewing our study through the lens of a specific tool,and drawing from a random user sample to carry outa general policy authoring scenario, we have insteadused participatory workshops to understand the ex-periences associated with policy decisions. We havealso based our study around scenarios that werespecific to demographics of the participants engagedin these workshops. Based on these factors, wehave illustrated how context was built into a policyeditor to better understand the design implications ofcontextual access control.

REFERENCES

Cooper, A., R. Reimann, and D. Cronin (2007).About Face 3: The Essentials of Interaction

Design. John Wiley & Sons.

Corbin, J. M. and A. L. Strauss (2008). Basics ofqualitative research : techniques and proceduresfor developing grounded theory (3rd ed.). SagePublications.

Fuhrhop, C., J. Lyle, and S. Faily (2012). Thewebinos project. In Proceedings of the 21stinternational conference companion on WorldWide Web, pp. 259–262. ACM.

Kelley, P. G., R. Brewer, Y. Mayer, L. F. Cranor,and N. Sadeh (2011). An investigation intofacebook friend grouping. In Proceedings ofthe 13th IFIP TC 13 international conferenceon Human-computer interaction, pp. 216–233.Springer-Verlag.

Lederer, S., I. Hong, K. Dey, and A. Landay (2004,November). Personal privacy through understand-ing and action: five pitfalls for designers. PersonalUbiquitous Comput. 8, 440–454.

Lyle, J., S. Monteleone, S. Faily, D. Patti, andF. Ricciato (2012). Cross-plaform access controlfor mobile web applications. In Policies forDistributed Systems and Networks, 2012 IEEEInternational Symposium on, pp. 37–44.

Norman, D. A. (1988). The design of everydaythings. Basic Books.

Parnas, D. L. and P. C. Clements (1986). A rationaldesign process: How and why to fake it. IEEETransactions on Software Engineering 12(2), 251–257.

Reeder, R. W. (2008). Expandable Grids: A userinterface visualization technique and a policysemantics to support fast, accurate security andprivacy policy authoring. Ph. D. thesis, CarnegieMellon University.

Reeder, R. W., C.-M. Karat, J. Karat, and C. Brodie(2007). Usability challenges in security and pri-vacy policy-authoring interfaces. In Proceedingsof the 11th IFIP TC 13 international conferenceon Human-computer interaction, pp. 141–155.Springer-Verlag.

Smetters, D. K. and N. Good (2009). How usersuse access control. In Proceedings of the5th Symposium on Usable Privacy and Security,SOUPS ’09, pp. 15:1–15:12. ACM.

webinos Consortium (2011, February). User expec-tations on privacy and security. Downloadablefrom http://webinos.org.

Zurko, M. E. and R. T. Simon (1996). User-centeredsecurity. In Proceedings of the 1996 New SecurityParadigms Workshop, pp. 27–33. ACM.

194