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). > 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. > > @Isura, > Could you please initiate a thread on the design of the new Identity > Management APIs > You can refer new thread of Identity Management Rest APIs from [1] [1] [Architecture] Identity Management Recovery API improvements. Thanks Isura > [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] > -- 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
