Designing the user experience for permissions

Theory is great, however at some point the user complexity will expand and the need to provide your users with the capability to set their own permissions will become necessary.

Background

For Authress Administrators, the Authress Management Portal solves that problem, but not for your users. Instead you might be thinking about having a UI that looks something like this:

Or alternatively, something that looks like this:

Irrespective of the UI or the user experience you are planning on providing, these UIs will map to Authress Access Records. Since access records exist specific to enable granting access.

These permissions should be presented as Roles within Authress, and when the users change the list of permissions specified, roles and the associated resources should be added or removed from the appropriate access record.

Solution

One common solution is to create an access record for each user following the recommendations from the Access Record Design. From there, on a permission being added or removed or a resource being added or removed, apply the change to the correct user based access record.

For this scenario, you will want to create two sets of roles:

• One set will be your Admin, User, Developer roles. These roles will be assigned to users programmatically and through the Authress Management Portal. Users often won't use these roles.
• The other set of roles will be a 1:1 mapping of what is displayed in the UI.

In some cases, your UI might contain high level roles like Admin, User, Editor. However, if your UI contains more granular roles such as Project Reader, Project Viewer, Chat Reader, etc... Then these roles will likely directly map to user permissions. Make sure that all users still are assigned the Admin or User based role programmatically, so that you can add default permissions on top.

Here we can imagine the Project Viewer role has one permission projects:read. Going forward you might decide to introduce a new scoped permission project:comments:read, and want this permission to be distinct for your users. That is there might be some people that should get projects:read without the new permission. This case, you would:

1. Add the new permission to the existing Project Viewer role
2. Create 2 new Roles Project Viewer 2 and Project Commenter, each with just one permission
3. Update your UI to allow users to select either of these tow new roles
4. Update your UI backing code, to convert automatically from the old Project Viewer role to the new new roles in the UI.

info

It's important to remember that access records and groups, are finite in size, and so when selecting a non-user based access record cardinality, to make sure that the total number of users, resources, and roles that will be in that record will be below the access record capacity limit.

More information on the interaction pattern using the Authress API is available in the usage guide on Splitting Permissions and Resources.