You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description:
Recently we evaluated GDPR requirement(right to be forgotten) for API Manager 3.0.0 development. Our primary focus was to find a way to implement "right to be forgotten" without effecting core logic of the system(with minimum changes). Following is the design we came up. We will be able to utilize same design for other products(who used same development methodology) as well. In API Manager 3.0.0 we do have set of MSF4J based micro services. Then ReactJS based apps developed on top of these APIs. Micro services directly call API publisher, store and admin implementations(via APIs). So what we did was intercept each API call and change user name to pseudo name.
To do this we have utility functions which maps real user to pseudo users and vise versa. It works like this.If pseudo name/username available in map then get mapping and return mapped value.
Else check mapping in database and load it to local map. Then return mapped value.
If mapping is not in database then add it to db and map. Then return mapped value.
And if we need to disable GDPR support due to some reason then above mentioned utility methods can return same attribute passed. Then it will not change anything and real user name will be used inside implementation. #5043
Description:
Recently we evaluated GDPR requirement(right to be forgotten) for API Manager 3.0.0 development. Our primary focus was to find a way to implement "right to be forgotten" without effecting core logic of the system(with minimum changes). Following is the design we came up. We will be able to utilize same design for other products(who used same development methodology) as well. In API Manager 3.0.0 we do have set of MSF4J based micro services. Then ReactJS based apps developed on top of these APIs. Micro services directly call API publisher, store and admin implementations(via APIs). So what we did was intercept each API call and change user name to pseudo name.
To do this we have utility functions which maps real user to pseudo users and vise versa. It works like this.If pseudo name/username available in map then get mapping and return mapped value.
Else check mapping in database and load it to local map. Then return mapped value.
If mapping is not in database then add it to db and map. Then return mapped value.
And if we need to disable GDPR support due to some reason then above mentioned utility methods can return same attribute passed. Then it will not change anything and real user name will be used inside implementation.
#5043
https://docs.google.com/document/d/1hyM99JFaUNaywIRVwplOX8oFdJ2s5l7L_OzWmxDMiDo/edit?usp=sharing
Suggested Labels:
Suggested Assignees:
Affected Product Version:
OS, DB, other environments details and versions:
Steps to reproduce:
Related Issues:
The text was updated successfully, but these errors were encountered: