REST API for resending confirmation code in account recovery and self registration scenarios

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

REST API for resending confirmation code in account recovery and self registration scenarios

Indunil Upeksha Rathnayake
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
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?



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).
  • 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


Appreciate your ideas and comments on this.


Thanks and Regards

--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   0772182255

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: REST API for resending confirmation code in account recovery and self registration scenarios

Dushan Abeyruwan


On Mon, Dec 4, 2017 at 6:54 AM, Indunil Upeksha Rathnayake <[hidden email]> 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
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?
So, generally, when resendingm it should verify the user email address isn't that the case case here? genreally, you will not re-send confirmation code for unverified accounts



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).
How to filter out the facts? you mean managing UI per inactive confirmation links? then selectivly disabling?  Anyway, yeah this looks to be a good initiate to have anyway.
  • 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 :
+1 
    • select the user(s) to whom need to resend the activation email 
users/s how many users at once? don't you think it may get complicate when user store is large and if the selection get larger
    • 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
would appropriate to send email to a user group rather a indvidual IMO or may be users who are in certain group as you have specified, that may more praticle (I'm thinking larger user store)
     

    --
    You received this message because you are subscribed to the Google Groups "WSO2 Documentation Group" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
    For more options, visit https://groups.google.com/a/wso2.com/d/optout.



    --
    Dushan Abeyruwan | Architect
    Technical Support,MV
    PMC Member Apache Synpase
    WSO2 Inc. http://wso2.com/
    Mobile:(001)408-791-9312


    _______________________________________________
    Architecture mailing list
    [hidden email]
    https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
    Reply | Threaded
    Open this post in threaded view
    |

    Re: REST API for resending confirmation code in account recovery and self registration scenarios

    Isura Karunaratne
    In reply to this post by Indunil Upeksha Rathnayake
    Hi Indunil,



    On Mon, Dec 4, 2017 at 8:24 PM, Indunil Upeksha Rathnayake <[hidden email]> 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. 


     
    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?



    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


    Thanks
    Isura.  



    --
    Isura Dilhara Karunaratne
    Associate Technical Lead | WSO2
    Mob : +94 772 254 810




    _______________________________________________
    Architecture mailing list
    [hidden email]
    https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
    Reply | Threaded
    Open this post in threaded view
    |

    Re: REST API for resending confirmation code in account recovery and self registration scenarios

    Johann Nallathamby
    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 :). 

    On Tue, Dec 5, 2017 at 8:15 AM, Isura Karunaratne <[hidden email]> wrote:
    Hi Indunil,



    On Mon, Dec 4, 2017 at 8:24 PM, Indunil Upeksha Rathnayake <[hidden email]> 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".

    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?
     


     
    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?
     



    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.




    --
    Isura Dilhara Karunaratne
    Associate Technical Lead | WSO2
    Mob : <a href="tel:+94%2077%20225%204810" value="+94772254810" target="_blank">+94 772 254 810






    --
    Thanks & Regards,

    Johann Dilantha Nallathamby
    Senior Lead Solutions Engineer
    WSO2, Inc.
    lean.enterprise.middleware

    Mobile - +94777776950

    _______________________________________________
    Architecture mailing list
    [hidden email]
    https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
    Reply | Threaded
    Open this post in threaded view
    |

    Re: REST API for resending confirmation code in account recovery and self registration scenarios

    Ishara Karunarathna
    In reply to this post by Isura Karunaratne
    HI,

    On Tue, Dec 5, 2017 at 8:15 AM, Isura Karunaratne <[hidden email]> wrote:
    Hi Indunil,



    On Mon, Dec 4, 2017 at 8:24 PM, Indunil Upeksha Rathnayake <[hidden email]> 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. 
    +1, I also think no need re send the code if user can retry the scenarios.


     
    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?



    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).
    In this scenarios how do we going to identify the incident and who will going to revoke the conformation code. 

    +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


    Thanks
    Isura.  
    Appreciate your ideas and comments on this.
    This is open ended feature. shall we break down the tasks, So it whould be easy for you to start.

    -Ishara



    --
    Isura Dilhara Karunaratne
    Associate Technical Lead | WSO2
    Mob : <a href="tel:+94%2077%20225%204810" value="+94772254810" target="_blank">+94 772 254 810






    --
    Ishara Karunarathna
    Technical Lead
    WSO2 Inc. - lean . enterprise . middleware |  wso2.com

    email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: +94717996791



    _______________________________________________
    Architecture mailing list
    [hidden email]
    https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
    Reply | Threaded
    Open this post in threaded view
    |

    Re: REST API for resending confirmation code in account recovery and self registration scenarios

    Indunil Upeksha Rathnayake
    In reply to this post by Johann Nallathamby
    Hi,

    On Tue, Dec 5, 2017 at 9:03 AM, Johann Nallathamby <[hidden email]> 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 <[hidden email]> wrote:
    Hi Indunil,



    On Mon, Dec 4, 2017 at 8:24 PM, Indunil Upeksha Rathnayake <[hidden email]> 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.




    --
    Isura Dilhara Karunaratne
    Associate Technical Lead | WSO2
    Mob : <a href="tel:+94%2077%20225%204810" value="+94772254810" target="_blank">+94 772 254 810






    --
    Thanks & Regards,

    Johann Dilantha Nallathamby
    Senior Lead Solutions Engineer
    WSO2, Inc.
    lean.enterprise.middleware

    Mobile - +94777776950



    --
    Indunil Upeksha Rathnayake
    Software Engineer | WSO2 Inc
    Email    [hidden email]
    Mobile   0772182255

    _______________________________________________
    Architecture mailing list
    [hidden email]
    https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
    Reply | Threaded
    Open this post in threaded view
    |

    Re: REST API for resending confirmation code in account recovery and self registration scenarios

    Indunil Upeksha Rathnayake
    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)"
    Thanks and Regards

    On Tue, Dec 5, 2017 at 10:56 AM, Indunil Upeksha Rathnayake <[hidden email]> wrote:
    Hi,

    On Tue, Dec 5, 2017 at 9:03 AM, Johann Nallathamby <[hidden email]> 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 <[hidden email]> wrote:
    Hi Indunil,



    On Mon, Dec 4, 2017 at 8:24 PM, Indunil Upeksha Rathnayake <[hidden email]> 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.




    --
    Isura Dilhara Karunaratne
    Associate Technical Lead | WSO2
    Mob : <a href="tel:+94%2077%20225%204810" value="+94772254810" target="_blank">+94 772 254 810






    --
    Thanks & Regards,

    Johann Dilantha Nallathamby
    Senior Lead Solutions Engineer
    WSO2, Inc.
    lean.enterprise.middleware

    Mobile - +94777776950



    --
    Indunil Upeksha Rathnayake
    Software Engineer | WSO2 Inc
    Email    [hidden email]
    Mobile   0772182255



    --
    Indunil Upeksha Rathnayake
    Software Engineer | WSO2 Inc
    Email    [hidden email]
    Mobile   0772182255

    _______________________________________________
    Architecture mailing list
    [hidden email]
    https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
    Reply | Threaded
    Open this post in threaded view
    |

    Re: REST API for resending confirmation code in account recovery and self registration scenarios

    Johann Nallathamby
    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 <[hidden email]> 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)"
    Thanks and Regards

    On Tue, Dec 5, 2017 at 10:56 AM, Indunil Upeksha Rathnayake <[hidden email]> wrote:
    Hi,

    On Tue, Dec 5, 2017 at 9:03 AM, Johann Nallathamby <[hidden email]> 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 <[hidden email]> wrote:
    Hi Indunil,



    On Mon, Dec 4, 2017 at 8:24 PM, Indunil Upeksha Rathnayake <[hidden email]> 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.




    --
    Isura Dilhara Karunaratne
    Associate Technical Lead | WSO2
    Mob : <a href="tel:+94%2077%20225%204810" value="+94772254810" target="_blank">+94 772 254 810






    --
    Thanks & Regards,

    Johann Dilantha Nallathamby
    Senior Lead Solutions Engineer
    WSO2, Inc.
    lean.enterprise.middleware

    Mobile - +94777776950



    --
    Indunil Upeksha Rathnayake
    Software Engineer | WSO2 Inc
    Email    [hidden email]
    Mobile   0772182255



    --
    Indunil Upeksha Rathnayake
    Software Engineer | WSO2 Inc
    Email    [hidden email]
    Mobile   0772182255



    --
    Thanks & Regards,

    Johann Dilantha Nallathamby
    Senior Lead Solutions Engineer
    WSO2, Inc.
    lean.enterprise.middleware

    Mobile - +94777776950

    _______________________________________________
    Architecture mailing list
    [hidden email]
    https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture