Access Control in OpenTox

Authentication and Authorization (often referred to as AA) form the very core of network security along with Accounting being the third 'A' of the trilogy. Authentication is the process of trusting a user's alleged identity by requiring certain evidence like pairs of id and password or attested digital certificates by some trusted authority.

Simply put, authentication is about confirming that the users are those that claim to be. Authorization is a process that follows authentication and determines access privileges to the system including – but not limited to – retrieval of information from databases and use of web services or other functions of the system. So authorization determines whether a particular authenticated individual has the right to perform a given action thus frames users with certain restrictions. Finally Accounting refers to the tracking of actions of a particular authenticated user with most important being the consumption of resources like storage usage and computational power. In OpenTox, these principles of network security are materialized by means of a central access control system based on Single sign-on.

An access control infrastructure for OpenTox is necessary to provide a security mechanism supporting AA. Accounting is delegated to the service providers according to their processing and storage resources. It is fundamental for a distributed system like OpenTox to provide a rigid access control system that enables administrators and system providers to :

  1. Flexibly specify and modify access privileges to users and user groups

  2. Segregate public and private data

  3. Protect users' private information such as passwords

  4. Build web services decoupled from the AA infrastructure (administrative access to some database is not necessary) or even provide completely public services without AA

For these reasons, Single sign-on was chosen as the security mechanism in OpenTox. The principles of SSO and how these bind with REST and with the OpenTox web services, is described in detail in the Deliverable Report D.3.3. The REST API for accessing the SSO infrastructure is described in http://www.opentox.org/dev/apis/api-1.2/AA.

The realization of access control in OpenTox is based on a central SSO server which is employed by individual web services to decide for a users access to them or to other service to which the first act as gateways or proxies. The following figure depicts the main concept and how services interact with the single access control manager when a single service is involved.

The client identifies itself providing an authentication token to the OpenTox web service it wants to access. Tokens are generated by the SSO services upon request (over an secure TLS-encrypted connection) the user's identifier and password (user credentials) and have a certain lifetime. In the current implementation, tokens stay active for 24 hours unless they are invalidated by the client. The web service receives this token and using the SSO service checks whether the token is valid (corresponds to a logged in user) and whether that user is granted the necessary privileges to perform the request. If authentication or authorization fails, a status code 401 is returned to the user along with an error report.

In case the initial client request induces a second request from the invoked service, this is always done on behalf of the user using the provided token. This token is passed to the next service(s) of the work-flow and in case authorization fails somewhere in the middle, an error report is generated an propagated backwards to the client with a status code 401.

In the scheme described above, service 1 passes to the remote service the token of the user that initiated the request. This way it is guaranteed that an end user will not access, either directly or indirectly (through some other service) confidential data unless he is authorized to do so.