Hi Isura, Since reCaptcha requires to call Google's services for captcha generation and validation, we won't be able to use the dashboard with captcha when we are running IS in an environment without internet connectivity. I'm assuming we are not shipping the old captcha implementation in 5.3.0 so a user will not be able to switch to an internally managed captcha implementation with a simple config change.
It'll be good if we can make the old captcha implementation (or a similar implementation) available (by means of an extension or a sample maybe ?) so a user can switch to an internally managed captcha model without much work. WDYT ? Regards, Omindu. On Sun, Jun 5, 2016 at 12:35 PM, Malithi Edirisinghe <[email protected]> wrote: > Hi Isura, > > Noted. > > I've got one more concern. > Initially, as you may have noted in the top most mail, recovery scenarios > were to be supported in the login page of the end user dashboard in IS. > But in a consecutive discussion it was highlighted that these options > should be provided in the default SSO login page. Thus, upon a successful > recovery or registration, the flow should be as below. > > 1. End user will be redirected to the login page. > 2. End user will enter the credentials > 3. End user is authenticated and upon successful authentication user > will be redirected to the Service Provider application (Ex: ACS url of the > SP). > > So at the moment, we are using the param 'sessionDataKey' to map the > server session across modules, which can be used even here to retrieve the > respective Service Provider who initiated the flow. But, when it comes to > recovery with notifications there is no parameter being communicated to > identify the respective Service Provider. Can we please address this also, > along with this effort ? > > Thanks, > Malithi. > > On Sun, Jun 5, 2016 at 8:39 AM, Isura Karunaratne <[email protected]> wrote: > >> 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 >> >> > > > -- > > *Malithi Edirisinghe* > Associate Technical Lead > WSO2 Inc. > > Mobile : +94 (0) 718176807 > [email protected] > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Omindu Rathnaweera Software Engineer, WSO2 Inc. Mobile: +94 771 197 211
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
