Security model

Authentication and identity

Authentication of users can be performed through a normal userid/password validation or through the use of OpenID Authentication 2.0 .

In the original POC implementation only OpenID was supported. This was intended to be compatible with likely future government authentication schemes and enable us to provide authentication in the Registry without having to store credentials or personal information locally. However, since that original decision no government OpenID provider has emerged and many public OpenID providers have withdrawn their service, including Google.

In the current solution the user information stored by the registry comprises:

• user id which can be an OpenID or another identifier such as an email address
• user display name or nickname
• password credentials

If the user identifier is an OpenID identifier then the user can login either using OpenID or using an associated password. In other cases the password is required. The password is also required for API use.

In the case where OpenID is used then 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 .

In the case of OpenID then the user name is obtained from the OpenID provider using OpenID Attribute Exchange 1.0 . The precise set of name attributes available varies by provider.

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.

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. Previously, when OpenID authentication was the only supported mechanism, this achieved by creating a temporary password. In the current solution all users can have a permanent (though changeable) password and can use that for access.

Session level login is provided by two API endpoints /system/security/apilogin and /system/security/logout.

A POST to /system/security/apilogin with form parameters userid and password will 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
   ...
   curl -i -b cookie-jar -c cookie-jar http://ukgovld-registry.dnsalias.net/system/security/logout

Sessions time out after 30 minutes.

Security API

The details of the security API are implementation dependent. The API provided by the POC implementation is summarized below.

API	Purpose	Parameters	Return
POST /system/security/login	Login via a registered OpenID	provider the OpenID provider to use return the URL within the registry to return to after login	Redirects to the return URL
POST /system/security/pwlogin	Login via a password	userid the user identity password the user password return the URL within the registry to return to after login (optional)	Redirects to the return URL or /ui/admin
POST /system/security/register	Register an OpenID and login with it	provider the OpenID provider to use return the URL within the registry to return to after login	Redirects to the return URL
POST /system/security/pwregister	Register a new user	userid the user identity password the user password name the user display name or nickname return the URL within the registry to return to after login (optional)	Redirects to the return URL or /ui/admin
POST /system/security/logout	Logout of the current authenticated session		Redirects to /
POST /system/security/apilogin	Login using a password, for use in API scripting	userid the id of the user password the authentication password.	200 or 403 status
GET /system/security/username	Return the name of the current authenticated user. Used for testing.		User name as text/plain
GET /system/security/listusers	List users to whom you could grant permissions	query partial user name to filter possible users uri the uri to which to grant access grant the permissions to be granted	Rendered text/html listing users
POST /system/security/grant	Grant permissions to a user	user user’s id path the uri to which to grant access grant the permissions to be granted	Redirect to uri
POST /system/security/ungrant	Remove all permissions that a user has over the given uri	user user’s OpenID path the uri to which to grant access	Redirect to uri
POST /system/security/createpassword	Generate an authenticated password for API access	minstolive lifetime for the password	Rendered text/html display of the generated credentials
POST /system/security/setpassword	Change the password of the current user	currentPassword the current password of this user newPassword the new password to set return the URL within the registry to return to after login (optional)	Redirects to the return URL or /ui/admin
POST /system/security/resetpassword	Change the password of another user, only possible by an administrator	userid the id of the user whose password is to be changed newPassword the new password to set for that user return the URL within the registry to return to after login (optional)	Redirects to the return URL or /ui/admin
GET /system/security/listadmins	List all users with administrator permissions		Rendered text/html list of amins
POST /system/security/setrole	Set or remove administrator permissions for a user	id the OpenID of the user role The role to grant, “administrator” or ""	Redirect to /ui/admin

Parameters are passed to these calls as a form parameters in a POST body of type application/x-www-form-urlencoded.

Migration

Migrating an existing registry installation which only supports OpenID to the current code base which uses passwords should be automatic. There is no change in the format of the database holding the user credentials and the existing OpenID identities should continue to work if they are working now.

As a precaution we recommend creating a temporary API key for the administrator with a long time to live. That key can then be used as a password in the migrated system. So long as one administrator can login then they can reset credentials for other users if necessary.