Lions and tigers and handling user capabilities - Tiffany Conroy - Codemotion Milan 2014

LIONS AND TIGERS AND

HANDLING USER CAPABILITIES

HI, I’M TIFFANY@THEOPHANI

LIONS AND TIGERS ANDHANDLING USER

CAPABILITIES

(EXAMPLES)

ON A HUNT FORWAYS TO APPROACH

USER CAPABILITIES

PART ITHE UX OF USER CAPABILITIES

PART IIIMPLEMENTING USER CAPABILITIES

PART ITHE UX OF

USER CAPABILITIES

GOOD USER CAPABILITY UXHELPS PEOPLE TO

1. AVOID MISTAKES2. UNDERSTAND THEIR CAPABILITIES

3. EASILY MANAGE PERMISSIONS

GOOD USER CAPABILITY UXHELPS PEOPLE TO

1. AVOID MISTAKES

WHY ADD USERACCESS RESTRICTIONSTO A SYSTEM ANYWAY?

PEOPLE SHOULD NOT BE ABLE TO DO THINGS THAT THEY

ARE NOT ALLOWED DO

PEOPLE SHOULD NOT BE ABLE TO DO THINGS THAT THEY

ARE NOT ALLOWED DO

PEOPLE SHOULD NOT BE ABLE TO DO THINGS THAT THEY

DO NOT NEED TO DO

THIS IS KNOWN AS THEPRINCIPLE OF

LEAST PRIVILEGE

Following this principle limits the potential damageof any security breach, whether accidental or malicious.

GOOD USER CAPABILITY UXHELPS PEOPLE TO

2. UNDERSTAND THEIR CAPABILITIES

INTERACTION DESIGN ASKS

HOW DOES THE USER:affect change?

understand the change?understand what they can change?

INTERACTION DESIGN ASKS

HOW DOES THE USER:affect change?

understand the change?→ understand what they can change? ←

YOUR UI MUST COMMUNICATEWHAT THE PERSON CAN DO

YOUR UI MUST NOT COMMUNICATETHAT THE PERSON CAN DOSOMETHING THEY CAN’T

GOOD USER CAPABILITY UXHELPS PEOPLE TO3. EASILY MANAGE

PERMISSIONS

FIRST, SOME

DEFINITIONS

SUBJECT, OBJECT,OPERATION &

PERMISSION, CAPABILITY

SUBJECT: ACTIVE ENTITY,SUCH A USER OR A PROCESS.

OBJECT: THINGTHE SUBJECT ACTS UPON.

OPERATION: ACTIONATTEMPTED BY THE SUBJECT ON THE OBJECT.

PERMISSION: THE RIGHTTO PERFORM THE OPERATION.

CAPABILITY: ALLOWED OPERATIONTHE SUBJECT HAS PERMISSION

TO PERFORM ON AN OBJECT.

SUBJECT: PERSONOBJECT: THING

OPERATION: ACTIONPERMISSION: GIVES CAPABILITY

TO A PERSON TO PERFORM AN ACTION ON A THING

ACL , RBACACL: ACCESS CONTROL LIST

RBAC: ROLE-BASED ACCESS CONTROL

ACLACCESS CONTROL

LIST

ACCESS CONTROL LIST

THE UX OF MAINTAININGAN ACCESS CONTROL LIST

HOW DO YOU KNOWWHICH ACTIONS TO ALLOW

ON WHICH THINGS?

WHAT IF YOU NEEDED TO UPDATE SUCH A LIST?

GROSS

NOT GOOD UX

PERMISSIONGROUPS?

ROLE-BASED ACCESS CONTROL TO THE RESCUE!

RBACROLE-BASED

ACCESS CONTROL

ROLE: JOB FUNCTIONIN AN ORGANIZATION

ROLE: COLLECTION OFCAPABILITIES

PEOPLE CAN HAVEMORE THAN ONE ROLE

WHEN A ROLE IS CHANGED,PEOPLE’S CAPABILITIES CHANGE TOO

ROLE-BASED ACCESS CONTROLor

ACCESS CONTROL LISTS?

BAD UX LEADS TO

MISTAKES

MISTAKESCAN LEAD TO VIOLATIONS OF THE

PRINCIPLE OFLEAST PRIVILEGE

ROLE-BASED ACCESS CONTROLis better UX than

ACCESS CONTROL LISTS

RECAP

PART I

GOOD USER CAPABILITY UXHELPS PEOPLE TO

1. AVOID MISTAKES2. UNDERSTAND THEIR CAPABILITIES

3. EASILY MANAGE PERMISSIONS

1. AVOID MISTAKESBY FOLLOWING THE

PRINCIPLE OF LEAST PRIVILEGE

