Hi Omindu, Yes. We can't use reCaptcha without internet. But the chance of having Bots attack from a internal network is very less. So we can either disable reCaptcha when server is not connect to the internet or have the old captcha implementation.
+1 for keep the existing captcha implementation. But we have to modify login, self-registration and recovery flows to add captcha/reCaptcha in a pluggable manner. Thanks, Thanuja. On Tue, Jun 7, 2016 at 11:14 AM, Isura Karunaratne <[email protected]> wrote: > 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 > > -- *Thanuja Lakmal* Senior Software Engineer WSO2 Inc. http://wso2.com/ *lean.enterprise.middleware* Mobile: +94715979891 +94758009992
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
