Access Control Basics

Overview

Access to Content Fabric objects (create, view, update, …) is governed by access control policies.

The most common, built-in access control policies are referred to as “Base Access Control”.

Policies are programable and can be specified individually for each content object.

Additional resources:

• Access Control Overview and Security Best Practices
• Content Security Whitepaper

Built-in ‘Base Access Control’

The “Base Access Control” system provides a familiar permissions system: users and groups can be granted view and edit permissions to content libraries, content types and basic content objects. This system is normally used within a tenant’s team, and in business collaborations. It is not practical for use in consumer applications.

Upon creation, a tenancy has a “Content Admins” group and a “Tenant Admins” group. The “Content Admins” group has rights to content and libraries and is intended for users with content management roles. The “Tenant Admins” group has rights to groups, content reporting and analytics, media wallet reports and is intended for users with administrative roles.

If your organization requires more roles, create groups based on these roles and grant access to the desired content resources.

Commonly used polices

For common use cases beyond simple group-based view/edit permissions, there are several commonly used policies:

• https://github.com/eluv-io/elv-docs/tree/main/auth/common_policies

Advanced used of policies

Advanced polices can be written from scratch or use one of the common policies as a base. The Advanced Access Control section covers policy development.

Common Practices

The most common way to manage access to objects in a tenancy is through using a Content Admins group with access to all libraries and content objects.

Access Tokens

There are several ways to access content stored in the content fabric - here are the common ones:

As a client application - ‘client-signed access token (CSAT)

As a backend system - ’editor-signed access token’ (ESAT)

Client-Signed Access Token

A client-signed access token is simply signed by the user (content consumer). A client app accessing contnet resources will present this access token and contnet fabric nodes will grant access based on the specific permissions policy of the content.

Sample (node.js): https://github.com/elv-serban/elv-client-js/blob/master/samples/auth/ClientSignedToken.js

Editor-Signed Access Token

This method is employed by backend services that could store a private key (secret) and can sign access tokens on behalf of their users.

Sample (node.js): https://github.com/elv-serban/elv-client-js/blob/master/samples/auth/EditorSignedToken.js