Hi Indunil, We need to also enforce captcha on the self signup Rest API (following the same pattern implemented for other Rest APIs), because the self signup API only has application level authentication and users who can access the application (by default "*authenticationendpoint"*) are able carry out a bot attack.
Regards, Johann. On Thu, Dec 7, 2017 at 10:46 AM, Indunil Upeksha Rathnayake < indu...@wso2.com> wrote: > Hi, > > Thanks all for your valuable feedbacks, it will be helpful to improve this > in future. > > In the design discussion (Refer [1]), it's concluded that to implement a > generic OSGI service for resending confirmation code in account recovery > scenarios and self registration and to consider other improvements in next > IS release. The OSGI service has been implemented with [2] and other > improvements will be tracking with [3]. > > [1] Mail thread : "Invitation: [Discussion] [Design] REST API for > resending confirmation... @ Tue Dec 5, 2017 1pm - 2pm (IST) (IAM team)" > [2] https://github.com/wso2-extensions/identity-governance/pull/197 > [3] https://wso2.org/jira/browse/IDENTITY-7062 > > Thanks and Regards > > On Tue, Dec 5, 2017 at 10:56 AM, Indunil Upeksha Rathnayake < > indu...@wso2.com> wrote: > >> Hi, >> >> On Tue, Dec 5, 2017 at 9:03 AM, Johann Nallathamby <joh...@wso2.com> >> wrote: >> >>> Hi Indunil/Isura, >>> >>> I have a general comment on this. Are we not planning to support this in >>> the UI at least in the public release? Because planning for backend only >>> IMO is not a good idea from previous experience because it will remain at >>> the same state for years. Don't want to go back there. And from a >>> capabilities POV it won't be considered as OOTB capabilities of the >>> product, which makes it hard to sell :). >>> >> >> AFAIU, you have mentioned about providing UI support for resending >> confirmation emails? >> I think we should consider the UI validations in account recovery >> endpoint, when a previously issued confirmation link is used, as I have >> mentioned previously (ex: when someone use a previously issued confirmation >> link for reset password, user should redirect to an error page, without >> redirect to the password reset page). WDYT? >> >> >>> >>> On Tue, Dec 5, 2017 at 8:15 AM, Isura Karunaratne <is...@wso2.com> >>> wrote: >>> >>>> Hi Indunil, >>>> >>>> >>>> >>>> On Mon, Dec 4, 2017 at 8:24 PM, Indunil Upeksha Rathnayake < >>>> indu...@wso2.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> With IS 5.3.0, we have currently provided a Rest API for resending >>>>> confirmation code (Refer [1]), which supports only for self signup >>>>> feature. >>>>> So that, we are planning to provide a more generic REST API and a OSGi >>>>> service, for resending confirmation code for any scenario. >>>>> >>>>> >>>>> >>>>> Following are the scenarios, currently where we are sending >>>>> confirmation emails in IS. >>>>> >>>>> - *Password Reset* - password recovery using email-based >>>>> notifications >>>>> - *Account Confirmation* - email confirmation on user self >>>>> registration >>>>> - *Ask Password* - ask password from user through confirmation >>>>> email >>>>> - *Admin Forced Password Reset*- admin to trigger a password reset >>>>> for a given user account >>>>> - *Admin Forced Password Reset With OTP* - admin send an email to >>>>> the user with a one time password that the user can use to login once >>>>> to >>>>> the account after which, the user will be prompted to set a new >>>>> password >>>>> - *Email Confirmation *- account confirmation through email >>>>> notification >>>>> >>>>> >>>> IMO it is not required to have an option to resend the confirmation >>>> codes for following scenarios. >>>> >>>> >>>> - Password Reset >>>> - Admin Force Password Reset >>>> - Admin Force Password Reset with OTP >>>> >>>> There is no intermediate step between sending confirmation and >>>> validating confirmation in mentioned scenarios. So, instead of resending >>>> the code, users can start a new flow again. (Ex. Try another attempt to >>>> reset password ) >>>> BTW, it is good to have a generic API to resend the confirmation codes. >>>> >>> >>> Yes. Please carefully consider the scenarios where "resending" is >>> absolutely necessary. Wherever we can "restart" the process we don't need >>> to "resend". >>> >> >> Yes. Planning to cover only the necessary scenarios from the above list. >> >> >>> >>> We can have two types of emails as far as I understand; emails with >>> confirmation codes for verification and emails with just text for >>> notification. Please consider these two kind of mails also when designing. >>> Are we planning to support "resend" for emails for just notifications? E.g. >>> user account disable? >>> >> >> I think it's not needed to resend emails with just text notifications. Or >> you are considering implementation of a generic API for notification >> sending in recovery scenarios rather than API for notification resending? >> >> >>> >>>> >>>> >>>> >>>> >>>>> In there, the confirmation emails get expired after a configured time >>>>> period in order to make the accounts secure. After the expiration, we may >>>>> need to resend the confirmation emails. >>>>> >>>>> So with this implementation, when we request for resending >>>>> confirmation code, previously issued code (even though, it's still not >>>>> expired), should get expired and the new confirmation code should >>>>> considered as active. So that in any scenario, if a user is requesting to >>>>> use an expired confirmation code, we need to redirect the user, to an >>>>> error >>>>> page mentioning of using an expired confirmation link. >>>>> >>>>> In case of user self registration, if request has made for resending >>>>> confirmation link, after a account activation, I think it should be >>>>> handled >>>>> in the self registration API (currently Re-Send button to resend the >>>>> confirmation link will be appeared in the login page, when we try to login >>>>> to an unverified account). We may not need to consider it, when resending >>>>> the confirmation code. WDYT? >>>>> >>>> >>> I am not sure I understood the differences in the scenarios you are >>> explaining well. Can you explain in a different way? >>> >> >> My concern was, when we resending a confirmation email for self >> registration, in the back-end REST API, we need to validate whether the >> account have been activated or not? Or we can provide a UI validation as >> currently in the login page (Re-Send button to resend the confirmation >> link will be appeared in the login page, if only account is not activated)? >> >> >>> >>> >>>> >>>>> >>>>> >>>>> Other than that, I think we can consider following scenarios as >>>>> further improvements. WDYT? >>>>> >>>>> - In case of a forgery, we may need to expire the confirmation >>>>> link, manually before the configured time (without resending the >>>>> confirmation link). >>>>> >>>>> >>>> +1. Please create a improvement Jira to track this. >>>> >>>>> >>>>> - >>>>> - Currently for resending confirmation email for user self >>>>> registration, we have provided support in the login page where user can >>>>> request to resend confirmation link (We have not added this to the >>>>> documentation, created a doc jira in [2]). In order to resend the >>>>> confirmation emails from admin (or user with a required permissions), >>>>> we >>>>> can provide support in management console to : >>>>> - select the user(s) to whom need to resend the activation >>>>> email >>>>> - select a role, to send confirmation emails to a group of >>>>> users - here we may need to automatically skip over users who have >>>>> already >>>>> activated there accounts in case of self registration >>>>> >>>>> +1 to consider resending to a group of users if we feel it's useful. >>> >>> Can we introduce a new role that contains all the users to whom emails >>> have been sent and confirmation pending? And may be another role to contain >>> all the users who have confirmed? Otherwise there is no way to easily >>> retrieve the list of users who are pending confirmation or already >>> confirmed. *@Maduranga* implemented a similar use case for a customer >>> recently. Please discuss with him and see how he did it. >>> >>> Thanks & Regards, >>> Johann. >>> >>> >>>>> - >>>>> >>>>> >>>>> >>>>> Thanks >>>> Isura. >>>> >>>>> Appreciate your ideas and comments on this. >>>>> >>>>> [1] https://github.com/wso2-extensions/identity-governance/blob/ >>>>> master/components/org.wso2.carbon.identity.user.endpoint/src >>>>> /main/java/org/wso2/carbon/identity/user/endpoint/impl/Resen >>>>> dCodeApiServiceImpl.java >>>>> [2] https://wso2.org/jira/browse/DOCUMENTATION-7189 >>>>> >>>>> Thanks and Regards >>>>> >>>>> -- >>>>> Indunil Upeksha Rathnayake >>>>> Software Engineer | WSO2 Inc >>>>> Email indu...@wso2.com >>>>> Mobile 0772182255 >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> *Isura Dilhara Karunaratne* >>>> Associate Technical Lead | WSO2 >>>> Email: is...@wso2.com >>>> Mob : +94 772 254 810 <+94%2077%20225%204810> >>>> Blog : http://isurad.blogspot.com/ >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> Thanks & Regards, >>> >>> *Johann Dilantha Nallathamby* >>> Senior Lead Solutions Engineer >>> WSO2, Inc. >>> lean.enterprise.middleware >>> >>> Mobile - *+94777776950* >>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >>> >> >> >> >> -- >> Indunil Upeksha Rathnayake >> Software Engineer | WSO2 Inc >> Email indu...@wso2.com >> Mobile 0772182255 >> > > > > -- > Indunil Upeksha Rathnayake > Software Engineer | WSO2 Inc > Email indu...@wso2.com > Mobile 0772182255 > -- Thanks & Regards, *Johann Dilantha Nallathamby* Senior Lead Solutions Engineer WSO2, Inc. lean.enterprise.middleware Mobile - *+94777776950* Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
