@Isura, Can we use SCIM to implement self sign-up instead of introducing a new self-sign up REST API? Can we extend the SCIM API to support the options we need for the two self sign-up scenarios Malithi has mentioned in her initial mail?
I think if it's possible we should go for it. If the restriction on using one API is because we want to know whether user is doing a self-sign up or getting created by an admin user, then I think it is wrong. Knowing who is the actor who is creating the user, self or admin, is necessary for access control only. That should be not a concern for the API. That should be handled before hitting the API. We have discussed and handled a similar requirement for our UserIdentityMangementAdminService which is a SOAP service using two axis2 handlers. Farasath will send a mail on this I think. I think we can discuss and see if it's possible to use SCIM to handle both these scenarios. On Wed, Jun 8, 2016 at 1:07 PM, Darshana Gunawardana <[email protected]> wrote: > 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 > > -- Thanks & Regards, *Johann Dilantha Nallathamby* Technical Lead & Product Lead of WSO2 Identity Server Governance Technologies Team WSO2, Inc. lean.enterprise.middleware Mobile - *+94777776950* Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
