Entity Identification

The Dydra service processing model comprises several elementary entity classes

  • Accounts

  • Agents

  • Repositories

  • Users

  • Views

Each request involves an initial step to identify an agent. This process follows several authentication methods:

  • user name and password (http basic)

  • token

    • static

    • sso

  • location (ip number)

  • session

The model covers their characteristics, their naming and which authentication methods are available to translate a request’s terms into concrete service entities. Service data security resolves ultimately to constraints on which operations one given entity may perform on some other entity. The most primitive relations are directly between agents and repositories, while the other relation forms afford an agent indirect access. Within controlled access pattterns, each access request is checked aginst known constraints. Whether direct or indirect, known combinations are reduced to a direct element in the relation between an agent an the target entity and is recorded in the agent’s capability list.

A minimal capability list is predefined as static program logic. The consequences of configured rules are computed on demand by applying SPARQL queries to the authorization graph. The results are then cached as true or false determinations in the agent’s capability list.

Entity Classes

Accounts

The built-in model uses just one account class, <urn:dydra:Account>, which is a subclass of <sioc:UserAccount>.

Agents

The class of agents comprises several specific entity specializations:

  • foaf:Agent : an agent without authentication

  • acl:AuthenticatedAgent : an agent which has been authenticated by name/password combination or by token.

  • <urn:dydra:User> : an authenticated agent which corresponds to a foaf:Person.

  • <urn:dydra:LocatedAgent> : an agent for which the client IP address is known, but the identity is not.

An agent is identified with a URL of the form <http://dydra.com/users/agent1>

Repositories

The built-in model uses just one repository class, <urn:dydra:Repository>, which is a subclass of <http://purl.org/dc/terms/Dataset>

Users

A user is an authenticated agent.

Views

Each request to the SPARQL endpoint includes a query. The query is either sent in-line - whether as the query argument in the request URL, as the content of a POST request, or as the query argument of a request form, or it is incorporated by reference - whether as the third component of the request URL path, or as the view argument of a request form.

Entity Identification Methods

HTTP Basic Authentication

The HTTP Authorization header carries user name and password information. These specifiy a user in the identity model. That user and their respective account combine to constitute the request agent.

Static Token Authentication

A token can be supplied in one of three ways:

  • as a password without a user name in the HTTP authorization header

  • as a bearer token value in the HTTP authorization header (see RFC 6750)

  • as the value of the auth_token URL query parameter

In either case, it specifies a user and, optionally a distinct account. That user and account combine to constitute the request agent.

In cases where the authentication affords access to sensitive data, the recommended practice is supply the token in a header.

SSO Authentication

SSO authorization involves interaction with an identity authority. When the authentication process succeeds, the authority supplies a collection of identifying attributes which are interpreted to determine an account and, optionally, a distinct user identity.

  • Group : If a group is present and it identifies an account, choose the account. If a name is also present choose that as the user.

  • Email : If an e-mail address is present and belongs to an account, choose that account.

  • NameID : If a name is present and identifies an account, choose that account.

  • PersonImmutableID : If the value corresponds to an account authentication token, choose that account.

The chosen account and user combine to constitute the request agent. If the attributes do not describe a known account, or the account’s e-mail address is not within the service domain, then a default account is elected, as per the service configuration.

Once the account is confirmed, a session token is generated and returned to the user agent to be supplied as the authentication cookie for subsequent requests.

Location (IP-Number) Authentication

If no other authentication information is provided, the request client location is attached to a located request agent.

Session Authentication

As a consequence of a basic or SSO authentication interaction, the service generates a session identifier which it furnishes to the user agent as a component of an HTTP cookie. This identifer is used to authenticate subsequent requests from interactive user agents and can be used as well for programmatic access.