On Tue, Mar 14, 2017 at 8:25 PM, Sagara Gunathunga <[email protected]> wrote:
> > - Personally I don't like to duplicate self sign-up or any other feature > in two different places but I agree with the given justification about the > limitations of SCIM /Me endpoint, it would be ideal if we can support these > use cases by extending SCIM but if we have already developed our own > endpoint that's ok for the time being. > If we are to limit self sign-up only for /Me endpoint, I think it'll be much cleaner to provide SCIM resource extensions for 'resend-code' and 'self sign-up confirmation' just so that user doesn't have to consume two types of APIS. > > - In my POV "Group" are for Identity admins, to group their end users > depend on business use cases and our requirement here is to track the > 'source' of new users based on system perspective. We can use "Group" > without any issue but I would much prefer if we can track the 'source' or > 'origin' per user basis, that is more prominent and can be useful in > analytics and workflows. In technical terms my suggestion is to introduce a > new system-claim/User-metadata-attribute called source/origin, also > this is not limited to self-sign-up we have to track all sources such as > from-admin-portal, from-JIT-IDP-X, from-SCIM-IDP-Y, from-SCIM-agent-Z etc. > +1 for introducing a system attribute to track the origin. But only having an attribute would not suffice when we need to perform authorization actions based on the origin since we won't be supporting attribute based authorization. So for those cases, we have to group the users and assign permissions by means of roles. Even in JIT scenarios it's a common requirement to provision the users to a certain group (which we didn't have OOTB support in C4). IMO it's better to have the self sign-up users added to a group and as you mentioned we can use the system attribute to identify the origin. > > Further we anyhow have to maintain set of > system-claim/User-metadata-attributes > to track user's metadata such as created-time, updated-time, created-by > etc. > > > Thanks ! > > On Fri, Mar 3, 2017 at 8:21 AM, Isura Karunaratne <[email protected]> wrote: > >> 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 <+94%2071%20899%200591> >>> Blog: http://madurangasblogs.blogspot.com/ >>> <http://wso2.com/signature> >>> >> -- >> >> *Isura Dilhara Karunaratne* >> Senior Software Engineer | WSO2 >> Email: [email protected] >> Mob : +94 772 254 810 <+94%2077%20225%204810> >> Blog : http://isurad.blogspot.com/ >> >> >> >> > > > -- > Sagara Gunathunga > > Associate Director / Architect; WSO2, Inc.; http://wso2.com > V.P Apache Web Services; http://ws.apache.org/ > Linkedin; http://www.linkedin.com/in/ssagara > Blog ; http://ssagara.blogspot.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
