Hi Sanjeewa, On Tue, Feb 6, 2018 at 12:33 PM, Sanjeewa Malalgoda <[email protected]> wrote:
> > > On Mon, Feb 5, 2018 at 11:29 PM, Ishara Karunarathna <[email protected]> > 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 <[email protected]> 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 <[email protected]> >>> 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 < >>>> [email protected]> 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 <[email protected]> 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 <[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/> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Nuwan Dias >>>>>> >>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>> email : [email protected] >>>>>> Phone : +94 777 775 729 <+94%2077%20777%205729> >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> 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 >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Nuwan Dias >>> >>> Software Architect - WSO2, Inc. http://wso2.com >>> email : [email protected] >>> Phone : +94 777 775 729 <+94%2077%20777%205729> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Ishara Karunarathna >> Technical Lead >> WSO2 Inc. - lean . enterprise . middleware | wso2.com >> >> email: [email protected], 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: [email protected], blog: isharaaruna.blogspot.com, mobile: +94717996791
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
