Document Access Control

Overview

In DocuSign CLM, Admins used to manage access permissions for files stored in CLM through a folder-based security mechanism. To ensure desired access, admins had to make sure the documents were stored in appropriate folders. This was cumbersome, hard to scale, and was creating problems in keeping with the journey of a document in its agreement lifecycle. 

The Document Access project termed ABAC (Attribute based Access control) was an initiative to replace the problematic folder-based security model with a dynamic, storage-location agnostic model that used document’s attributes (metadata) to determine user access. 

Designs for the first version of ABAC wrapped up in late fall 2021. Dev work early 2022 with ongoing enhancements until its public release in the second half of 2022.

Key Metrics and Impact

While external data on the customer reception wasn’t reported at the time of writing this case study, there were several wins for the project internally:

• Demoed at the 1st public release event of the year – Momentum, as a highlighted CLM update.
• While initially designed for Core CLM, ABAC project attracted attention of leadership and was requested to be built into all other versions of CLM.
• Delivered on requirements expressed by key CLM customers like Morgan Stanley, USDA, and DOI.

Business Motivation

As contract language and terms change constantly during its life cycle mostly during negotiations but also afterwards (think renewals), that system that houses and manages contracts needs to adapt with the change in data to make it easier for users to work with them. Simple folder security just does not suffice for the needs of modern businesses and large organizations. As a consequence of lack of an enterprise grade document security solution in CLM, the business was facing following challenges:

• Managing access permissions with the limited capacity of folder security model was very taxing on the system as it lead to countless hours of degraded performance and hours of babysitting on the end of TechOps team to resolve customer issues.
• To address complex use cases, customers often orchestrated access rule setting through .csv files and workflows in CLM
• Customers, especially in Public Sector and Financial Services markets, demanded document access control capabilities based on contract document metadata such as contract status, type, value, party, region etc. Not having this functionality would’ve led to adoption issues.

Business Goals

• 20% reduction in time to close support tickets related to document access.
• 50% reduction in escalation tickets related to document access in the legacy folder security model
• 80% reduction in TechOps intervention due to security calculation timeouts in deployed customers

UX Goals

• Create an best-in-class enterprise grade document access control solution that solves for 80% of customer use-cases.
• Simple, self-service model for admins to create and manage access rules which required minimal to no support.

What is Document Access?

The easiest way to understand document access control is to look at a B2C application that stores documents and is familiar to many of us. Let’s take a look at Google Drive, this is what access control look like there:

G-Drive: File–Folder Access

This basic model lets owners and administrators customize access permissions for each file or folder extending 1 of the 3 tiered permission sets to one or more users. The permission sets – Viewer, Commenter, and Editor determine the actions(view, download, comment, edit, delete) that the user can do on the file.

Features

• Individual user based.
• Access control at both file and folder level.

Shortcomings

• Static access control.
• Cumbersome to customize permissions for each user.
• Doesn’t allow for group permissions.

CLM: Old Folder Security Model

In CLM, admins could extend access of a folder to an individual user, user group, or all users that belonged to a certain user profile. Note that they weren’t able to create any access at the file level and had to operate at the file level.

Features

• User, user-profile or group based access.
• Security decided at folder level.

Shortcomings

• No file-level security customization.
• Depends on files being organized into folders.

What was I solving for?

“What if you have 1000s of users and 100s of user groups and you need access to change as the document content is modified?

I wasn’t a part of this project from the outset as this was only handed off to me at a time when most of the research had been done regarding user pain points. What I learned from consuming existing user research was that simple access control just doesn’t cut it for CLM use-cases.

CLM Customer Use-cases

From speaking to customers, we are able to collect their use cases. (Names of customers modified/hidden for confidentiality)

“bob@mail.com has view permissions for any contract that contains 'employeeIDnumber'"

– Telecom company

“Users in HR Admin have view, edit, and create permissions for contracts generated from a I-9 form"

– Telecom company

“Security group 'Default User' can only access documents with a status of “in process” or “executed"

– Law firm

“Users in the Legal group in Oil UK Limited have view and create permissions for contracts generated from a Lubricant sale and Asphalt sale tagged with 'APAC'"

– Oil & Gas company

CLM Customer Pain Points

In the existing system that operated on a folder level and did not consider document metadata for permission setting, it was not only painful but sometimes impossible to create rules like above without having to engineer a complex workflow with the help of a support team.

