On Sun, Jun 26, 2016 at 9:46 AM, Isura Karunaratne <is...@wso2.com> wrote:
> 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, > If we can do this by implementing a listener for addUser, we are not depending on using any specific API for self user registration. We can use any API such as, SCIM, RemoteUserStoreManager, UserAdmin or the new REST API and still send email confirmation codes to the email address. We are not bound to any specific API. We do need to consider the difference between the authorization levels of an admin user creating another user and a user signing up by himself, but this is a access control problem that should be handled before hitting any of these APIs, and shouldn't be different from one API to another. > > > - 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. > > Let's rename the role to Internal/selfsignup. Make sure this role is added in server startup, don't allow to delete or update this role manually. These validations can be achieved by implementing user store listeners. Only way to add a user to this role is through add user which will call doUpdateRoleListOfUser bypassing the listeners. > > - We can support SCIM self-registration for authenticated tenant > space and we will keep the existing rest API implementation to support SAAS > authentication. > > Yes we can go with this as a limitation in SCIM API. To use SaaS authentication we can use the new API. Later on we can improve the SCIM authentication and authorization handlers to support this. Like I previously mentioned its access control problem and can be fixed by changing the way the SCIM handlers for authentication and authorization are implemented. Thanks, Johann. > > - > > > Thanks > Isura > > On Sat, Jun 25, 2016 at 1:53 AM, Johann Nallathamby <joh...@wso2.com> > 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 <darsh...@wso2.com> >> wrote: >> >>> Hi Malithi, >>> >>> On Wed, Jun 8, 2016 at 10:28 AM, Malithi Edirisinghe <malit...@wso2.com> >>> 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 <than...@wso2.com> >>>> 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 <is...@wso2.com> >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> On Tue, Jun 7, 2016 at 10:47 AM, Omindu Rathnaweera <omi...@wso2.com> >>>>>> 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 < >>>>>>> malit...@wso2.com> 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 <is...@wso2.com> >>>>>>>> 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 < >>>>>>>>> malit...@wso2.com> 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 >>>>>>>>>> malit...@wso2.com >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Isura Dilhara Karunaratne >>>>>>>>> Senior Software Engineer >>>>>>>>> >>>>>>>>> Mob +94 772 254 810 >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> *Malithi Edirisinghe* >>>>>>>> Associate Technical Lead >>>>>>>> WSO2 Inc. >>>>>>>> >>>>>>>> Mobile : +94 (0) 718176807 >>>>>>>> malit...@wso2.com >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> Architecture@wso2.org >>>>>>>> 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 >>>>> Architecture@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> *Malithi Edirisinghe* >>>> Associate Technical Lead >>>> WSO2 Inc. >>>> >>>> Mobile : +94 (0) 718176807 >>>> malit...@wso2.com >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Regards, >>> >>> >>> *Darshana Gunawardana*Senior Software Engineer >>> WSO2 Inc.; http://wso2.com >>> >>> *E-mail: darsh...@wso2.com <darsh...@wso2.com>* >>> *Mobile: +94718566859 <%2B94718566859>*Lean . Enterprise . Middleware >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> 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 >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Isura Dilhara Karunaratne > Senior Software Engineer > > Mob +94 772 254 810 > > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > 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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
