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 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
