Hi Sanjeewa,

Do we have to remove the entries from the log files as well? even audit
logs?  does this mean we will remove from archived logs as well?  If so,
shouldn't this be a decision of the data controller? With this design, they
have no control over the logs only right?

On Fri, Feb 2, 2018 at 8:55 AM, Nuwan Dias <nuw...@wso2.com> 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 <sanje...@wso2.com>
> 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 : nuw...@wso2.com
> Phone : +94 777 775 729 <+94%2077%20777%205729>
> _______________________________________________
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Thanks and Regards
*,Shani Ranasinghe*
Senior Software Engineer
WSO2 Inc.; http://wso2.com

mobile: +94 77 2273555
Blog: http://waysandmeans.blogspot.com/
linked in: lk.linkedin.com/pub/shani-ranasinghe/34/111/ab
Architecture mailing list

Reply via email to