Hi Maduranga, Idea of this user id is to decouple the username from where it is used inside the system. So in an event of user removal, user id will not give an actual meaning. So this user id is internal to the system and we are not going to use it out side the system.
Thanks! *Jayanga Kaushalya* Senior Software Engineer Mobile: +94777860160 WSO2 Inc. | http://wso2.com lean.enterprise.middleware On Mon, Jan 22, 2018 at 5:37 PM, Maduranga Siriwardena <[email protected]> wrote: > Hi Jayanga, > > Now as we are maintaining a userId in our system, shall we use the same as > the id in the SCIM requests/responses also, rather than maintaining a > separate identifier for SCIM? > > Thanks, > Maduranga. > > On Thu, Jan 18, 2018 at 7:59 PM, Jayanga Kaushalya <[email protected]> > wrote: > >> On Tue, Jan 16, 2018 at 2:45 PM, Asela Pathberiya <[email protected]> wrote: >> >>> >>> >>> On Fri, Jan 5, 2018 at 5:50 PM, Jayanga Kaushalya <[email protected]> >>> wrote: >>> >>>> Hi all, >>>> >>>> According to the GDPR act [1] Chapter 3, Section 3, Article 17 (Right >>>> to erasure) the data subject has the authority to request the erasure of >>>> the data from controller. And the controller has the authority to erase the >>>> data according to the conditions given in the Article 17. And in an event >>>> of erasure request, it should perform the action without giving an extreme >>>> delay and erase all of the relevant information. >>>> >>>> In the current implementation, some of the user information (Ex: >>>> username) scattered around multiple locations and it is technically hard to >>>> clear all of the data from a single action without giving a significant >>>> delay. For an example there are instances username is printed in logs and >>>> it is technically difficult to erase those instances from logs. >>>> >>>> *Solution - Introducing Pseudonyms for Username* >>>> >>>> By introducing a pseudonym for username we can limit the usage of >>>> actual username throughout the system. By doing this erasure of actual >>>> username will remove the underlying value represented by the pseudonym >>>> attached to it. Hence it'll make the removal of user information from all >>>> of the related locations technically feasible. There are two main >>>> approaches to implement the pseudonyms for username which are below >>>> described. >>>> >>>> *Approach 1 * >>>> >>>> Keep the core implementation to work with usernames and change all of >>>> the output locations to convert username to relevant pseudonym and output. >>>> >>>> *Approach 2* >>>> >>>> Change the core implementation to work with pseudonym and change the >>>> places where the user friendly username is required. >>>> >>>> *Preferred Approach* >>>> >>>> Approach number 2 is selected as the best approach since all of the >>>> internal usages will be change to use the pseudonym and in a event of >>>> failure pseudonym will be displayed instead of the actual username which >>>> will guaranty the compliance. >>>> >>> >>> >>> It seems to be that approach 2 would add some more advantages such as >>> implementing the usename renaming. But we need to more careful with the >>> design as interfaces may be needed to modify. >>> >>> Are we storing the pseudonyms vs username in somewhere ? internal store >>> or user store ? >>> >> >> Since the pseudonym is introduced from Identity Server side and we have >> to consider about read only user stores, we are keeping the mapping on a >> Identity Server side. Not on the user stores. >> >>> >>> When it comes to username. Does it consider as user store domain + >>> user store username + tenant domain or just user store username ? >>> >> >> Username will be just user store user name. But the pseudonym will be >> unique to user store domain + username + tenant domain. >> >>> >>> >>>> >>>> [1] http://data.consilium.europa.eu/doc/document/ST-5419-2016-IN >>>> IT/en/pdf >>>> >>>> Thanks! >>>> >>>> *Jayanga Kaushalya* >>>> Senior Software Engineer >>>> Mobile: +94777860160 <+94%2077%20786%200160> >>>> WSO2 Inc. | http://wso2.com >>>> lean.enterprise.middleware >>>> >>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Thanks & Regards, >>> Asela >>> >>> ATL >>> Mobile : +94 777 625 933 <+94%2077%20762%205933> >>> +358 449 228 979 >>> >>> http://soasecurity.org/ >>> http://xacmlinfo.org/ >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Maduranga Siriwardena > Senior Software Engineer > WSO2 Inc; http://wso2.com/ > > Email: [email protected] > Mobile: +94718990591 <+94%2071%20899%200591> > Blog: *https://madurangasiriwardena.wordpress.com/ > <https://madurangasiriwardena.wordpress.com/>* > <http://wso2.com/signature> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
