OPERATION: ACTION
ATTEMPTED BY THE SUBJECT ON THE OBJECT.
Slide 29
Slide 29 text
PERMISSION: THE RIGHT
TO PERFORM THE OPERATION.
Slide 30
Slide 30 text
CAPABILITY: ALLOWED OPERATION
THE SUBJECT HAS PERMISSION
TO PERFORM ON AN OBJECT.
Slide 31
Slide 31 text
SUBJECT: PERSON
OBJECT: THING
OPERATION: ACTION
PERMISSION: GIVES CAPABILITY
TO A PERSON TO PERFORM AN ACTION ON A THING
Slide 32
Slide 32 text
ACL , RBAC
ACL: ACCESS CONTROL LIST
RBAC: ROLE-BASED ACCESS CONTROL
Slide 33
Slide 33 text
ACL
ACCESS CONTROL
LIST
Slide 34
Slide 34 text
ACCESS CONTROL LIST
Slide 35
Slide 35 text
THE UX OF MAINTAINING
AN ACCESS CONTROL LIST
Slide 36
Slide 36 text
No content
Slide 37
Slide 37 text
HOW DO YOU KNOW
WHICH ACTIONS TO ALLOW
ON WHICH THINGS?
Slide 38
Slide 38 text
WHAT IF YOU NEEDED TO
UPDATE SUCH A LIST?
Slide 39
Slide 39 text
GROSS
Slide 40
Slide 40 text
NOT GOOD UX
Slide 41
Slide 41 text
PERMISSION
GROUPS?
Slide 42
Slide 42 text
ROLE-BASED ACCESS
CONTROL TO THE RESCUE!
Slide 43
Slide 43 text
RBAC
ROLE-BASED
ACCESS CONTROL
Slide 44
Slide 44 text
ROLE: JOB FUNCTION
IN AN ORGANIZATION
Slide 45
Slide 45 text
ROLE: COLLECTION OF
CAPABILITIES
Slide 46
Slide 46 text
PEOPLE CAN HAVE
MORE THAN ONE ROLE
Slide 47
Slide 47 text
WHEN A ROLE IS CHANGED,
PEOPLE’S CAPABILITIES CHANGE TOO
Slide 48
Slide 48 text
ROLE-BASED ACCESS CONTROL
or
ACCESS CONTROL LISTS?
Slide 49
Slide 49 text
BAD UX LEADS TO
MISTAKES
Slide 50
Slide 50 text
MISTAKES
CAN LEAD TO VIOLATIONS OF THE
PRINCIPLE OF
LEAST PRIVILEGE
Slide 51
Slide 51 text
ROLE-BASED ACCESS CONTROL
is better UX than
ACCESS CONTROL LISTS
Slide 52
Slide 52 text
RECAP
PART I
Slide 53
Slide 53 text
GOOD USER CAPABILITY UX
HELPS PEOPLE TO
1. AVOID MISTAKES
2. UNDERSTAND THEIR CAPABILITIES
3. EASILY MANAGE PERMISSIONS
Slide 54
Slide 54 text
1. AVOID MISTAKES
BY FOLLOWING THE
PRINCIPLE OF LEAST PRIVILEGE
Slide 55
Slide 55 text
PEOPLE SHOULD BE ABLE TO
2. UNDERSTAND THEIR
CAPABILITIES
BECAUSE YOUR IU COMMUNICATES THEM
Slide 56
Slide 56 text
3. EASILY MANAGE
PERMISSIONS
BY USING ROLE-BASED ACCESS CONTROL
Slide 57
Slide 57 text
PART II
IMPLEMENTING
USER CAPABILITIES
Slide 58
Slide 58 text
BUT FIRST, MY
ASSUMPTIONS
Slide 59
Slide 59 text
▸ 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)
Slide 60
Slide 60 text
IMPLEMENTATION CONSTRAINTS:
1. ONLY GRANT NECESSARY CAPABILITIES
2. UI MUST COMMUNICATE CAPABILITIES
3. USE ROLE-BASED ACCESS CONTROL
Slide 61
Slide 61 text
0. THE SERVER-SIDE MUST
ENFORCE THE RESTRICTIONS
Slide 62
Slide 62 text
THE SERVER-SIDE MUST
ENFORCE THE RESTRICTIONS
← OR ELSE STUFF LIKE THIS IS POSSIBLE
Slide 63
Slide 63 text
THE SERVER-SIDE MUST
ENFORCE THE RESTRICTIONS,
AND THE CLIENT-SIDE MUST
REFLECT THE RESTRICTIONS
Slide 64
Slide 64 text
// 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 ...
}
Slide 65
Slide 65 text
// Do it like this!
if ( "view orders" in user.capabilities ) {
// Show "View Orders" button ...
}
// Checking for one capability
if ( "view orders" in user.capabilities ) {
// Show "View Orders" button ...
}
Slide 68
Slide 68 text
No content
Slide 69
Slide 69 text
// 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 ...
}
Slide 70
Slide 70 text
[ THIS KIND OF ]
CAPABILITY CHECKING
IS ADDITIVE
Slide 71
Slide 71 text
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
Slide 72
Slide 72 text
function can (user, requiredCapabilities) {
return requiredCapabilities.some(function (capability) {
return capability in user.capabilities
})
}
Slide 73
Slide 73 text
if ( can (user, ["do something"]) ) {
// ...
}
Slide 74
Slide 74 text
if ( can (user, ["do action", "do another action"]) ) {
// ...
}
Slide 75
Slide 75 text
WHAT ABOUT
“LOGIC-LESS” TEMPLATES?
Slide 76
Slide 76 text
// in your view code
mustache.render(template, {
can: user.capabilities,
// ...
})
{{#can.viewOrders}}
View Orders
{{/can.viewOrders}}
Slide 77
Slide 77 text
{{#can.viewOrders}}
View Orders
{{/can.viewOrders}}
{{#can.createOrders}}
Add Order
{{/can.createOrders}}
# 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
Slide 84
Slide 84 text
IN CONCLUSION …
Slide 85
Slide 85 text
IMPLEMENTATION CONSTRAINTS:
1. ONLY GRANT NECESSARY CAPABILITIES
2. UI MUST COMMUNICATE CAPABILITIES
3. USE ROLE-BASED ACCESS CONTROL
Slide 86
Slide 86 text
CONSIDER WHEN IMPLEMENTING:
1. ENFORCE IN BOTH SERVER AND CLIENT
BUT MAKE THE SERVER THE AUTHORITY
2. CHECK AGAINST CAPABILITIES, NOT ROLES