Hi Omindu, So the implementation of POST in /me endpoint will call addUser with special role and /User will call addUser without special role, right? So this address my concern.
Thanks, On Thu, Mar 2, 2017 at 6:34 PM, Omindu Rathnaweera <[email protected]> wrote: > Hi All, > > As per the offline discussion we had on the subject, we will be taking the > following approach. > > Self sign-up can be achieved by SCIM /Me endpoint and the self > sign-up REST endpoint. In addition to the self sign-up, the REST endpoint > will have support for confirmation code resend, and confirmation code > verification. > > As Johann pointed out, there should be a way to identify a self sign-up > users and searching through user claims or meta attributes will not be the > ideal solution considering the performance overhead. Therefore, we will be > introducing a reserved group for the self sign-up user and the Identity > Store API will have overloaded methods to add users with groups. And the > REST endpoints will be calling these methods for self sign-up internally. > > > *User addUser(UserBean userBean, List<String> groupIdList) throws > IdentityStoreException* > > *User addUser(UserBean userBean, String domainName, List<String> > groupIdList) throws IdentityStoreException* > > Also by introducing the overloaded method, we can overcome the problem of > identifying the self sign-up user. How we achieve this is by making the > self sign-up handler subscribe to the over loaded add user method. > Therefore, to start a self sign-up flow, one should call the overloaded > addUser method with the self sign-up group's unique ID. The handler will > check for the self sign-up group id to identify the whether the addUser > operation is related to self sign-up. > > @Sewmini: /User endpoint will not be supporting self sign-up. > > @Maduranga: > > The primary difference between the self sign-up 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? >> > > If we only consider the REST endpoints, it is a valid point. But the REST > endpoints will not be the only place which will trigger the self > sign-up flow. So I'm not quite confident whether we can rely on the fact > that there won't be an authenticated user for the self sign-up flow. > > 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. >> > > With the new approach, the REST service consumers won't need to specify a > group for self sign-up. > > Thanks, > Omindu. > > On Thu, Mar 2, 2017 at 6:57 AM, Omindu Rathnaweera <[email protected]> > wrote: > >> Hi Johann, >> >> 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). >>> >> >> With /Me endpoint, we can achieve user registration, but the user >> confirmation, resend confirmation code functionalities have to be given by >> the self sign up REST API unless we introduce SCIM resource extensions. >> >> >>> 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? >>> >> >> Correct me if I've understood this wrong. With this approach we are >> limiting the origin of SSU request only to the REST API/OSGi service and >> eliminate the need to identify whether the request is for SSU or not ? >> >> If that's the case we can even get rid of the SSU handler and do >> everything in the self sign-up manager OSGi service. But I was under the >> assumption that, we should not limit the capability to initiate the SSU >> flow only to the REST API and the OSGi service. With the handler, whenever >> we call the addUser method, we can trigger the SSU flow (given that we can >> identify it's a SSU request). >> >> >>> 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. >>> >> >> +1 for having a group. >> >> >>> 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>* >>> >> >> Thanks, >> Omindu >> >> -- >> Omindu Rathnaweera >> Software Engineer, WSO2 Inc. >> Mobile: +94 771 197 211 <+94%2077%20119%207211> >> > > > > -- > Omindu Rathnaweera > Software Engineer, WSO2 Inc. > Mobile: +94 771 197 211 <+94%2077%20119%207211> > -- 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
