Introduction

This section introduces the vocabulary for technical teams to define identity graphs, related accounts/groups, and access authorization lists. It assumes familiarity with graph and security concepts.

Definitions

Authorization Context (AC) - The process vector comprises account, agent, repository and view.

Identity Graph (IG) - The Dydra Identity Graph (DIG) maintains the list of identities qualified for access to the Dydra service.

Agent - The authenticated agent is an abstracted individual (identity) which allows for either native identities, or for externally provided identities from third party identity providers e.g. SSO. None for anonymous access.

Account - The account for which an agent is authenticated. For each account dydra maintains a repository with the authorization declarations for all of the resources in that account. The account provides the context for relations. This value is derived during the authentication process and remains unchanged. None for anonymous access.

Access Control Graph (ACG) - Each account ACG defines the authorized access to each resource owned by the account. This includes the account itself, its repositories, and the views defined for the repositories. This graph provides the capabilities available to the account.

Group - An arbitrary set of entities - agents, repositores, views or other groups, with which access rights may be associated.

Repository - A resource, the repository e.g. data, is the target of a given query. It exists for the duration of that clause.

View - A resource, specifically a program or query. The view is initially determined from the request. If the request resource designates a view, that is the initial value. Otherwise the inline content serves as an anonymous view.

Request/Response Content - A SPARQL request body contains a query (an “inline view”) while a Graph Store request contains a graph. The response body contains the query solutions and the target graph, respectively.

Resource - Dydra system entities/objects:

• Accounts

• Agents

• Users

• Repositories

• Views

Not all Dydra resources are “target entities”. Specifically, the external interface exposes no operations on agents and the model does not support constraints on individual graphs in a repository. Operations on agents are performed through the web user interface and command-line programs only. Rather than encumber query processing with graph-level constraints, controls are applied on inter-repository federation.

Mode - the operations available to an agent:

• Read

• Write

• Execute

• Control

Search for Authorization - The ACL for a session governed by the relation between the agent, the target resource, and the modes(s)

Dydra Identity Management and Access Control Model

Dydra Graph Based Access Control (ACG)

Dydra stores and manages identity, role, and permission information information as semantic graphs which allow for use of standard Graph Store and SPARQL operations to specify agents and their access rights to system resources.

Each registered user/identity creates a new resource in the Dydra Identity Graph (DIG). The DIG is only accessed indirectly through system operations only, due to cyber security considerations.

Each account maintains its own Access Control Graph (ACG) to allow for the definition and application of modes (permissions) to resources (repositories, views, users, accounts, agents). Each ACG can be viewed, browsed and edited by the account owner, like any other repository.

The Dydra model supports controls such as those defined in role based access control (RBAC) systems. The two key differences are:

• the GBAC uses a structured and formal query language e.g. SPARQL to derive access controls rather than depend on their enumeration.

• the Dydra model identifies its terms with IRI

An overview of the terms and their relations is visible in the “GBAC model” diagram:

The Dydra GBAC model

Dydra GBAC vs RBAC

RBAC is used by many security professionals who may not be familiar with set theory or expressing relations in semantic web or graph data ways. Organizations and professionals familiar with RBAC can use the Dydra security framework to define RBAC models. The issue is often one of mapping terms. The below table maps terms from Dydra graph concepts to those most often used when discussing RBAC.

Dydra Term	RBAC Term
account	user
user	user
agent	role
type	role (hierarchy)
mode	permission
resource	object

A RBAC mechanism uses roles (R) to organize users (U) and permissions (P), where roles represent organizational responsibilities of the users of the information system.

Using this system, an organization can:

• assign users to roles

• assign permissions to roles

• and assign roles to roles to define a role hierarchy

The below table illustrates the relation between RBAC and Dydra terms.

Dydra Term	RBAC Term
agent assignment AA The set of all pairs accounts A x users U \(\text{AA} \subseteq A \times U\)	User Assignment UA The set of all pairs users U x roles R \(\text{UA} \subseteq \text{ \ U} \times R\)
mode assignment MA The set of all pairs modes M to agents G \(\text{MA} \subseteq M \times G\)	Role Assignment RA The set of all pairs of role and permission \(\text{RA} \subseteq R \times P\)
type assignment TA The set of all pairs entity (E+T) and type T asserts direct membership and permits to infer indirect assertions \(\text{TA} \subseteq (E + T) \times \text{T}\)	Role Hierarchy RH The set of all pairs of roles r1 to roles r2 only if all permissions of r2 are also permission of r1, and all users of r1 are also users of r2 \(\text{RH} \subseteq R \times R\)

Rather than articulating “role” as a specific relation between two entity types, Dydra applies the more general “type” to to any resource, and provides flexibility beyond the use of “role” in RBAC models. For example, in RBAC the term “role” would be applied to a “user” and “capability” to an object. In Dydra, both can be expressed as types e.g. agent to type \(G \rightarrow T\)or resource to type \(R \rightarrow T\).

Dydra Security Relations Model

Authorization Status

Dydra records authorization status as a relation between the agents, the target resources, and access modes in the context of a request. Particular elements of this relation, i.e. an agent’s state, constitutes the agent’s capabilities or the sum of all authorized operations for an agent against resources. The initial state comprises the agent, account, and mode for a given request. This is transformed as a request is processed to include additional resources e.g. repository, view, stream. The search for authorization is governed by this eventual, current state.

The defined set of relations constitutes the Dydra capability model, allowing for entity resources to serve as capability containers and therefore behave in a similar manner to roles. Dydra constructs this capability list from the agent to the modes to the resource and stores it as part of each accounts ACG.

Default Authorization Status for Views and Repositories

The Dydra API supports two aspects to authorize:

• for access to a view

• for access to repository data

View Authorization

Dydra views, (e.g. queries or programs) can be inline, or saved and versioned as resources. They are applied to a target resource, a repository, or the “data”. The default rules for running, or executing a query (creating a view) are:

• an authenticated agent has execute access to all views defined in the account for which the agent is authenticated.

• an agent has execute access to the request inline view.

Anonymous access to saved views must be authorized. As a matter of site configuration, authorization can be required for anonymous access to inline views.

Repository Authorization

Dydra does not define default access rules for repositories. Any direct access to a repository must be authorized.

For federated queries, access requires that one of the following be true:

• the Agent has access

• the active View has access

• the active Account has access

• the origin Repository has access to the target

The HTTP request resource designates the initial repository. A federation operation establishes the service clause location as a replacement value.