Access Control System (Postman 7.0)

Illustration by Shaivya Saraswat

The Problem

Postman had just launched an Enterprise plan and some of our bigger clients were immediately interested. We asked them what features were they most interested in. In all these discussions, there was a common pattern. All of these bigger companies wanted more control over their data and team members. They were all saying “I want only person A to be able to do X, not person B or C”.

When we looked at ways to go about building these access controls, we realised that we were not in a shape to be able to do this quickly. Our existing logic for access control was spread across our 30 micro-services and all user facing products. For every tiny control that we wanted to build, we would need to make the change in all the different parts of the product.

How we approached the problem

We decided that we would abstract out all this logic into a simple service. The design of the access control system however was left up to the design team since we had a deep understanding both of the product’s architecture as well as user expectations, both of which were critical for doing a good job. I was to lead the designing with technical help from Ankit (CTO) and Shamasis (VP Engineering). This was a unique challenge for me as my usual toolset would not help me much here. In fact, interface design would be a rather small part of the job.

From the product design side, Anudeep (my fellow Product Designer) was to help with some of the interfaces that he was already working on, and Brandon who had recently joined our team as a UX writer was to work together with me on all the product copy as well as coordinate with marketing and technical writing teams.

We defined the desired outcome. With the implementation of this system, all we wanted was to achieve parity with the current system. But the new implementation would also give us the flexibility of defining new roles as we see fit, without actually needing to write code. We also wanted to make it so configurable, so that user teams themselves could manage this.

The Plan

The plan of action was broken broadly into three distinct steps

  1. Research — Into access control models
  2. Product Architecture design — Mapping the existing product in terms of the new system
  3. Interface design — Designing general rules for the interface behaviour
  4. Migration — Figure out a way for current users to migrate smoothly onto the new system

1. Research

We did some background reading into theoretical models for access control. This helped us understand the options we had. We did whiteboard discussions with engineering about how some of these models would actually work in the context of out system and weighted pros and cons for each. While the engineering team was comparing robustness and ease of implementation, I was looking at what user experience would we be able to provide.

After some deliberation, we narrowed down our focus to two options, Attribute Based Access Control (ABAC) and Role Based Access Control (RBAC). In ABAC, the access is provided based on policies defined on the user, the resource or the environment. This provides a lot of granularity because you can define policies as you see fit. RBAC on the other hand relies only on the role assigned to a user. This has some downsides, for example the object’s properties are not taken in account while providing access, but the huge upside was that it is the most user friendly out of all the models we looked at. We decided that we’d go with RBAC with a limited use of policies if needed.

2. Product Architecture design

I started by doing an inventory of the whole product. This involved looking at what types of resources exist our ecosystem, what different types of actions can a user perform on these resources and all the different contexts under which these actions can be performed.

The second exercise that I did was to come up with a list of roles, that could act as a base to build upon. For this, I looked at how the current product behaved, as we sought to emulate this behaviour. Whenever the behaviour was not consistent, I took small decisions to reach consistency.

In the end, all I did was to surface the information that was buried deep inside uncountable lines of code so we could start having a common understanding of the product.

Product Architecture for Access Control

A secondary outcome of this exercise was that it deepened my understanding and appreciation for the product.

3. Interface design

The interface needed to reflect the state of the system. Instead of designing for specific contexts, we defined general rules that could be followed product wide. Some examples are,

Some of the above functionality (editing roles and requesting for permissions) was left out of the first release. Anudeep (Product designer) who was already working on sharing flows for Collections (an entity in Postman) took care of management of roles for that part of the product and also standardise the format of resource specific role management for the future.

4. Migration

Both the user experience and the technical constraints ruled out the possibility for a team using both the older and the newer access control system. Therefore, we had to design paths for teams to migrate to the new system, while also taking all their data and members along.

I created a simple flowchart to capture all the possible flows and states. This accounted for all notifications and state changes which can occur during the migration process.

The flowchart server two purposes:

  1. Orchestrating releases of atleast 7 different services by making clear the expectations of how each part should behave.
  2. Brandon (the UX writer) and I used this to also align the copy across the product, product documentation and marketing.

Results

We had several criteria for success of the feature

  1. No regression because of adoption. With the data and inputs (from users) we have till now, we consider ourselves successful on this criterion. Though we still have to see some of the bigger teams and power users make the shift, we don’t expect this to change a lot.
  2. Future features around access control to have smaller turn-around time. We have only limited basis for making a judgement right now since this is a recent release. However, the next feature in development is using this and it is generally felt that in absence of the new Access Control System, development would have taken longer.