Assigning roles and tailoring permissions

When developing an app, we naturally spend a lot of time thinking about, designing, and implementing the features we want users to see. But we don't spend enough time considering what someone shouldn't see. Often, these considerations are thrown together in a confusing matrix of checkboxes and radio buttons.

You've logged into a SaaS application before; you know what I'm talking about. Your admin has to give you permission to open a directory; or, you need to make sure everyone on your team has the right access level to comment on the document. Finding the right permissions, or keeping them up to date, is a challenge unto itself.

My background in API development (both the REST and GraphQL flavors) has given me a sort of warped view on how organization memberships and permissions should work. In an API, permissions are used to filter every action a user might take. No request is accepted and no response is given unless the client has been granted a specific set of permissions. That's because one bad database JOIN and someone's private records could be mistakenly included in a public feed; one missing permission check could lead to an unauthorized back door.

But when it comes to the UI, too often, the "solution" for these potential security lapses is one of two choices. Either the authorization system is designed to be an all-encompassing blob of Read/Write/Admin permissions, or it's diced up into hundreds of radio buttons granting varying levels of access to each and every part of an application. Both of these systems suck for users, who don't have the autonomy to understand why they can't perform an action, and for administrators, who must manage everyone's individual needs.

Leave a Comment