PEOPLE SHOULD BE ABLE TO2. UNDERSTAND THEIR

CAPABILITIESBECAUSE YOUR IU COMMUNICATES THEM

3. EASILY MANAGE PERMISSIONS

BY USING ROLE-BASED ACCESS CONTROL

PART IIIMPLEMENTING

USER CAPABILITIES

BUT FIRST, MY

ASSUMPTIONS

▸ Client-side rendered apps,▸ that use REST APIs to

load and save data asynchronously,▸ and the server can tell the client details

about the authenticated user.

(Though, same ideas can apply to server-side rendered views)

IMPLEMENTATION CONSTRAINTS:1. ONLY GRANT NECESSARY CAPABILITIES2. UI MUST COMMUNICATE CAPABILITIES

3. USE ROLE-BASED ACCESS CONTROL

0. THE SERVER-SIDE MUSTENFORCE THE RESTRICTIONS

THE SERVER-SIDE MUSTENFORCE THE RESTRICTIONS

← OR ELSE STUFF LIKE THIS IS POSSIBLE

THE SERVER-SIDE MUSTENFORCE THE RESTRICTIONS,

AND THE CLIENT-SIDE MUSTREFLECT THE RESTRICTIONS

// Don’t do this

if ( "Junior Warehouse Clerk" in user.roles || "Warehouse Clerk" in user.roles || "Warehouse Manager" in user.roles ) { // Show "View Orders" button ...}

// Do it like this!

if ( "view orders" in user.capabilities ) {

// Show "View Orders" button ...

}

$.ajax( url: "/_api/me/capabilities", success: function (response) { user.capabilities = response.capabilities }})

// Checking for one capability

if ( "view orders" in user.capabilities ) {

// Show "View Orders" button ...

}

// Checking for more than one capability

if ( "view orders" in user.capabilities || "edit orders" in user.capabilities || "manage customers" in user.capabilities ) { // Show drop down menu icon ...}

[ THIS KIND OF ]

CAPABILITY CHECKINGIS ADDITIVE

can ( user, ["view orders"] )// returns true if user can view orders

can ( user, ["action one", "action two", "action three"] ) // returns true if the user can do any of the actions

function can (user, requiredCapabilities) { return requiredCapabilities.some(function (capability) { return capability in user.capabilities })}

if ( can (user, ["do something"]) ) { // ...}

if ( can (user, ["do action", "do another action"]) ) { // ...}

WHAT ABOUT“LOGIC-LESS” TEMPLATES?

// in your view codemustache.render(template, { can: user.capabilities, // ...})

<!-- in your mustache template -->{{#can.viewOrders}} <a link=“/orders">View Orders</a>{{/can.viewOrders}}

<nav> {{#can.viewOrders}} <a link="/orders">View Orders</a> {{/can.viewOrders}} {{#can.createOrders}} <a link="/orders/new">Add Order</a> {{/can.createOrders}}</nav>

<!-- This doesn’t work -->{{#can.viewOrders}} {{#can.createOrders}} <nav> ... </nav> {{/can.createOrders}}{{/can.viewOrders}}

// Augment capabilities with view-specific ones

if ( can(user, ["view orders", "create orders"]) ) { user.capabilities.viewMenu = true;}

mustache.render(template, { can: user.capabilities, // ...})

{{#can.viewMenu}} <nav> ... </nav>{{/can.viewMenu}}

<!-- Handlebar template containing a “can” block helper -->{{#can "viewOrders editOrder"}} <nav> ... </nav>{{/can}}

// Define the block helper ...function canBlockHelper (requiredCapabilities, options) { // ... return hasSomeCapabilities ? options.fn(this) : ""}// ... and register it as “can”Handlebars.registerHelper("can", canBlockHelper);

{{#can "viewOrders editOrder"}} <nav> {{#can "viewOrders"}} <a link="/orders">View Orders</a> {{/can}} {{#can "createOrders"}} <a link="/orders/new">Add Order</a> {{/can}} </nav>{{/can}}

# Use the same kind of “can” per route server-side

get "/_api/orders" can ( user, "view orders" ) do # ... end end

post "/_api/orders" can ( user, "add orders" ) do # ... end end

IN CONCLUSION …

IMPLEMENTATION CONSTRAINTS:1. ONLY GRANT NECESSARY CAPABILITIES2. UI MUST COMMUNICATE CAPABILITIES

3. USE ROLE-BASED ACCESS CONTROL

CONSIDER WHEN IMPLEMENTING:1. ENFORCE IN BOTH SERVER AND CLIENTBUT MAKE THE SERVER THE AUTHORITY

2. CHECK AGAINST CAPABILITIES, NOT ROLES

THANK YOU!TIFFANY CONROY – @THEOPHANI