GDPR-Ready Microservices Framework

The General Data Protection Regulation (GDPR), in Article 25, addresses data protection by design as a legal obligation for data controllers and processors. This requirement is particularly important for architects and developers implementing programs collecting such data.

GDPR Compliant Microservices

Cricket Microservices Platform offers a specific set of features that programmers can use to provide GDPR compliance:

• Secure communication

• User database encryption (both: operational and backup)

• API request authentication

• Access rights

• Two-phase confirmation

• "Forget me" implementation

• Data access log

• Data export

Secure Communication

Communication encryption is usually delegated to a separate service (e.g. NGINX, Apache httpd), but the embedded HTTP server also supports SSL. Thanks to this, we can immediately start our microservice protected by the default, self-signed certificate.

Database Encryption

User data is stored in the separate database so we can connect to an external, encrypted one. We can use the embedded H2 database as well, which uses the AES-128 encryption algorithm to protect the database and the backup files.

API Request Authentication

All API requests, except user registering and logging, require access tokens. Tokens have a configurable expiration time and are managed by the dedicated adapter exposing the REST API.

Access Rights

Personal data is only available to the user and administrators, so standard data is protected by default.

Each request in the authentication process is given an additional header identifying the user. We can use this to design our own API to check each request for compliance with the authorization policy.

Two-Phase Confirmation

To register a user with the REST API, two steps are required:

1. Create a user account.

2. Modification of the account by changing the "confirmed" parameter.

This allows us to comply with the requirement of informed consent to the storage of personal data.
The internal scheduler will help us automatically delete unconfirmed accounts.

"Forget Me" Implementation

Right to erasure, addressed in Article 17, requires an administrator to erase personal data without undue delay, in strictly defined cases.

The user's ability to delete his own data is implemented by default. Other cases must be implemented depending on the characteristics of the implemented service. Designing of appropriate procedures will be facilitated by the platform's architecture, including the event system.

Data Access Log

Cricket uses a special event category fired by used data activities (CRUD). These events, along with the dedicated logger adapter, are used to create anonymized data access log files. These elements can also be used to implement a specific, extended logging policy.

Data Export

User data can be exported as a file in JSON format using the REST API. Logged in users can do this at any time without administrator assistance.

Use Cases

The method of registering a user and accessing data using the REST API of a site built using the Cricket Microservices Framework can be traced on the following examples. We will use for this purpose a microservice operating locally on port 8080 and a cURL program as a REST API client.

If we already have Docker installed, it is easiest to use a ready-made container with the "Microsite" service of the Cricket platform.

$ docker run -p 127.0.0.1:8080:8080 gskorupa/cricket-microsite:latest

Having the service up and running, we can start testing.

1. We generate a session token for the admin user

$ echo admin:cricket|base64
YWRtaW46Y3JpY2tldAo=

$ curl -k -H "Authentication: Basic YWRtaW46Y3JpY2tldAo=" -H "Accept: text/plain" -X POST "http://localhost:8080/api/auth"
YWRtaW46MTUyNTQ3MTg0MDQzMA==

2. We register the user with the name/login user1.

$ curl -H "Accept: text/plain" -d "uid=user1&email=myname@myserver&password=mypassword" http://localhost:8080/api/user
user1

3. The administrator has access to the data of each user. By using our token, we can download user data.

$ curl -k -H "Authentication: YWRtaW46MTUyNTQ3MTg0MDQzMA==" http://localhost:8080/api/user/user1
{
  "type":0,
  "uid":"user1",
  "email":"myname@myserver",
  "role":"",
  "confirmed":false,
  "unregisterRequested":false,
  "confirmString":"LTE1NDY3NzU5Mzg0NTg0NzI4MjM",
  "password":"34819d7beeabb9260a5c854bc85b3e44",
  "authStatus":0,
  "createdAt":1525472221682,
  "number":4
}

4. A registered user does not have access to the system (they cannot download the session token) until they confirm the registration (users consent to the processing of personal data).

$ echo user1:mypassword|base64
dXNlcjE6bXlwYXNzd29yZAo=

$ curl -k -H "Authentication: Basic dXNlcjE6bXlwYXNzd29yZAo=" -H "Accept: text/plain" -X POST "http://localhost:8080/api/auth"
authorization required

5. The administrator can confirm the user's agreement to the processing of personal data (we assume that the admin obtained such consent).

$ curl -k -H "Authentication: YWRtaW46MTUyNTQ3MTg0MDQzMA==" -X PUT -d "confirmed=true" http://localhost:8080/api/user/user1
{
  "type":0,
  "uid":"user1",
  "email":"myname@myserver",
  "role":"",
  "confirmed":true,
  "unregisterRequested":false,
  "confirmString":"LTE1NDY3NzU5Mzg0NTg0NzI4MjM",
  "password":"34819d7beeabb9260a5c854bc85b3e44",
  "authStatus":1,
  "createdAt":1525472221682,
  "number":4
}

6. After confirming the registration, the user can log in, get a session token, and then download his data.

$ curl -k -H "Authentication: Basic dXNlcjE6bXlwYXNzd29yZAo=" -H "Accept: text/plain" -X POST "http://localhost:8080/api/auth"
dXNlcjE6MTUyNTQ3MjUzMTIwMQ==

$ curl -k -H "Authentication: dXNlcjE6MTUyNTQ3MjUzMTIwMQ==" http://localhost:8080/api/user/user1
{
  "type":0,
  "uid":"user1",
  "email":"myname@myserver",
  "role":"",
  "confirmed":true,
  "unregisterRequested":false,
  "confirmString":"LTE1NDY3NzU5Mzg0NTg0NzI4MjM",
  "password":"34819d7beeabb9260a5c854bc85b3e44",
  "authStatus":1,
  "createdAt":1525472221682,
  "number":4
}

7. However, attempts to download another user's data will fail.

$ curl -i -H "Authentication: dXNlcjE6MTUyNTQ3MjUzMTIwMQ==" http://localhost:8080/api/user/admin
HTTP/1.1 403 Forbidden
Access-control-allow-headers: Authentication
Pragma: no-cache
Access-control-max-age: 1728000
Date: Fri, 04 May 2018 22:25:46 GMT
Access-control-allow-methods: POST, GET, OPTIONS, DELETE, PUT
Last-modified: Fri, 4 May 2018 22:25:46 UTC
Content-type: application/json; charset=UTF-8
Access-control-allow-origin: *
Access-control-allow-credentials: true
Content-length: 6

null