Rubicon’s advertisement management platform, REVV, makes it easy for thousands of our customers to interact with our ad servers. Each of our customers use REVV in their own way, using different tools, accessing different resources, via different interfaces. To accommodate this diverse set of needs, we developed a single access control library (ACL) and accompanying interface to organize users and resources into groups to make it easier to manage this complicated system.
Early in REVV’s development we realized that simply associating software credentials to users wasn’t going to scale well, with sometimes hundreds of new users being added each week. So we decided to tackle the problem with standard ACL techniques, but with a little bit of creative user interface flair.
Users, Roles, Resources, CRUD (Create, Read, Update, Delete) settings
Users HAVE Roles
Roles HAVE Resources with CRUD settings
Users HAVE overridden Resources with CRUD settings
Every section of our code is either enabled of disabled by a Resource + CRUD setting. For instance, when a user saves a campaign, we check to see if they have proper privileges to the “Campaign” resource, and that their “Update” CRUD setting is enabled. Only then do we allow the save action to proceed successfuly.
In addition to CRUD, we also use “View” and “Do”. These are useful for protecting interfaces and processes with permissions.
On our Edit Resource screen, we list available CRUD options for each resource—in the image on the left, only “Do” is allowed. Beneath the options are all the users and roles for this particular resource, with links to edit settings for each on subsequent Edit User or Edit Role screens.
The Edit Role screen shows users falling into a particular role, along with the Resource/CRUD combinations granted by the role. Green checkmarks mean the role grants access; empty checkboxes mean the role doesn’t affect permissions, and a red X means the role explicitly denies the resource—even if another role shared by the user allows it.
On our Edit User Permissions screen we can see what roles a user belongs to and also explicitly add or remove resources for this particular user individually via the Edit User Overrides link, which overrides any settings inherited from roles. On the right are the cumulative permissions granted and denied this user by their roles and overrides, with a green check meaning Allowed, a grey dot Denied, and a red X Explicitly Denied, which is essentially treated the same as Denied.