Hi Malithi,

These steps seem to be ok. However we are going to move from KAPCHA to
google reCaptcha in IS 5.3.0 and this captcha implementation is decoupled
with each flow you mentioned. So, in new implementation captcha validation
will happen before invoking to the backend APIs.

In "security questions based password recovery flow", we are going to add a
new parameter to parameterize the minimum number of questions that user
should be answered to recover the password. In the previous releases (IS 5,
IS5.1.0) this is an application side configuration and it was not a server
side configuration. With IS 5.3.0 onwards tenant admin can define the
minimum number of questions that user should be answered to recover the
password.

Thanks
Isura



On Fri, Apr 29, 2016 at 11:40 AM, Malithi Edirisinghe <[email protected]>
wrote:

> Hi All,
>
> We are working on $subject.
>
> So with this, we will be supporting below options in the login page of the
> end user dashboard in IS.
>
>    1. Forgot Password (Password Recovery)
>    2. Forgot Username (Username Recovery)
>    3. Create an account (Self Signup)
>
> Below I have listed the user stories that we identified, to support each
> option above.
>
> *Password Recovery*
>
> With the existing information recovery service implementation we can
> support two options.
> Visibility of each option would be decided on the availability of required
> configurations and required user information.
>
>    - Password recovery with an email notification (Email transport
>    configuration are required and the user should have a valid email address)
>    - Password recovery with security questions (User should have
>    preconfigured security questions)
>
> *User story for password recovery with email notification*
>
>    1. User views a generated captcha
>    2. User enters the captcha answer and submit
>    3. Server verifies the captcha answer and sends an email notification
>    with the confirmation code
>    4. User clicks on the received confirmation url
>    5. User views a generated captcha
>    6. User enters the captcha answer and submit
>    7. Server verifies the captcha answer and let the user to reset
>    password
>    8. User resets the password
>    9. Upon successful password reset user is notified and redirected to
>    login page
>
>
> *User story for password recovery with security questions*
>
>    1. User views a generated captcha
>    2. User enters the captcha answer and submit
>    3. User views the security questions (Based on the server
>    configuration user may have to answer preconfigured security questions from
>    each question set one by one or all at once)
>    4. User answers the questions as requested by the server.
>    5. Server verifies the answers and let the user to reset password
>    6. User resets the password
>    7. Upon successful password reset user is notified and redirected to
>    login page
>
> *Username Recovery*
>
> Username recovery is supported only with an email notification.
> Thus, the visibility of this option would be decided on required email
> transport configurations
>
> *User story for username recovery with email notification*
>
>    1. User views a page with a set of requested claims and captcha
>    2. User enters the requested claim values and captcha answer
>    3. Server verifies the captcha answer along with the claims
>    4. Server sends an email notification with the username, notifies the
>    user on the status and redirects to the login page
>
> *Self Registration*
>
> Ideally we have two services that supports self registration. One verifies
> the user account with an email notification and the other just registers
> the user.
> So if email transport configurations are done self registration will
> always verify the user with an email notification, other wise the user will
> be allowed to simply register.
>
> *User story for self registration with email verification*
>
>    1. User views the registration page
>    2. User enters the requested information and register
>    3. Server sends an account confirmation to the user via email
>    4. User clicks on the received confirmation url
>    5. User views a generated captcha
>    6. Server verifies the captcha answer
>    7. User views security question configuration page (User should be
>    allowed to skip this as well. Based on the preconfigured security questions
>    it's decided if the user is allowed to recover password with security
>    questions or not)
>    8. User may skip or configure as desired
>    9. Upon successful registration user is redirected to login page
>
> *User story for self registration without email verification*
>
>    1. User views the registration page
>    2. User enters the requested information and register
>    3. User views security question configuration page (User should be
>    allowed to skip this as well. Based on the preconfigured security questions
>    it's decided if the user is allowed to recover password with security
>    questions or not)
>    4. User may skip or configure as desired
>    5. Upon successful registration user is redirected to login page
>
> Appreciate you thoughts.
>
> Thanks,
> Malithi.
> --
>
> *Malithi Edirisinghe*
> Senior Software Engineer
> WSO2 Inc.
>
> Mobile : +94 (0) 718176807
> [email protected]
>



-- 
Isura Dilhara Karunaratne
Senior Software Engineer

Mob +94 772 254 810
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to