On Wed, Mar 1, 2017 at 6:44 PM, Johann Nallathamby <[email protected]> wrote:
> Hi Isura/Omindu, > > On Wed, Mar 1, 2017 at 5:23 AM, Omindu Rathnaweera <[email protected]> > wrote: > >> Hi All, >> >> For the user self sign-up feature in IS 6.0.0, we have a requirement to >> distinguish a self sign-up request from a normal user provisioning >> operation. >> >> In IS 6.0.0 currently, a user can self sign-up using one of the following >> 2 mechanisms. >> >> 1. Using self sign-up REST API. >> > > Why do we need to keep on supporting this if /Me has the same > functionality? I think we must not have this if we can do the same things > with /Me, with/without extensions to /Me (meaning additional params, > headers, etc. which SCIM2 doesn't stop us from doing). > > >> 2. Using SCIM provisioning endpoints (/Me, /User) >> >> The self sign-up operation will be achieved by the means of an event >> handler which will be triggered during PRE and POST addUser() operations. >> Therefore, for any user add operation call, the self sign-up event handler >> will be triggered and from the handler, we have to identify whether it is a >> self -sign-up request or not. >> > >> One possible way to achieve this is by sending a special claim along with >> the UserBean and from the self sign-up event handler we check for the >> mentioned claim before starting the self sign-up flow. >> >> Appreciate your thoughts on this. >> > > The primary reason we have a separate /Me endpoint for self-signup is to > avoid authentication. @Gayan: correct me if I am wrong. Otherwise at a > protocol level there aren't much differences between /Me "self-signup" API > and /Users "create" API. > Yes it is same. In /Me end point for unauthenticated requests, username will be taken from http request POST body. More importantly even though /Me end point can accept unauthenticated request we should have some kind of mechanism to protect /Me end point such as use oauth with client trust broker application. > > The reason why we needed to support self-signup flow using our addUser API > in IS 5.3.0 was because, we needed an API which is not open but protected > by some form of authentication/authorization that client applications can > invoke on behalf of the user. > > In that case why don't we give an option to secure the self-signup API > itself, which is very easy now if we have Ruwan's interceptor working, and > not allow self-signup flow using /Users endpoint? > > Now the second question is how do we identify the self-signup users once > they have been created. As I can see there are 3 ways of storing that > information. > 1. Claim > 2. Group (role is not correct here, we used role in IS 5.3.0 because we > didn't have groups) > 3. User metadata attribute > > Which one makes more sense? For me group makes more sense over claim, > because its important to identify the whole set of self-signup users as a > group, so that we can define additional attributes for the whole > "self-signup" group, which will be inherited by all the users in that > group. This will be important going forward, when we hit new use cases. > > Also it is much more efficient to search/list users by group rather than > by claim. I know that the initial addition may take a hit because we have > to do two OSGi calls, first to add the user and then to add him to the > group. But looking at the tradeoff I feel taking the initial hit and having > more performance for search and list is acceptable. > > May be we can even overcome that initial hit if we give a OSGi level API > to add users with the groups. Its not wrong to give an overloaded API at > the identity store level, because we don't violate the concept of resources > at that level like we might do if we do it at the SCIM2 level. > > I will let the others weigh in. > > Thanks and Regards, > Johann. > > >> >> Thanks, >> Omindu >> >> -- >> Omindu Rathnaweera >> Software Engineer, WSO2 Inc. >> Mobile: +94 771 197 211 <+94%2077%20119%207211> >> > > > > -- > > *Johann Dilantha Nallathamby* > Technical Lead & Product Lead of WSO2 Identity Server > Governance Technologies Team > WSO2, Inc. > lean.enterprise.middleware > > Mobile - *+94777776950* > Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* > -- Gayan Gunawardana Software Engineer; WSO2 Inc.; http://wso2.com/ Email: [email protected] Mobile: +94 (71) 8020933
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
