Skip to end of metadata
Go to start of metadata

Planned feature

This page describes a feature planned for future midPoint versions.

This feature is roughly designed and it was evaluated as feasible. However, there is currently no specific plan when it will be implemented because there is no funding for this development yet. In case that you are interested in supporting development of this feature, please consider activating midPoint Platform subscription.

Motivation

Identity management and governance is all about processing personal information. Processing data on employees, contractors, students and other identity types is the main focus of identity management and governance systems. Processing of such data were mostly governed by internal policies of the organizations that did the processing. The privacy legislation was not entirely strong, it was not consistent and it was often not strictly enforced. But that is very likely to change as soon as the General Data Protection Regulation (GDPR) becomes enforceable.

General Data Protection Regulation (GDPR)

The General Data Protection Regulation (Regulation (EU) 2016/679) is a regulation of European Commision aimed at strengthening the protection of data protection. GDPR intent is to give control back to people over their personal data. Its primary concerns are EU citizens and companies, but it also affects subjects that make business with European Union, that process data about EU citizens and so on. Therefore, this regulation is like to have a very broad world-wide impact. It becomes enforceable from 25 May 2018.

One of the fundamental implications of GDPR is that there must be a lawful basis for data processing. If there is no lawful basis, then personal information cannot be processed. The lawful basis may be an employee contract, business contract or other legitimate interest. Therefore, most organizations already have a lawful basis to process information about their employees, contractors and students. But what happens when an employee leaves? What happens when a contract expires? Also student population is changing every year. How are the data regarding those identities managed after the lawful basis for processing disappears?

This is much more complicated that it looks at the first sight. The lawful bases for processing may overlap. A single person can be both student and an employee of the same university. The same support engineer may be engaged in several support contracts with different scopes and expiration. Scientists from different organizations may cooperate on several scientific projects at once. We cannot simply delete the data when a specific lawful basis expires. We need to consider all the active lawful bases to properly manage the data. And to make things even more complicated, the lawful basis may be active even after the original contract expires. For example it is a common practice and even a legal requirement to maintain employee data for several years after the employee leaves. However, it may still be required to erase the data once that period is over if there is no other lawful basis for processing of that data.

There is also the right of individuals to request information about processing of their data. This is known as subject access request (SAR). GDPR gives data subjects (users) the right to request a very broad information about processing of their data. It is quite clear that the organization needs to know all lawful bases and their parameters to be able to efficiently respond to subject access requests. The GDPR also prohibits to charge any fee on subject access requests (unless they are manifestly unfounded or excessive). Therefore, the best strategy would be to automate most of the SAR data processing to keep the process as efficient as possible.

The big problem is that the current IT applications are not designed with the good data processing methods in mind. Vast majority of applications do not understand the concept of lawful basis. Some applications have a means to specify account expirations, but vast majority of the applications cannot handle several overlapping "bases" for the accounts. And even if there was such support in applications this has to be supported by each application separately in their own way. As a typical enterprise IT is composed of tens or even hundreds of applications the manual management of such data is very likely to be infeasible.

Fortunately there is a convenient solution. In fact the solution exists for years. We all know what that solution is: identity management and governance. The IDM systems can already reach to all the crucial applications and manage identity data. This is exactly what is needed to implement proper data protection methods. All that is needed is modification of the existing approach to provide proper user interfaces and additional mechanisms to support data protection mechanisms.

Regulation is not the only reason to implement good data protection mechanisms. There is a huge overlap of data protection and information security. Accounts that belong to former employees should be deprovisioned due to data protection regulation. But they should be deprovisioned also because of good security policies. Former employees definitely should not have the same access to company systems as they had while their employment contract was valid. Therefore, the implementation of data protection mechanisms and information security goes hand-in-hand. They have similar goals.

Lawful Bases for Data Processing

We propose to enhance midPoint to improve the support for lawful bases for data processing and thus support the GDPR compliance. However, as there is a significant overlap between data protection and information security midPoint already has a basic implementation of these mechanisms. We plan to reuse these existing midPoint mechanisms to support the methods required by GDPR. This includes:

  • New concept of data protection scope that can be used to model lawful bases for data processing.
  • Seamless integration with existing RBAC roles - as many existing lawful bases will have one-to-one correspondence with existing RBAC roles (such as "employee" role) or organizational units.
  • New user interface for data protection officers to easily determine and manage lawful bases for existing users.
  • Automated processing of overlapping lawful basis with various parameters and time validity.
  • Process for erasure and archival of identity data when the last active lawful basis for data processing disappears.

The management of lawful bases will be cleanly integrated to existing midPoint user interface - and in fact to the entire midPoint core as this is an extension of existing midPoint mechanisms (see below). The management of lawful bases will also be seamlessly integrated with the proposed consent management functionality as consent is just one of many possible lawful basis for information processing.

Implementation

Implementation will follow midPoint principle of reuse. The lawful basis for data processing will be modelled as an assignment. Target of that assignment will be data protection scope which will be modelled as special type of a role.

The protection scope will specify all the legal details about the lawful basis for processing. But being a role it can also define all the technical implementation details that the lawful basis implies: the target systems where the data will be managed, which properties are to be managed and so on. Therefore, both legal and technical side will be maintained in a single object, so it will be easy to keep them consistent.

The lawful basis is activated by creating an assignment to the role which represents the protection scope. When there is a lawful basis for processing of data of a specific user then such assignment is created. This will automatically trigger provisioning of all the accounts that are allowed by the lawful basis and proper set up of all the attributes. But most importantly this also works the other way. When the lawful basis expires then deprovisioning is automatically triggered. The data for which there is no other lawful basis will be removed, the accounts deleted or archived. Existing and well proven midPoint mechanisms will be used to execute such data management tasks.

By reusing existing mechanisms we are also enabling all the advanced features in a very natural way. For example lawful basis may be active only for a specific time period. For this we can reuse existing assignment validity constraints. The protection scopes may be hierarchical: one protection scope being subset of another protection scope. Role hierarchy can be reused to model this behavior. And so on.

There are many potential improvements of this mechanism for the future. For example assignment lifecycle can be used to model lawful bases that were based on an expired contracts and are currently in their "fade out" phase. Protection scopes and even individual assignments might be made to be part of certification campaigns. The protection scopes are very likely to evolve as the legislation evolves. Therefore the role lifecycle management may be used to manage the evolution of lawful bases as well.

See Also

 

  • No labels