Hi All, In IS user portal we have implemented REST clients by using JAX-RS proxy based client APIs[1]. At the beginning of the flaw we store User object as a session attribute. User object contains username, user store domain and tenant domain. For captcha enforcement there is a external component with generic filter. Now filter need to capture information from User object session attribute.
Do we need to define a class for user session object in a common place for both user portal and captcha filter ? IMO user portal should be totally independent from captcha implementation. WDYT? [1] http://cxf.apache.org/docs/jax-rs-client-api.html Thanks, Gayan On Sun, Jun 26, 2016 at 12:27 PM, Johann Nallathamby <[email protected]> wrote: > > > On Sun, Jun 26, 2016 at 9:46 AM, Isura Karunaratne <[email protected]> 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 <[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 >> >> > > > -- > 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 > > -- Gayan Gunawardana Software Engineer; WSO2 Inc.; http://wso2.com/ Email: [email protected] Mobile: +94 (71) 8020933
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
