This article describes the domain model that Elimity Insights employs to reason about the authorization data loaded from its sources.

Extensible data model

Elimity Insights provides a fully-configurable graph data model of entities that are assigned attributes and that are linked to each other. Think of the data model as the database schema of a source in your own Elimity Insights deployment.

The data model consist of the following parts:

Entities

Entities are the basic objects in a data model. Common examples of entities are users, groups, roles or files.

Every entity at least has the properties id (string) and name (string). These properties have to have a value assigned for every entity.

Apart from the id and name, all other information about entities is stored as attribute assignments (see later on). These can be not-assigned (have a NULL value in SQL terminology).

Entity types

The entities in Elimity Insights are structured in multiple entity types. An entity type has a name and defines which attributes can be assigned to entities of that type (the attributes types of the entity type).

The entity types are defined in an ordered list, which is used in the menu and on entity details pages.

As an example, a typical Active Directory source has at least the User and Group entity types:

Attribute types

An attribute type defines a type of information that can be assigned to an entity or a relationship. These attribute types then form the columns in the datatables in Elimity Insights and form the basis for filtering, querying, grouping and other analytics.

Attribute types have an id (for internal usage), a name (for the UI), an optional description and a data type (string, number, boolean, date, time, datetime).

All supported attribute types can currently only have a single assigned value. Elimity Insights does not support multi-valued attribute types (e.g., the cost centers of a user) yet.

For example, the User entity type in a typical Active Directory source has the following attribute types defined:

Relationships

Relationships model that Elimity Insights entities are linked to each other. 

Most of the time, a link well mean "is assigned to", e.g., for users and roles, or roles and entitlements. However, strictly seen Elimity Insights does not know the semantics of such a link and we use the term "linked" to cover all cases.

Directly vs indirectly linked entities

An entity can be directly linked to zero or more other entities.

When performing AQL queries, Elimity Insights traverses the direct links to calculate all indirectly linked entities. For example, take the following entities and relationships:

In this example, user John Smith has three "linked permissions":

1. Permission A is directly linked,
2. Permission B follows from Role A and Role B,
3. Permission D follows from Role B.
   

No cycles

In order to guarantee highly-performant queries, Elimity Insights poses some restrictions on the relationships that together avoid cycles in the graph of linked entities:

• Entities can only be linked if they belong to different entity types (e.g., you cannot link two users to each other).
• Links represent directed relationships and the direction has to follow the order of the entity types.

For example, when you have 4 entity types, the following links are permitted (note again that the order of the entity types matters):