DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
  1. DZone
  2. Data Engineering
  3. Data
  4. GDPR-Ready Microservices Framework

GDPR-Ready Microservices Framework

In this post, we take a look a how developers can use a microservices framework to create GDPR complaint applications that ensure data security.

Grzegorz Skorupa user avatar by
Grzegorz Skorupa
·
May. 08, 18 · Analysis
Like (5)
Save
Tweet
Share
5.98K Views

Join the DZone community and get the full member experience.

Join For Free

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
microservice Data (computing) Framework

Published at DZone with permission of Grzegorz Skorupa. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Introduction to Spring Cloud Kubernetes
  • OpenVPN With Radius and Multi-Factor Authentication
  • Getting a Private SSL Certificate Free of Cost
  • How To Build a Spring Boot GraalVM Image

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: