On Sun, Mar 19, 2017 at 5:24 PM, Johann Nallathamby <[email protected]> wrote:
> > > On Wed, Mar 15, 2017 at 4:41 AM, Omindu Rathnaweera <[email protected]> > wrote: > >> >> 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. >> > > +1 for doing this later on. > Added to Redmine: https://redmine.wso2.com/issues/5933 > Please add any information if necessary. > > >> >> >>> >>> - 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. >> > > +1 for this. Having users assigned to a group in advance is in fact going > one step further than tracking the origin. Then admins can directly assign > roles for those groups and do access control. Otherwise as the first step > they will need to search for all the users by origin attribute and then > assign them to a group and then assign roles to that group. > +1 It seems tracking the origin and assigning into groups serve two different purposes, let's implement both with along with related user stories. Thanks ! > > >> >> >>> >>> 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 <+94%2077%20119%207211> >> > > > > -- > Thanks & Regards, > > *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>* > -- 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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
