Hi Maduranga, On Fri, Mar 3, 2017 at 8:11 AM Maduranga Siriwardena <[email protected]> wrote:
> 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. > Yes, but it is a special Group, not a role. Thanks Isura. > > 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> > -- *Isura Dilhara Karunaratne* Senior Software Engineer | WSO2 Email: [email protected] Mob : +94 772 254 810 Blog : http://isurad.blogspot.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
