Hi Malithi, On Wed, Jun 8, 2016 at 10:28 AM, Malithi Edirisinghe <[email protected]> wrote:
> Hi All, > > I have following concern with regard to moving the account recovery web > application from OOTB supported KAPTCHA to google reCaptcha. > > As noted at [1], we should have an API key pair. Thus, we will not be able > to enable this for the webapp by default (with the fresh IS server pack). > There will be a default key pair that can be used in the default pack. Further, previously, captcha validation is a must for recovery API calls( > Ex: Password Recovery). > So does the new implementation enforce that verification? > If it does, we would also not be able to view those recovery options by > default. > As per new captcha implementation, captcha enforcement is decoupled from the backend API and new generic filter take care of handling the captcha. So any web app don't have to invoke additional APIs to handle captcha. Regards, Darshana. > > @Isura, > Could you please initiate a thread on the design of the new Identity > Management APIs > > [1][Architecture] [IS] Support for Google reCapth > > Thanks, > Malithi. > > On Tue, Jun 7, 2016 at 11:33 AM, Thanuja Jayasinghe <[email protected]> > wrote: > >> 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 >> >> > > > -- > > *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 > > -- Regards, *Darshana Gunawardana*Senior Software Engineer WSO2 Inc.; http://wso2.com *E-mail: [email protected] <[email protected]>* *Mobile: +94718566859 <%2B94718566859>*Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
