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