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