Hi Omindu, The primary difference between the self-signup endpoint and the normal user provisioning endpoint is one needs authentication and one does not need authentication. So can't we use the separation to distinguish the 2 operation. Do we have a way to identify whether this request is authenticated or not during the execution of the handler?
I think if we use some claim/role/attribute to distinguish this, there might be problems with the situations where client will not send the claim/role/attribute when it is required and vice versa. Thanks, On Wed, Mar 1, 2017 at 8:39 AM, Gayan Gunawardana <[email protected]> wrote: > > > 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 > > -- Maduranga Siriwardena Software Engineer WSO2 Inc; http://wso2.com/ Email: [email protected] Mobile: +94718990591 Blog: http://madurangasblogs.blogspot.com/ <http://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
