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