How to do identity de-provisioning in a right way with WSO2 Identity Server – adhering to GDPR?

What is identity deprovisioning?

All things must come to an end. This proverb pertains to our lives and everything that we do, also in the digital world. You might be a customer of a web shop, sign up for an account with them and order from them. At one point, for whatever reason, you might stop ordering from them. It really does not matter why you stop ordering. Well, it does to the web shop, because they want to keep you as a client but for you if you do not want to be a customer anymore that is a fact. And the web shop should facilitate leaving. This is call identity deprovisioning, and it is not optional, it is mandated.

In legal terms identity de-provisioning is a right of a user under Article 17 of GDPR – Right to be forgotten. Hence it is essential for a digital platform to implement de-provisioning to its user’s as per regulations specially in EU region or when you handle data of EU citizens.

There are multiple ways that deprovisioning could happen on a digital platform.

1. Identities or users could self-deactivate/suspend their user account – This way of deprovisioning is temporary disabling the account and the user can activate the account whenever he wants. Eg: Facebook is providing this facility to temporary deactivate their account, so their accounts will not be discoverable till he/she activates back.
2. Identities or users could self-delete their account – This way of deprovisioning is permanent and user will not have their identity in that space available after the deletion. If he/she wants to come back, they have to self-register again or go through the on-boarding process again as previous.
3. Administrator of the platform can delete or temporary disable a user account – This should be available in a platform as a must in an emergency or to act upon a user request.
4. Automatic deletion of idle user accounts for a long time – Every platform has its inactive users and active users. Inactive users could be occasional or rarely using your platform as trial users or test users, hence there should be a way to clean up these trial or test users to remove stale data and secure resources.

Why a proper deprovisioning is important to an IDM system?

Many studies prove that if you can provide a seamless deprovisioning procedure through your platform, there is chance that your customers will come back to you, because they appreciate your start to end process – Carbone, L.P. and Haeckel, S.H., 1994. Engineering customer experiences. Marketing management, 3(3), pp.8-19 . Hence, is a MUST need feature for any CIAM solution to provide standard de-provisioning capabilities adhering to the laws provided by the legal bodies. Failing to offer the de-provisioning is not only going against regulations, but also bad for business.

Although you might want to keep data about inactive users (they might want to come back as a customer), it is better to offer seamless de-provisioning.

There are numerous advantages of having a proper de-provisioning mechanism:

• Save Time and Money – Having a proper method of de-provisioning adhering to GDPR will save time and money of both consumers as well as platform owners, because it reduces data breaches and lawsuits that must undergo if data is exposed after the identity left the platform.
• Save resources and storage – Keeping idle or disabled user accounts for a long time in the platform is a waste of resources. Extra storage must be allocated for this user accounts and this also affect the performance of the search operations in the platform. Hence having an automated way of removing these accounts is a best way to save resources to save money.
• Improve user experience of the platform – Having multiple ways of deprovisioning methods shows users that the system is mature and concerning more about the consumers and provide what is best for them.
• Reduce unnecessary data exposures – As per GDPR only adequate data should be exposed outside under user’s consent. Hence removing inactive users after a notification is the most appropriate way of securing others’ privacy who registered in your platform.

Other than above advantages, an IDM solution should always adhere to data protection regulations such as GDPR.

What are the GDPR regulations related to De-provisioning?

There are two articles in General Data Protection Law, that needs to be considered when you introduce a de -provisioning platform to your platform in your organizations. Please find them in detail below –

• Art.  17 – Right to erasure.

 When giving the consent to a platform application to use his/her user data, he/she must have a right to ask for a data deletion in several conditions as per this article.

It is a MUST for a platform to delete all user’s tracers if he requests under a data breach or privacy violation when needed.

As per GDPR, platforms like health care should adhere to this article when processing special categories of data e.g.: health care data.

• Art. 19 – Notification obligation regarding rectification or erasure of personal data or restriction of processing

As a platform who is collecting personal data is obliged to notify before a deletion of personal data for the relevant data subject or user regarding the following:

• The reason for the deletion
• What data will be deleted?
• What data will remain in the system?
• When is the data deletion happened?
• Steps to follow to object the data deletion

In summary, this emphasize that identities as individuals have the right to demand to delete his/her user accounts and personal data and these data should be deleted from everywhere including in logs and other database resources. Also, if it is an automatic deletion, the platform must inform or notify the users before the account deletion and provide precautions to stop the deletion if needed.

Implementing the right de-provisioning process is a must.

How to achieve de-provisioning with WSO2 Identity Server?

So how can you enable de-provisioning on the WSO2 Identity Server?

Let us first look at what SCIM offers. SCIM is an acronym for System for Cross-Domain Identity Management, and it is included with the Identity Server, and it can be used to manage identities in Identity Server,

a) Identities or users could self-deactivate/suspend their user account.

The self-deactivate and self-suspension of user account can be implemented by using existing account disabling by updating an identity claim called http://wso2.org/claims/identity/accountDisabled.

Updating this user claim/attribute via SCIM2 API will disable the account in WSO2 Identity Server.

As per GDPR we should notify the user after account disabling. You can enable internal notification by default to send an email to the user to inform that account is disabled.

b) Identities or users could self-delete their user account.

WSO2 Identity Server is a CIAM solution will provide full Identity life cycle management capacities. WSO2 Identity Server is provide SCIM2/Me endpoint with delete functionality to DELETE ME.

DELETE     /scim2/Me

DELETE https://localhost:9443/t/{tenant-domain}/scim2/Me

This API is used to delete the currently authenticated user. It returns HTTP 204 if the user is successfully deleted.

Sample Request

curl -v -k –user  [username]:[password] -X DELETE https://localhost:9443/scim2/Me

It is a MUST to send a notification after deleting the user account. You can send this email by triggering an email notification via userstore listeners – postDeleteUser(). This will be a customization, that you must do based on your requirement.

c) Admin User account disabling and deletion.

As an Administrator, he has the capability to disable user or delete a user from the system when required.

For disabling users, WSO2 Identity Server provide an out of the box feature to enable. With this any admin user can disable a user account when required. By updating the attribute http://wso2.org/claims/identity/accountDisabled via SCIM2 API provided by WSO2 Identity Server

For deletion of user accounts, WSO2 Identity Server provide multiple options:

• Using Management/Admin console to delete users.

• Using SCIM2/Users rest API to delete users.

Sample request: 

curl -v -k --user {IS_USERNAME}:{IS_PASSWORD} -X DELETE https://{IS_IP}:{IS_PORT}/wso2/scim/Users/{SCIM_USER_ID} -H “Accept: application/json”

• Using SOAP Admin Service to Delete users.

Sample request:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:ser="http://service.ws.um.carbon.wso2.org">
   <soap:Header/>
   <soap:Body>
      <ser:deleteUser>
         <!--Optional:-->
         <ser:userName>nila@wso2support.com</ser:userName>
      </ser:deleteUser>
   </soap:Body>
</soap:Envelope>

It is important to delete the user account and notify the user after account deletion as previously discussed.

d) Automatic Deletion of Idle user accounts

This requirement varies from organization to organization. Hence this should be catered via customization using existing features of WSO2 Identity Server and its APIs. Please find the sequence diagram of how a standard automation deletion process should be.

To achieve the requirement, you can use couple of features in WSO2 Identity Server and cater this requirement.

• WSO2 Identity Server 6.1.0 has an out of the box feature to lock user accounts which are idle for a configured period. Moreover, it allows to send automatic notification before the account locking.

• After disabling, if you required to delete the user account, you must follow the similar flow via a customization.

e) Removing the outbound provisioned users

With CIAM 2.0 we need to integrate your identity server with other third-party systems. Then you have to outbound provision some of the users that created in WSO2 Identity Server system to other third-party systems.

For this you must use out of the box provided Outbound Provisioning connectors or Custom Outbound Provisioning connectors. Out of the box connectors support creation, update, and deletion. Hence, when you create your own connectors, make sure to support all the possibilities.

f) Forget me option

WSO2 Identity Server has introduced a tool called ‘forget me’ tool, which you can run on deleted users to delete other information and references related to these users in logs and session stores. This is necessary to adhere to the GDPR as it required to remove all the references of the deleted Users.

As per WSO2, this tool is designed to replace all occurrences of a deleted user’s identity with either a randomly generated UUID value, or a pseudonym that you specify when you run the tool. Therefore, running the tool does not mean that all data related to a deleted user is completely removed from the WSO2 Identity Server. What actually happens is that the same pseudonym replaces each record that belongs to a deleted user in order to preserves the connection integrity of user records. Hence, even after removing all references to a deleted user’s identity, the system administrator is able to track all events performed by a particular user without having any reference to the user’s identity.

This tool is an external resource provided by WSO2, therefore this is available to download and use it according to your requirements.

Summary

Identity deprovisioning is not only one of the most important components of the identity life cycle management, but also required by law. (Which should adhere to GDPR). When implemented in the right way, it not only minimizes the number of manual tasks associated with it, but it can also actually work to your benefit as an organization because users appreciate a seamless process to de-provision and might even think favorably about your organization and if they wanted to come back. WSO2 Identity Server is a leading CIAM solution (recognized by Gartner and KuppingerCole) that can provide de-provisioning capabilities to in cooperate to your CIAM solution to achieve a proper de-provisioning of identities.