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:Repository>, which is a subclass of <sioc:UserAccount>.

Agents

The class of agents comprises several specific entity specializations:

  • foaf:Agent : an agent without authentication
  • <urn:dydra:LocatedAgent> : an agent for which the client IP address is known, but otherwise the identy is not.
  • <urn:dydra:User> : An agent which has been authenticated by name/password combination or by token.

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 either as a password without a user name in the HTTP authorization header or 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 as an password as that avoids its presence in service logs.

SSO Authentication

SSO authorization involves interaction with an identity authority. When the authentication process succeeds, the authority supplies an account and, optionally, a distinct user identity. That account and user combine to constitute the request agent.

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.