Directory

The Aserto Directory stores information required to make authorization decisions. It is flexible enough to easily support different access control strategies including Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), and Relationship-Based Access Control (ReBAC).

An authorization decision is an answer to the question "Is subject S allowed to perform action A on resource R?" In other words, authorization decisions determine whether a subject (user, group, service, etc.) has a given permission on a resource (document, folder, project, etc.).

Concepts

The Aserto Directory helps to define policies that make authorization decisions through three main concepts:

• Object: Objects represent the participants in authorization decisions. Some objects represent subjects—actors who perform actions—and other may represent resources—the items that subjects can attempt to access in various ways.

• Permission: A kind of action that subjects may attempt to perform.

• Relation: A labeled association between a source object and a target object, which may carry with it a set of permissions.

Using these concepts, an authorization decision can be rephrased as "Does subject S have a relation that carries permission P with resource R?" A relation between a subject and a resource can be defined explicitly, or be implied from group membership. For example, the subject S may be a member of group G, which in turn has a relation that carries permission P with the resource R.

Directory as a Graph

It is convenient to think of the Aserto Directory as a graph in which objects are the nodes and relations the edges. Under this model, the authorization quesion in the previous section can be rephrased again as "Is there a path from the node S to the node R in which one or more edges have permission P?"

Indeed, the directory API provides methods to query and traverse this graph of objects and relations.

Examples

With these building blocks, it's possible to construct expressions like:

• Euan is a member of the Sales-group
• Sales-folder is a parent of the Sales-plan-document
• Sales-group is a viewer of the Sales-folder
• The viewer relation includes the read permission

And answer queries like:

• Does Euan have the read permission on the Sales-plan-document ?

The Aserto directory is able to evaluate this graph query, traversing through these relationship and determining the outcome.

Types

To help define different kinds of objects and specify the relations that may exist between them, the Aserto Directory provides two extensible sets of types:

• Object Types define the kinds of objects that can be created in the directory.
• Relation Types define the kinds of relations that can be created between directory objects.

Built-in Object Types

The Directory is pre-configured with a few types:

• User: a principal (used as a subject)
• Group: used to model a collection of users and/or other groups (can be used as a subject or object)
• Identity: an identifier for a User (e.g. email, PID)
• Application: an object that a User may have a relationship to
• Resource: a generic resource

Built-in Relation Types

The following relation types are also pre-configured:

Relation type	Object type	Description
Member	Group	A subject is a member of a group
Identifier	Identity	A user is identified by an identity
User	Application	A user can have applications
Manager	User	A user has a manager

The Aserto Directory seeds User instances and Identity instances (and the relationships between them) from any identity providers that has been connected to the Control Plane. Some identity providers also allow importing Group objects. All of these imported objects are available to Authorizer instances for making authorization decisions.

User-defined types

Object and relation types are extensible. Aserto makes it easy to create your own types which model your resource hierarchy / domain model. For example, you may have Organizations, which may have Folders. Aserto lets you create these object types in the directory, along with relation types (like Viewer, Editor, Admin, Owner) which model the relationship between these objects and subject types (such as User or Group).

Directory implementations

An an abstract level, a Directory is a service that implements the Directory gRPC contract.

Currently there are three implementations.

Aserto Central Directory

The Aserto central directory, hosted at directory.prod.aserto.com, is a Postgres-backed multi-tenant implementation of the directory contract. Every Aserto tenant / organization is provisioned with a single directory tenant. The directory contents are accessible to a caller via read-only and read-write API keys, and are shared across Policies.

Topaz Directory (EDS)

Each Topaz instance has its own clone of the directory, known as the Edge Directory Service (EDS), implemented as an embedded BoltDB database. Topaz authorizers use the EDS for real-time access to anything stored in the directory, including user properties, groups, roles/relationships, and any other objects. These can be accessed in policies to help make authorization decisions.

Aserto transparently synchronizes changes from the source identity providers (e.g. Auth0) to the Aserto Central Directory, and from the Directory to each of the Edge Directory Services that live within the Topaz Authorizers.

Local Directory

The Postgres-backed Aserto Directory can be deployed as a container in a customer environment. This deployment option is available with a commercial license.

Authorizers and the Directory

The Aserto Hosted Authorizer is configured to connect to the Aserto Central Directory.

Topaz can be configured to connect to any of the three Directory implementations mentioned above. By default, Topaz spins up its own EDS, but can be configured to connect to a remote Directory implementation - the Local Directory or the Central Directory.

Regardless of the Directory implementation, Policies can access Directory contents via a set of built-ins.