Nuwan, All,
When we are calling with external systems such as scim we will use user ID.
But internal flow manly goes with user name. Each time when rest API get
hit with call we will call getUserName() method with http request and it
resolve user name. That particular user name passed all through system and
get recorded in databases, log files etc.
Whenever we call SCIM etc we get relevant user id by calling identity
provider and do following calls with user id. Still even with SCIM in place
user name is available all through implementation. Please see below code
which we use to interact with external identity provider. As you can see we
use id only when communicate with identity providers. So above suggested
implementation is a must.
String userId = getIdentityProvider().getIdOfUser(userName);
roles = new HashSet<>(getIdentityProvider().getRoleIdsOfUser(userId));
What i'm doing is call follwing method before we need actual user name. So
i had to place this line above code block.
So i can use pseudo name all over the implementation.
String userName =
APIUtils.getLoggedInUsernameFromPseudoName(user);
Thanks,
sanjeewa.
On Fri, Feb 2, 2018 at 10:07 AM, Malintha Amarasinghe <malint...@wso2.com>
wrote:
> 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 <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
>>
>>
>
>
> --
> Malintha Amarasinghe
> *WSO2, Inc. - lean | enterprise | middleware*
> http://wso2.com/
>
> Mobile : +94 712383306 <+94%2071%20238%203306>
>
--
*Sanjeewa Malalgoda*
WSO2 Inc.
Mobile : +94713068779
<http://sanjeewamalalgoda.blogspot.com/>blog
:http://sanjeewamalalgoda.blogspot.com/
<http://sanjeewamalalgoda.blogspot.com/>
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
