NMC security requirements

From BioAssist
Revision as of 19:04, 4 November 2010 by Rob Hooft (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Security Requirements NMC Data Support Platform

Version:Machiel Jansen 1-7-2010


This page presents a brief overview of the proposed requirements regarding Authentication, Authorization and Accounting (AAA) for the NMC Data Support Platform (DSP). Potential users can request a login and password by applying for an account at the NMC. The NMC will set up a procedure by which new applications will be judged.

Data security

Research data may be subject to privacy laws and regulations. The DSP will not enforce these or issue warnings. Instead a ‘Code of Conduct’ for proper user of the DSP will be set up by the NMC. The system will contain a disclaimer against storing privacy sensitive data in the DSP. Patient records should NOT be stored in the DSP.


Data will not be stored encrypted. The transfer of the network and the internet will be encrypted by https. Users will login with a username and password.


In the DSP we will distinguish roles for each user of the system. Each user will be given at least one role which allows him or her to perform certain actions within the system. These actions can be of the following types: Create(C) , Read (R), Update or write(U) and Delete (D). In addition, data elements in the system are also owned (O) by users with a specific role. Creating a project, study or data file in the DSP will make the user owner of that data item. Based on the access rights provided by the owner, users have read/write access to the data in the DSP.

The following roles can be distinguished:

  • Project Leader The leader of the project is responsible for the content and access to the project
  • Project member Can read/write data in the project
  • Sub Contractor Can own data within the project and may hide data from project leader
  • Global Administrator Can create users and institutes or organizations
  • Local Administrator Can create users for an institute or organization
  • Guest Has only access to public data

The Project Leader (PL) is the person responsible for the content of the project. He/she is allowed to created studies, samples and create data items. The PL can select users and promote them to Project Members (PM’s) by assigning read/write access to them, within the context of the project.

If the PL grants a Project Member (PM) read or write access then the PM is able to read or write all data in the project which is owned by the PL. All data that is uploaded or changed in the project is owned by the PL. An exception is formed by data that is created or uploaded by the Sub Contractor in the project owned by the PL. A PL can add a Sub Contractor (SC) to the project. This user can own and create his own data items in the DSP and later transfer ownership to the PL.

The reason for introducing the SC came up in conversations with people from the DCL in Leiden. The DCL often performs measurements for studies and returns to the PL the resulting peak information. The intermediate data is not returned, unless it is specifically asked for. In order to facilitate such a use of the DSP the DCL will take the role of SC and transfer ownership of the peak data files to the PL. Information about QC’s and other intermediate or raw data can still be in the DSP but invisible to other users. A Global Administrator (GA) is able to view and change all data within the DSP. This user will be bound by NMC procedures and regulations not to abuse access to the system. The GA is not a normal user of the system but takes care of bugs, problems and maintenance. The GA also can add users and institutes. A Local Administrator (LA) can create users which belong to a certain institute.


The following actions will be logged for accounting purposes.

  • Data and time of user log in
  • Date and time of user downloading a dataset
  • Data and time of user updating or deleting a dataset
  • Date and time of transfer ownership (from SC to PL)

Miscellaneous remarks

WRITE permissions entail READ permissions, the inverse is not true.

Only anonymous data will be stored in the system. This means that no information which directly links to a patient identity will be stored. In the case of clinical studies the treating physician is owner of patient data and will hold the key which links anonymous to patient data. The project leader, in charge of the investigation, will enter data into the system and responsible for sharing parts, with other groups or persons.

Data can also indirectly lead to a person’s identity. It’s not clear which impact this has on the requirements of the system. Communication with the database will be SSH/SSL/HTTPS encrypted.

s 24/7 support needed? Not known, but unlikely. Is there trust in external web services? What part of the data will be stored by the web service provider? Best would be to use only web services that are insourced. The project can learn from Parelsnoer. They share very little data for these reasons.

The following consequences of a breach of security will have to be discussed in more detail 1. Loss or corruption of data Backups will have to be provided. Currently there seems to be no need for a mirror system. 2. Disclosure of secrets or sensitive information 3. Disclosure of privileged/privacy information about individuals 4. Corruption of software or introduction of malware, such as viruses 5. The need for the following types of security has to be discussed. 1. Physical security. Where to host the NMC datawarehouse? 2. Access by user role or types. 3. State access control requirements by data attribute. For example, one group of users has permission to view an attribute but not update it while another group of users has permissions to update or view it. 4. State access requirements based on system function. For example, if there is a need to grant access to certain system functions to one group of users, but not to another. For example, "The system shall make Function X available to the System Administrator only". 5. State if there is a need for certification and accreditation of the security measures adopted for this application

The authentication scheme implemented should be able to differentiate between individual users, research groups and companies, and should facilitate separation of concerns within a study.

Technical implementation

Since the NMC DSP is dependent on the GSCF for study meta data security concerns have to be addressed by both systems. The idea is to come up with a single sign-on (SSO) solution, in which the GSCF is leading.

A user of the NMC DSP will first log in to the NMC DSP. The NMCDSP will then make calls on the GSCF on behalf of the user. This is called delegation.

There most feasible option seems to implement a protocol that is used by flickr. See here for full details. Below this scenario is repeated for the NMCDSP and GSCF case.

Delegation solution

The GSCF will have an authentication module which is leading for the DSP and all other modules. Any moduke wishing to use the GSCF authentication api must have already obtained a GSCF API key. In addition, they must configure the following settings, attached to the API key:

   * Application title
   * Application description
   * Application logo graphic (max 600x300, recommended 300x90) (Optional)
   * Application 'about' URL (Optional) 

A 'shared secret' for the api key is then issued by the GSCF. This secret is used in the signing process, described below. For web based authentication, the developer must register a 'callback URL' for the application.

When the DSP needs to authenticate a user, it should redirect the user to the following URL:


perms is a desired level of permission for actions which the application wants to perform on behalf of the user. api_sig is a signature.

If the user is not currently logged in to the GSCF, they are first asked to do so.

The GSCF then asks the user if they wish to authenticate against the DSP. The DSP and description are displayed, along with a description of permissions the application wishes to have. The user can then choose to grant all or none of the requested permissions. If the user grants the permssions, then they are redirected back to the DSP using the callback url previously registered for the used API key. The callback url will have the following appended:


The DSP should then call the API method gscf.auth.getToken, passing along their api key and the passed frob, and signed with their shared secret. The response then includes an authentication token for use in future API calls, along with the granted permissions.

Authentication tokens

Each authentication token is specific to a user and the DSP api key, and can only be used with that key. The DSP can check the status of an auth token by calling the API method gscf.auth.checkToken, which will return the validity of the token, along with the user it authenticates and the premissions it is granted.

((Authentication tokens can be set to expire by the user when they authenticate against the DSP. This is an advanced feature, hidden by default. Options are 1 hour and never. This may be set for different modules of the GSCF by policy in the future.))

Only one authentication token per application per user will be valid at any one time. Applications must deal with expired and invalid authentication tokens and know how to renew them.

All API calls using an authentication token must be signed.


All API calls using an authentication token must be signed. In addition, calls to the gscf.auth.* methods and redirections to the auth page on flickr must also be signed.

The process of signing is as follows.

  • Sort your argument list into alphabetical order based on the parameter name.
  • e.g. foo=1, bar=2, baz=3 sorts to bar=2, baz=3, foo=1
  • concatenate the shared secret and argument name-value pairs
  • e.g. SECRETbar2baz3foo1
  • calculate the md5() hash of this string
  • append this value to the argument list with the name api_sig, in hexidecimal string form
  • e.g. api_sig=1f3870be274f6c49b3e31a0c6728957f


An application should never request more permissions than it needs to operate. The permissions field is a string, representing the permission level. Each level implies the level below it. Possible permissions are:

  • read - permission to read private information
  • write - permission to add, edit and delete photo metadata (includes 'read')
  • delete - permission to delete photos (includes 'write' and 'read')

For example, the permission w allows an application to read and write on behalf of the user.

Example session

Web based app

Our web based app has the api key '1234567890'. It has already registered a callback url for this key - 'http://viewr.com/auth.php'.

* The application makes a background request to the gscf.people.getInfo to return information about the user, by calling http://gscf.nl/services/rest/?method=flickr.people.getInfo&api_key=1234567890&auth_token=334455&api_sig=4f3870be274f6c49b3e31a0c6728957f.

Implementation details

To renew an authentication token, a web based app simply redirects the user to the GSCF auth url again. If the user is logged in to flickr and has already authenticated against this DSP with the requested permissions (or more permissions - so long as the requested subset has been granted) and the token hasn't expired then they are redirected straight back to the DSP with a frob pointing to the existing authentication token. If the token has expired or extra permissions are requested, the user is prompted as before for renewal.

Authentication cookies should only be stored for a single session.

Users must be provided with a 'logout' link.