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. 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>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
