Hi, We already have a rest API implementation for self-registration.
+1 for implementing self-registration through SCIM. I have following concern when implementing self-registration through SCIM, - How to identify SCIM self-registration request over normal admin provisioning request? - It is required to support SAAS authentication (users in super tenant should be able to add users to other tenants) for self-registration feature. AFAIR, Currently, SCIM requires tenant wise authentication. We can use following to overcome above, - Currently, we are assigning identity internal role for self-registered users. So, we can identify the self-registration provisioning SCIM request from internal/identity role. So, we can create a new Event handler to support this feature. - We can support SCIM self-registration for authenticated tenant space and we will keep the existing rest API implementation to support SAAS authentication. Thanks Isura On Sat, Jun 25, 2016 at 1:53 AM, Johann Nallathamby <[email protected]> wrote: > @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 > > -- 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
