Hi, On Tue, Jun 7, 2016 at 10:47 AM, Omindu Rathnaweera <[email protected]> wrote:
> 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 ? > +1. but, we better to decouple old captcha implementation with recovery flows. Thanks Isura > 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 > -- 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
