On Thu, Feb 1, 2018 at 10:47 PM, Rukshan Premathunga <[email protected]> wrote:
> Hi Sanjeewa, > > Did we thought how this affect to the analytics and throttle data > publishing? For Throttle i think we can use the pseudo name right? > For analytics we can use pseudo name and do all the aggregation based on > pseudo > name. But when rendering UI, we can convert to real name using the map. > Yes we can do that. > Next option is we can send the real username to analyzer > without using pseudo name. Which will reduce the overhead and will reduce > username mapping. > I think it would be best to use pseudo name as it analytics or throttling engines logs particular incoming data which will contain the real username which is a violation of GDPR. > > Any thoughts? > > Thanks and Regards > > 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/> >> >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Rukshan Chathuranga. > Software Engineer. > WSO2, Inc. > +94711822074 <+94%2071%20182%202074> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Harsha Kumara Software Engineer, WSO2 Inc. Mobile: +94775505618 Blog:harshcreationz.blogspot.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
