Hi Nuwan, Looks like there are several places we are using usernames as it is. Eg: provider, business owner, technical owner names in API table, CREATED_BY, UPDATED_BY audit columns in all the resource tables. There can be several other places. We need to fix those places to use UUIDs. I guess we can use this UUID itself as the pseudo name.
When SCIM comes into place, we will be getting a UUID for each user. We should be able to store it instead of the username in above places. But not sure whether we need to (persist/keep in memory in a map) username - UUID mapping in APIM side too, otherwise we need to give SCIM call to get the real username when needed all the time. On Fri, Feb 2, 2018 at 8:55 AM, Nuwan Dias <[email protected]> wrote: > Hi Sanjeewa, > > Can you post a chunk of code that benefits from this mapping in relation > to GDPR compliance? Basically I want to understand how a chunk of code that > wasn't GDPR compliant before becomes GDPR compliant due to this mapping. > > I was under the impression that APIM v3.0 works on user ids and not on > user names. User names are only used in responses, UIs, for calling other > services, etc. Which means that this user id is anyway a pseudo name. The > reason for this decision was to address a set of problems in C4 products > such as inability to change a username, problems with the same user in > different cases, etc. Meaning that APIM v3 was already GDPR compliant in > that sense. It we now have to build an addition layer to make the code GDPR > compliant, we've basically lost our design objective of using user ids > instead of usernames. > > Thanks, > NuwanD. > > On Thu, Feb 1, 2018 at 6:05 PM, Sanjeewa Malalgoda <[email protected]> > wrote: > >> Hi All, >> 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. >> >> So as you can see in below image, API Manager implementation(boundary >> marked with green dash line) works only with pseudo name. Whenever it >> communicates with API layer or any other external system(two boxes >> connected to green box) we will change pseudo name to real user name. I >> have done a quick test with this implementation and now everything(logs, db >> entries, files etc) getting recorded with pseudo name. So whenever we need >> to delete user we just have to delete user and remove mapping. Our plan is >> to do same for light weight auth framework as well. >> >> >> >> >> I would like to know others opinion on this before move forward. >> >> Thanks, >> sanjeewa. >> -- >> >> *Sanjeewa Malalgoda* >> WSO2 Inc. >> Mobile : +94713068779 <+94%2071%20306%208779> >> >> <http://sanjeewamalalgoda.blogspot.com/>blog >> :http://sanjeewamalalgoda.blogspot.com/ >> <http://sanjeewamalalgoda.blogspot.com/> >> >> >> > > > -- > Nuwan Dias > > Software Architect - WSO2, Inc. http://wso2.com > email : [email protected] > Phone : +94 777 775 729 <+94%2077%20777%205729> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Malintha Amarasinghe *WSO2, Inc. - lean | enterprise | middleware* http://wso2.com/ Mobile : +94 712383306 <+94%2071%20238%203306>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
