Cookies policy

We use cookies to deliver a better experience. By using our website, you agree to use cookies in accordance with our privacy policy.

We use cookies to deliver a better experience. By using our website, you agree to use cookies in accordance with our privacy policy.

ACCEPT

Getting Ready For GDPR - Securing User Profiles on AEM

AEM’s Secure Profiles ensure that consumer data remains safe and secure, with GDPR just around the corner.

The EU’s General Data Protection Regulation (GDPR) is now only a few days away from coming into force. An administrative law designed to unify data protection throughout the EU, GDPR has made organizations across the continent (and beyond) rethink their processes in order to ensure that they are prepared.  

 

The new legislation requires companies to implement reasonable data protection measures to protect consumers’ personal data against loss and exposure. In an era of increasing consumer awareness of their online profiles, GDPR is very timely in that it provides consumers with more power over exactly what happens to their data once they hand it over to brands online.

 

At Netcentric, we’ve been aware of GDPR for a long time and have been working hard behind-the-scenes to ensure that we are ready for the changes it will bring. When it comes to AEM  stack of technologies, there are some particular changes in regard to user personal data that are worth exploring in further detail.

Migrating user data from AEM to secure storage

One of the approaches of reflecting the GDPR requirements is transferring all user personal data to a secure storage outside of AEM. A secure system, used for storing user personal data, differs depending on the particular project architecture. What remains is migrating the CID (client identifying data) as well as the user profile outside of AEM.

Custom Authentication

Taking a deeper look into the AEM architecture, the following specificity should be considered. There are two core mechanisms which will be affected by implementing this approach: authentication and authorisation.

 

Authentication - it’s a mechanism to recognise who is the user and that this individual is who he or she claims to be.

Authorisation - process of giving access to system objects based on the user identity.

 

With the approach of transferring all user personal data outside of AEM, it’s definitely needed to implement a custom authentication, which should authenticate the user against the secure system. But at the same time, we want to use the OOTB (out of the box) AEM authorisation mechanism.

 

The approach to achieve this is to have for each real-world client, a corresponding standard AEM user, without any sensitive data but only with the technical, not identifying userID.

 

When a user logs in, AEM authenticates him in the secure system via the custom authentication mechanism. As a response, the secure system provides a technical user ID (which doesn’t identify the user) and this is used to create a standard AEM user needed to perform the OOTB authorisation mechanism.

 

Essentially, the technical ID provides the possibility of creating a one-to-one relationship between the AEM user, not having any sensitive data, and the secure system user, which contains all the user’s personal information. This structure maintains a solid layer of security whilst also allowing to request the specific data, as for example, a list of CUGs (closed user groups), which the user should be assigned to.

Custom Resource Provider

As already mentioned, the user personal data consists of two parts: a CID (client identifying data) and a user profile. We have just discussed the challenge of transferring the CID to a secure system. The second part is moving the user profile outside of AEM.

 

The approach which allows to reuse the maximum possible of the application layer logic without customising existing components is creating a custom resource provider. This mechanism provides a possibility to customise the logic deeper on the Sling layer.

 

The custom resource provider mechanism is a very powerful instrument. The one specificity which should be taking into account is that it works on the Sling layer.

 

The idea is to catch all requests coming to user profiles resources and instead of getting the data from the JCR, request it from the secure system. By creating the logic in a one single place, this approach covers all the functionality, which relies on the user profile data.

Conclusions

Using a secure system for migrating all the user personal data is one of the approaches that enables companies to protect user data using AEM in a way that’s GDPR-compliant and secure.

 

It provides the corresponding functionality of storing and processing the user personal data, and ultimately ensures meeting all the requirements of the GDPR.



Olena Slyshkova

Senior Back-end Software Engineer