Security model

Authentication and identity

Authentication of users is performed using OpenID Authentication 2.0 . This is intended to be compatible with likely future government authentication schemes, enables access to widespread existing authentication services such as Google and enables us to provide authentication in the Registry without having to store credentials or personal information locally thus reducing the burden of operating a registry service.

The internal identifier for a user is the identity URI provided by the OpenID authority. For example, authentication via a generic Google account yields an identity URI of the form https://www.google.com/accounts/o8/id?id=AItOawnQBYnsRksvzmoKfzHW3NX5_EVBQ7DkbhI whereas authentication using an individual’s Google profile yields a URI which resolves to the users profile page such as https://profiles.google.com/114719444327647609228 .

When an administrator needs to associate a role with a user we need a human readable alias. For the proof of concept we will use a human readable name for the user obtained from the OpenID provider using OpenID Attribute Exchange 1.0 . The precise set of name attributes available varies by provider. The proof of concept will assume attributes compatible with the Google OpenID attribute schema, viz. firstname and lastname.

When assigning roles it is up to the granter to satisfy themselves that the identity to which they are granting role privileges corresponds to the intended real world person. For an OpenID provider which provides public access to profile information (e.g. individual Google + profile pages) this may be easy. For other providers (e.g. general Google account) then a manager may need to take additional steps. Such identity verification is out of scope of the proof of concept.

Permissions

The set of actions for which permissions can be granted or denied are:

• Register an item in a register
• Update an item or register metadata
• StatusUpdate of an item within life-cycle constraints
• Force a status change outside the life-cycle
• Grant manager rights on a register, maintainer rights on an item
• GrantAdmin grant full administrator role

All except the last permission are qualified by a location. Permissions inherit down the location tree. Thus for example:

   Register,Update:/reg

allows the corresponding user to both Register and Update /reg and any sub-register or item under /reg.

All read actions are assumed to be uniformly available. No login is required to read any part of the registry. So a separate read permission is not needed.

Delete is not a separate permission because it just corresponds to a status change.

This permission set could be further subdivided in the future. For example, one might conceivably want to grant permission to register a simple item but not a sub-register. Or one might want to grant different permissions over different status transitions. However, for the proof of concept we have no use cases for such finer grain permissions.

Note that a single API action might require multiple permissions. An API call can both register/update an item and can change its status either explicitly (in the request parameters) or implicitly (by including a reg:status value on a reg:ResisterItem in the payload).

Roles

We group these permissions into four roles.

Role name	Applies to	Permissions
Manager	A specific register and its contained subtree	Register Update StatusUpdate Grant
Maintainer	A single non-register item	Update Grant
Authorized	Specific register	Register Update StatusUpdate
administrator	Whole registry	All permissions

The first two roles are intended to be the primary operating roles. The UI allows administration permissions (Manager or Maintainer) for a given location to be assigned to a known user. This is done via the “administer” tab on the item view. The tab is only visible to authenticated users who have Grant permission at that location.

The Authorized role is provided to allow open experimentation with designated areas of a registry. The registry provides an built in anonymous user (pseudo openid: http://localhost/anon). A manager can make a register or item open for such experimental using the “Add any” control on the “administer” tab. This will assign the group of permissions corresponding to Authorized to all registered users. This means can any user can register with the registry and immediately update any item within such an open area.

Non-browser access

API operations, other than read, require an authenticated session.

This is problematic since OpenID requires the sign-on to take place within a browser interacting directly with the registry service. This is not possible using external tools such as curl or custom UIs.

We solve this by allowing an authenticated user to generate an API token, with a finite time to live, which can be used to establish an API session. This essentially generates a secure random password (which is stored salted and hashed in the credentials database) which the user can use to open an authenticated session.

Two API endpoints are provided for this /system/security/apilogin and /system/security/logout.

A POST to /system/security/apilogin with form parameters userid (set to the OpenID URI for the user) and password (set to the generated password) with establish an authenticated session. The user can then use any API tool which records and transmits the session cookie.

For example:

   curl -i -b cookie-jar -c cookie-jar --data "userid=https://profiles.google.com/114719444327647609228&password=307cd20902a138b90f47cfe6c6ca707c" http://ukgovld-registry.dnsalias.net/system/security/apilogin
    curl -i  -b cookie-jar -c cookie-jar -H "Content-Type: text/turtle" -X POST --data "@test/blue.ttl" http://ukgovld-registry.dnsalias.net/def/colours
Sessions time out after 60 minutes. The password credentials can be set to have more or less minutes to live than the sessions themselves.