Re: [Architecture] 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 <
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 
>> 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 
>>> 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 

Re: [Architecture] 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)"
[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 
> 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  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 

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

[Indunil Upeksha Rathnayake]

Hi,

On Tue, Dec 5, 2017 at 9:03 AM, Johann Nallathamby  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  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 

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

[Ishara Karunarathna]

HI,

On Tue, Dec 5, 2017 at 8:15 AM, Isura Karunaratne  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.
>
+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

>
>> [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/Re
>> sendCodeApiServiceImpl.java
>> [2] https://wso2.org/jira/browse/DOCUMENTATION-7189
>>
>> Thanks and Regards
>>
>> --
>> Indunil Upeksha Rathnayake
>> Software Engineer | WSO2 Inc
>> Emailindu...@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/
>
>
>
>


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

email: 

Re: [Architecture] 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  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".

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 

Re: [Architecture] 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  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)

>
>
>

>
>-
>
>
>
> 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/
> ResendCodeApiServiceImpl.java
> [2] https://wso2.org/jira/browse/DOCUMENTATION-7189
>
> Thanks and Regards
>
> --
> Indunil Upeksha Rathnayake
> Software Engineer | WSO2 Inc
> Emailindu...@wso2.com
> Mobile   0772182255
>
> --
> 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 documentation+unsubscr...@wso2.com.
> 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/
Blog:*http://www.dushantech.com/ *
LinkedIn:*https://www.linkedin.com/in/dushanabeyruwan
*
Mobile:(001)408-791-9312
___
Architecture mailing list
Architecture@wso2.org

[Architecture] 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.

[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/ResendCodeApiServiceImpl.java
[2] https://wso2.org/jira/browse/DOCUMENTATION-7189

Thanks and Regards

-- 
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Emailindu...@wso2.com
Mobile   0772182255
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture