Many web applications must restrict access to some features for some users for various reasons. For example: Only premium users get access to extra features. Only supervisors can edit online store prices. If your web app is a dynamically rendered JS, your frontend code needs to know what restrictions your users have in order to render the UI. How can you centralize the logic? Where in the application should you check for and enforce restrictions? Join me on a safari through the approaches, patterns, and techniques for handling the logic around user capabilities in client-side apps.

1. LIONS AND TIGERS AND
HANDLING USER
CAPABILITIES

3. HI, I’M TIFFANY
@THEOPHANI

4. LIONS AND TIGERS AND
HANDLING USER
CAPABILITIES

5. (EXAMPLES)

7. ON A HUNT FOR
WAYS TO APPROACH
USER CAPABILITIES

8. PART I
THE UX OF USER CAPABILITIES
PART II
IMPLEMENTING USER CAPABILITIES

9. PART I
THE UX OF
USER CAPABILITIES

10. GOOD USER CAPABILITY UX
HELPS PEOPLE TO
1. AVOID MISTAKES
2. UNDERSTAND THEIR CAPABILITIES
3. EASILY MANAGE PERMISSIONS

11. GOOD USER CAPABILITY UX
HELPS PEOPLE TO
1. AVOID MISTAKES

12. WHY ADD USER
ACCESS RESTRICTIONS
TO A SYSTEM ANYWAY?

13. PEOPLE SHOULD NOT BE ABLE
TO DO THINGS THAT THEY
ARE NOT ALLOWED DO

14. PEOPLE SHOULD NOT BE ABLE
TO DO THINGS THAT THEY
ARE NOT ALLOWED DO

15. PEOPLE SHOULD NOT BE ABLE
TO DO THINGS THAT THEY
DO NOT NEED TO DO

16. THIS IS KNOWN AS THE
PRINCIPLE OF
LEAST PRIVILEGE

17. Following this principle limits the potential damage
of any security breach, whether accidental or malicious.

18. GOOD USER CAPABILITY UX
HELPS PEOPLE TO
2. UNDERSTAND THEIR
CAPABILITIES

19. INTERACTION DESIGN ASKS
HOW DOES THE USER:
affect change?
understand the change?
understand what they can change?

20. INTERACTION DESIGN ASKS
HOW DOES THE USER:
affect change?
understand the change?
→ understand what they can change? ←

21. YOUR UI MUST COMMUNICATE
WHAT THE PERSON CAN DO

22. YOUR UI MUST NOT COMMUNICATE
THAT THE PERSON CAN DO
SOMETHING THEY CAN’T

23. GOOD USER CAPABILITY UX
HELPS PEOPLE TO
3. EASILY MANAGE
PERMISSIONS

24. FIRST, SOME
DEFINITIONS

25. SUBJECT, OBJECT,
OPERATION &
PERMISSION, CAPABILITY

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

27. OBJECT: THING
THE SUBJECT ACTS UPON.

28. OPERATION: ACTION
ATTEMPTED BY THE SUBJECT ON THE OBJECT.

29. PERMISSION: THE RIGHT
TO PERFORM THE OPERATION.

30. CAPABILITY: ALLOWED OPERATION
THE SUBJECT HAS PERMISSION
TO PERFORM ON AN OBJECT.

31. SUBJECT: PERSON
OBJECT: THING
OPERATION: ACTION
PERMISSION: GIVES CAPABILITY
TO A PERSON TO PERFORM AN ACTION ON A THING

32. ACL , RBAC
ACL: ACCESS CONTROL LIST
RBAC: ROLE-BASED ACCESS CONTROL

33. ACL
ACCESS CONTROL
LIST

34. ACCESS CONTROL LIST

35. THE UX OF MAINTAINING
AN ACCESS CONTROL LIST

37. HOW DO YOU KNOW
WHICH ACTIONS TO ALLOW
ON WHICH THINGS?

38. WHAT IF YOU NEEDED TO
UPDATE SUCH A LIST?

39. GROSS

40. NOT GOOD UX

41. PERMISSION
GROUPS?

42. ROLE-BASED ACCESS
CONTROL TO THE RESCUE!

43. RBAC
ROLE-BASED
ACCESS CONTROL

44. ROLE: JOB FUNCTION
IN AN ORGANIZATION

45. ROLE: COLLECTION OF
CAPABILITIES

46. PEOPLE CAN HAVE
MORE THAN ONE ROLE

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

48. ROLE-BASED ACCESS CONTROL
or
ACCESS CONTROL LISTS?

49. BAD UX LEADS TO
MISTAKES

50. MISTAKES
CAN LEAD TO VIOLATIONS OF THE
PRINCIPLE OF
LEAST PRIVILEGE

51. ROLE-BASED ACCESS CONTROL
is better UX than
ACCESS CONTROL LISTS

52. RECAP
PART I

53. GOOD USER CAPABILITY UX
HELPS PEOPLE TO
1. AVOID MISTAKES
2. UNDERSTAND THEIR CAPABILITIES
3. EASILY MANAGE PERMISSIONS

54. 1. AVOID MISTAKES
BY FOLLOWING THE
PRINCIPLE OF LEAST PRIVILEGE

55. PEOPLE SHOULD BE ABLE TO
2. UNDERSTAND THEIR
CAPABILITIES
BECAUSE YOUR IU COMMUNICATES THEM

56. 3. EASILY MANAGE
PERMISSIONS
BY USING ROLE-BASED ACCESS CONTROL

57. PART II
IMPLEMENTING
USER CAPABILITIES

58. BUT FIRST, MY
ASSUMPTIONS

59. ▸ 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)

60. IMPLEMENTATION CONSTRAINTS:
1. ONLY GRANT NECESSARY CAPABILITIES
2. UI MUST COMMUNICATE CAPABILITIES
3. USE ROLE-BASED ACCESS CONTROL

61. 0. THE SERVER-SIDE MUST
ENFORCE THE RESTRICTIONS

62. THE SERVER-SIDE MUST
ENFORCE THE RESTRICTIONS
← OR ELSE STUFF LIKE THIS IS POSSIBLE

63. THE SERVER-SIDE MUST
ENFORCE THE RESTRICTIONS,
AND THE CLIENT-SIDE MUST
REFLECT THE RESTRICTIONS

64. // 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 ...
}

65. // Do it like this!
if ( "view orders" in user.capabilities ) {
// Show "View Orders" button ...
}

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

67. // Checking for one capability
if ( "view orders" in user.capabilities ) {
// Show "View Orders" button ...
}

69. // 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 ...
}

70. [ THIS KIND OF ]
CAPABILITY CHECKING
IS ADDITIVE

71. 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

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

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

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

75. WHAT ABOUT
“LOGIC-LESS” TEMPLATES?

76. // in your view code
mustache.render(template, {
can: user.capabilities,
// ...
})
<!-- in your mustache template -->
{{#can.viewOrders}}
<a link=“/orders">View Orders</a>
{{/can.viewOrders}}

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

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

79. // Augment capabilities with view-specific ones
if ( can(user, ["view orders", "create orders"]) ) {
user.capabilities.viewMenu = true;
}
mustache.render(template, {
can: user.capabilities,
// ...
})

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

81. <!-- 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);

82. {{#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}}

83. # 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

84. IN CONCLUSION …

85. IMPLEMENTATION CONSTRAINTS:
1. ONLY GRANT NECESSARY CAPABILITIES
2. UI MUST COMMUNICATE CAPABILITIES
3. USE ROLE-BASED ACCESS CONTROL

86. CONSIDER WHEN IMPLEMENTING:
1. ENFORCE IN BOTH SERVER AND CLIENT
BUT MAKE THE SERVER THE AUTHORITY
2. CHECK AGAINST CAPABILITIES, NOT ROLES

87. THANK YOU! TIFFANY CONROY – @THEOPHANI