Hi All,
We were able to implement above suggested solution for API Manager 3.0.0
and test user flows successfully. Also we did integrations with identity
server 5.4.0 as authenticate service to verify external system
communication part. If user resides outside product domain(in tested
scenarion IS 5.4.0) we have to delete user from identity server side and
remove internal mapping. We do not have any plan to expose this
functionality as a web service to outside due to security concerns. APIM
components will be able to communicate with this through java API and get
mappings.

Do you have any suggestion to implement mechanism to mapping removal?
Should we expose API or java method to do that? Or let database admin to
remove mapping from database?
Appreciate suggestions.

Thanks,
sanjeewa.

On Wed, Feb 7, 2018 at 3:06 PM, Ishara Karunarathna <isha...@wso2.com>
wrote:

> Hi Sanjeewa,
>
> On Tue, Feb 6, 2018 at 12:33 PM, Sanjeewa Malalgoda <sanje...@wso2.com>
> wrote:
>
>>
>>
>> On Mon, Feb 5, 2018 at 11:29 PM, Ishara Karunarathna <isha...@wso2.com>
>> wrote:
>>
>>> HI Sanjeewa,
>>>
>>> Pseudonym user ID (User ID) is not only limited to GDPR requirements
>>> but its really useful supporting features like changing userName, In C4 we
>>> do some workaround for this.
>>>
>>> I think this proposed approach is much similar to the pseudonym user ID
>>> implementation we did to support GDPR features in C4 based products. Where
>>> we have users in the system and later we introduce a mapping to those
>>> existing users. (Jayanga and Ruwan can add more on this).
>>>
>>> But IMO, I think in the new implementation we can provide first-class
>>> support for this. So we can create a user context with userID and
>>> displayName (Username), all the places we use the user ID, but when we
>>> display the users we can show the displayName or (username)
>>>
>> Yes we had discussion about subject and it was decided to use user pseudo
>> name in all places of the implementation. But whenever we need to show user
>> logged in name we will call user info or some other service and get display
>> name. That part will be handle from UI app and back end run time do not
>> need to worry about it. I think this implementation align with your
>> suggestion. Please let us know if you have any suggestion to above flow.
>>
> If this userID to display name conversion is not a frequest task this
> seems good
>
> Thanks,
> Ishara
>
>>
>> Thanks,
>> sanjeewa.
>>
>>>
>>> Thanks,
>>> Ishara
>>>
>>>
>>>
>>> On Fri, Feb 2, 2018 at 4:52 PM, Nuwan Dias <nuw...@wso2.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> When this is done up to some extent let's have a code review. I'm still
>>>> struggling to understand the difference between user_id and pseudo name.
>>>> And wondering whether we actually need a user_id concept if we implement
>>>> something based on a pseudo name or vice versa.
>>>>
>>>> Just to be clear on the GDPR expectations, processing data with
>>>> usernames in memory has absolutely no problem in terms of GDPR compliance.
>>>> The only problem occurs when/if we persist a username somewhere. So as long
>>>> as we don't log a username and don't write to a DB or file, we're good.
>>>> Since developers have access to the username at the development time, they
>>>> can still log it or write it to a DB or file anyway.
>>>>
>>>> @Shani, GDPR compliance rules apply over other rules. It's not intended
>>>> to override other organizational rules. So if a particular organization has
>>>> a policy to retain user data for 6 months and the user has consented to
>>>> that, the user only has the "right to be forgotten" after the 6 months has
>>>> passed. Until then the organization has the right to hold on to that data.
>>>>
>>>> Thanks,
>>>> NuwanD.
>>>>
>>>> On Fri, Feb 2, 2018 at 11:11 AM, Sanjeewa Malalgoda <sanje...@wso2.com>
>>>> wrote:
>>>>
>>>>> 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 <+94%2071%20306%208779>
>>>>>
>>>>> <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
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>>
>>>>
>>>
>>>
>>> --
>>> Ishara Karunarathna
>>> Technical Lead
>>> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>>>
>>> email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
>>> +94717996791 <071%20799%206791>
>>>
>>>
>>>
>>
>>
>> --
>>
>> *Sanjeewa Malalgoda*
>> WSO2 Inc.
>> Mobile : +94713068779 <+94%2071%20306%208779>
>>
>> <http://sanjeewamalalgoda.blogspot.com/>blog
>> :http://sanjeewamalalgoda.blogspot.com/
>> <http://sanjeewamalalgoda.blogspot.com/>
>>
>>
>>
>
>
> --
> Ishara Karunarathna
> Technical Lead
> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>
> email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
> +94717996791 <071%20799%206791>
>
>
>


-- 

*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

Reply via email to