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. > 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. > Yes that is very good suggestion. I think we should use pseudo name as harsha suggested. Ideally analytics throttling etc can consider as systems in APIM domain and they are really not external apps systems. In that case we can follow that. Regarding user delete operation we can implement caching layer to hold user to pseudo name map. Then it will automatically clear after sometime user delete. In GDPR specification also it was mentioned that we can tale sometime to complete data cleaning part. So i think we are good to go with node local cache. Thanks, sanjeewa. > > 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 <071%20182%202074> > -- *Sanjeewa Malalgoda* WSO2 Inc. Mobile : +94713068779 <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
