BlogDesigning Modern Enterprise SaaS: Content Access Management

Planorama’s SaaS Administration series examines the design and architecture of modern SaaS applications.  We shed light on Users and Access Management our previous article. In this third installment, we focus on common considerations for managing content access.

We introduced the utility of the SaaS admin panel in prior articles, focusing first on users’ permissions to perform certain actions. Now we go deeper into the panel’s functionality and focus on the content that SaaS users are given access to.  

First, let’s establish that content comes from a variety of sources dependent upon the application. We can generally categorize sources of content as follows:

1. User Generated Content (UGC):  SaaS users directly create content like articles, news posts, conversations, voting, reviews, etc.  It’s difficult to conceive of a modern SaaS application where users do not create some type of UGC.
2. System Generated Content:  SaaS algorithms can also directly create content or create content from user input.  Some examples are dashboard summaries, auto-generated categories, AI-generated information or application metadata. 
3. External Content:  Finally, the SaaS application interacts with the outside world, likely through API’s.  It may interface to “edge devices” or any numerous IoT devices to acquire external content.  Some broad examples are external news or statistics, weather reports, tank levels, and even metadata that augments existing content in the SaaS application.

In general, any SaaS application’s content is aggregated from all three categories.  Excellent SaaS management depends on a SaaS admin panel design for determining and managing which content each user is given access to.

Tenancy to Restrict Content Access  

In general, all SaaS content is not made available to every customer.  Especially in enterprise SaaS applications, content normally needs to be siloed by customer.  Most modern B2B SaaS applications, and some B2C, use some type of tenanted architecture to segment SaaS configuration, content, and users into private areas for each customer.  In a single-tenanted approach, the application, configuration, content, and users are physically siloed to a separate infrastructure resources per customer.  Alternately, with the more common multi-tenanted approach, the application is generally shared across all customers, and so are the infrastructure resources; the configuration, content, and users per customer usually exist in the same database. 

While there are many cost and ongoing maintenance benefits derived from a multi-tenanted approach, the SaaS application must ensure one customer’s data, while residing in the same database, isn’t accessible to other customers.  In addition, the admin panel for a multi-tenanted SaaS application will essentially handle two types of administration.  One type is administrative management of the overall SaaS application, at a hierarchical level above all customer tenants.  The other type is administrative management of configurations within a particular tenant.  A well-designed admin panel will clearly identify which type of configuration is happening so admin users understand the scope of their actions. 

With SaaS content now restricted to each customer tenant, let’s move on to discuss common access control schemes with a tenant.

Access Control Schemes

In the series’ previous article we examined permissions as a common mechanism to grant users rights within the SaaS application.  Many permissions are related to content access, simply because users often create, edit, view, and delete content.  For a multi-tenanted SaaS application, administrators within the tenant normally set content-related permissions for their users.  

There are various access control schemes to manage the content permissions within a tenant.  A notable scheme is Attribute-Based Access Control (ABAC) which employs attributes of the user, content, and context, to form policies that determine what users have permission to do with any given content.  Here, the admin panel needs support management of all of the attributes and policies that will dynamically grant content permissions to users.

As an alternative to ABAC, consider the Role-Based Access Control (RBAC) approach.  In RBAC, the admin panel design supports exact definition of roles with specific permissions granted to perform actions on content.  In contrast to ABAC which relies on policies, RBAC is a static approach where the user role grants the content access.  Yes another access control scheme is centered around User Groups that define a set of content access permissions.  In this case, users are assigned to one or more groups, and those users inherit the permissions and access capabilities for that content.

Depending upon the chosen scheme, the admin panel may support certain capabilities, such as:

• Viewing, searching, filtering the content in the SaaS
• Setting attributes for users and content
• Viewing, creating, and editing policies for content access
• Configuration of content access permissions per role
• Viewing, creating, and editing user groups for specific content permissions

In the end, SaaS application UX designers and software architects can implement any of a variety of schemes to support the desired simplicity, flexibility, and granularity of the app’s content access. The key is to consider this complexity early on in your project to avoid significant redesign and rewrite of your SaaS application.

Working together, multitenancy and the selected content access control scheme gives businesses the necessary flexibility in setting the user boundaries in their SaaS application.  

Impersonation

Impersonation is a useful technique where the SaaS administrator assigns a particular configuration of content access and permissions, and then can experience it as a user would.  Impersonation is often made available to certain administrative users via the admin panel.  This eliminates inefficient and repeated creations of fake users in a given customer tenant followed by trial-and-error of the unique configurations to ensure the access privileges are correct.  

With impersonation, the tenant administrator temporarily and immediately experiences the configured access boundaries of certain users.  In addition, the SaaS application owner’s system admins can manage configurations of a particular customer by entering the tenant itself. This saves time for administrators who need to test permission boundaries on behalf of other users.  It also helps reduce confusion for administrators, since the UX design generally makes it very clear when an admin is impersonating (acting on behalf of another customer’s tenant) versus performing operations at the system level.

Closing Thoughts

Content is at the core of SaaS applications, whether generated by its own users or some internal or external entity or function.  Defining who can access content is equally core to a SaaS application.  This is ultimately configured in an admin panel that your team choses to design.  There is usually significant complexity in the rules that surround content access.  Recognizing this complexity and planning for it, coupled with professional UX/UI design that compliments the data architecture will simplify user configurations so less mistakes are made over time, and content is not put in the wrong users’ hands.

Stay tuned for our next article which will continue the conversation about Content Management. 

Photo by Patrick Tomasso on Unsplash