• As the document moved through its agreement lifecycle, admins didn't have an easy way to update user permissions other than moving them to another folder via a workflow.
• There was also no easy way to set security based on contract status, type, value, and party.
• Admins would've like to set security based on user region and department. This was being achieved by creating security groups specifically for that rule, adding to the list of unnecessary groups and thereby making it hard for admins to manage
• There was no easy way to see who has access to what without opening up each folder security page

Problem Statement

Based on the understanding of the customer problems, we came up with the following statements that needed to be addressed through design in v1 of the ABAC model.

"How might we help Admins who want to be more self-sufficient set user access based on contract attributes so that they can ensure only the appropriate end-users have access at the right time?"

ABAC - The new model

ABAC or 'Attribute based access control' was proposed as the new model to address some of the aforementioned use-cases.

Features

• Dynamic: Access will change automatically with changes in attribute values
• Works with user groups and user profiles

Shortcomings

• Complicates access level calculation per document
• Does not work for individual one-off permissions

ABAC Policy: Dynamic Access

Let’s say ‘document type’ is an attribute with possible values ▲, ■ ,● . Now, if different access levels (view, edit, no access) were assigned for each of those attribute values to the same user, their access would change the moment the value of the attribute ‘document type’ is modified.

ABAC Policy: Least Restrictive access wins

Notice how a blue persona has an ‘Edit access to a file with ▲ through the first group but an ‘View’ access to the same file through the second group. When conflicts like these arise, ‘least restrictive’ access will win. So the blue persona will have ‘Edit’ access, resolving the conflict.

By breaking down the use-case statement, we are able to figure out the variable at play

• Who needs access?
• What is the level of access required?
• What specifically is this access for? (document that satisfies certain parameters)

ABAC - An example

Let's take an example similar to one of our customer use cases and try to observe it through the lens of ABAC.

Design Explorations

When I was was handed this project off, one exploration had already been created by my design partner Sara. After going through the research and building an understanding of the problem at hand, I revisited the existing exploration and iterated on it. We'll take a look at all the explorations we went through as a team.

1. Access rules by group (Sara's exploration)
‍

Pros

• Access rules can be understood and searched easily by admin as they are organized by user groups.
• Focused experience with all inputs on a single page helps build a mental model of the access rule for the admin.
• Can be scaled to create individual user permissions by swapping out group selection with user selection

Cons

• Can only create access rule for 1 user group at a time. Hard to scale when 100s of user groups exist at a time.
• Attributes are applied to documents but it gives the impression that they are a property of a user group.
• Access level (view, edit, delete) cannot be customized by an secondary attribute like status (edit if status='in progress', view if status='signed'

ABAC Exploration 1: Group based access rule

2. Access rules by document type (my 1st exploration)
‍

Pros

• Rule can be created for multiple groups at a time
• Access level can be customized by a secondary attribute such as 'Region' as shown below (Primary attribute is 'document type').

Cons

• Rules are organized by Document Type so only one Document type can be chosen at a time.
• Model hard to scale to individual users

ABAC Exploration 2: Document-type based access rule

3. Open Access rules (my 2nd exploration)
‍

Pros

• One rule can solve for multiple use cases as it can apply to multiple document types and user groups

Cons

• Hard to calculate for the system and also hard to digest for the admin
• Busy page with a lot of inputs increases cognitive load for users

ABAC Exploration 3: Hyper-customizable access rule

4. Stepped access rule creation (my 3rd exploration & selected version)
‍

Pros

• Stepped approach gives admins time to digest the information and also provides a space to review the rule before publishing it
• Retains the customizability of exploration 2 and is not hard to calculate on the system like exploration 3

Cons

• Only lets admins customize access level by 1 secondary attribute
• A rule need to be created for every document type if they're to be visible to a non-admin user since the default is 'no access'

ABAC Exploration 4: Stepped access rule creation

Solution Demo

Let's dissect the selected solution and put it to test. We'll see how it meets the requirements expressed by our customers through interviews with the help of a user story.

Scenario

Abby is an admin at Tally. There’s a group of new hires in the legal department starting soon in the new Chicago office of Tally.

‍Abby was asked to provide all the new legal hires Edit access to all documents of type Master Services Agreements (MSA) whose region is ‘EMEA’.

‍Abby noticed that there was already a user group named ‘Legal- North America’ created by her assistant with profiles for all the incoming new hires on CLM.