Skip to content

Security model

Jump to bottom
Simon Cox edited this page May 21, 2015 · 21 revisions

Authentication and identity

Authentication of users can be performed through a normal userid/password validation or through the use of OpenID Connect (which layers on top of OAuth 2.0).

Prior support for OpenID Authentication 2.0 is still present in the database but use of it is deprecated (since most OpenID providers are removing support for it).

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 Connect 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 of the form https://plus.google.com/114719444327647609228.

In the case of OpenID Connect then the user name is obtained from the OpenID 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
    & RealDelete true delete of an entry, outside the normal 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
Submitter specific register Register Update
Reviewer specific register StatusUpdate

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. Note that neither of the normal Manager/Maintainer roles have permissions to RealDelete, which is normally reserved for a system administrator.

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.

Clone this wiki locally