Hi All,
On Wed, May 29, 2019 at 9:51 AM Hasanthi Purnima Dissanayake < hasan...@wso2.com> wrote: > Hi Shammi, > > Are you planing to provide a check box to select the user stores at the >> time it creates the SP? >> > > At the moment a handler level implementation will do this and no any UI > level configurations to achieve this. But +1 for SP level configuration , > let's consider this as a feature improvement in a future release. > > - If a user is not available in the assigned user stores for the SP, But >> the user is available in the other user stores which is not added to the >> SP, What would be the message we plan to provide to the user. >> Eg: We created a SP and assigned the user stores, Later there is a new >> user store configured but it was not assigned to the existing SP >> scenario. >> > > If the user does not exist in the configured user store that means the > user is not there in the system. So IMO this should be an authentication > failure. > > When the system deleted an existing user store, Is there any plan to >> traverse the existing entries in registry and remove all relevant SP-> >> User store mappings? >> > > We already have handlers to do actions on postUserStoreDelete. So we can > have some handlers to remove these configurations. > We need only to provide error response (API and UI) indicating the reasons for conflict. We should not delete the mappings automatically. Otherwise system may behave unexpected way after the deletion. It should be the identity admin responsibility to re-configure the affected SPs to free up the user store for deletion while maintaining the business logic. Thanks, > Hasanthi > > On Fri, May 24, 2019 at 11:46 PM Shammi Jayasinghe <sha...@wso2.com> > wrote: > >> Hi Nilasini, >> >> It is very nice idea and i believe we will be able to improve the >> performance of a deployment where we have many user stores configured due >> to this feature. >> >> With regarding to this, I would like to get few clarifications. >> - Are you planing to provide a check box to select the user stores at the >> time it creates the SP? >> - If a user is not available in the assigned user stores for the SP, But >> the user is available in the other user stores which is not added to the >> SP, What would be the message we plan to provide to the user. >> Eg: We created a SP and assigned the user stores, Later there is a new >> user store configured but it was not assigned to the existing SP scenario. >> >> - When the system deleted an existing user store, Is there any plan to >> traverse the existing entries in registry and remove all relevant SP-> User >> store mappings? >> >> I could locate the medium post [1] about implementing the similar feature >> with using Xacml. Are we planing this feature due to some issue/ usability >> of that existing capability? >> >> [1] >> https://medium.com/@Pushpalanka/application-wise-authorization-wso2-identity-server-user-store-per-service-provider-dfea5f9ad758 >> >> Thanks >> shammi >> >> On Fri, May 24, 2019 at 1:07 AM Nilasini Thirunavukkarasu < >> nilas...@wso2.com> wrote: >> >>> Hi, >>> >>> Currently, if the user doesn't specify the user store domain name with >>> username then we are trying to authenticate the user with all the available >>> user store. I am in the process of implementing a feature to support >>> authentication against a predefined user store list. >>> >>> *Requirement* >>> >>> If more than one user stores having the same user name with different >>> passwords then during the authentication we must have to specify the user >>> store domain. In case if user stores are LDAP or AD and the user store >>> domain couldn't be appended to the username then there can be issues like >>> account locking if AD and LDAP have configured for wrong password policies. >>> So with the current implementation, the following requirement can't be full >>> filled without specifying the user store domain along with the username. >>> >>> 1. AD and LDAP have configured for wrong password policies. AD and >>> LDAP are having the same user(let's say the *username is bob*) with >>> a different password. >>> 2. Employees only can access SP1(service provider) and Employees >>> details are stored in UserStore1(LDAP). >>> 3. Customers only can access SP2 and Customers details are stored in >>> UserStore2(AD). >>> 4. Employee and Customer can access SP3 >>> >>> *Issues* >>> >>> 1. Now if either employee or customer tries to log in to SP1 without >>> specifying the userStoredomain then the user will be searched to both the >>> user store domains >>> 2. If we have fixed the above issue and allow the users to search >>> only through UserStore1 for SP1 application, allow the users to search >>> only >>> through UserStore2 for SP2 then we will face another issue that if SP1 >>> already logged with user *bob *using the LDAP password and now if we >>> try to access the application SP2 in the same browser we will be >>> automatically logged in to SP2 as the LDAP user *bob *since there is >>> already a session. But as mentioned in point 3, only AD users can access >>> SP2 app. >>> >>> >>> *How to address the issues.* >>> >>> 1. To solve issue 1, we could introduce a callback handler and >>> generate the SP wise user store list through an extension point of the >>> call >>> back handler. So in the user store level, we will consider the generated >>> user store list and only execute the generated user store list for a >>> specific service provider. For example, we could configure the service >>> provider name against the allowed user stores in the registry. >>> 2. To solve the issue2, when there is already an existing session, >>> in addition, to check already authenticated authenticator and identity >>> provider, we should include a logic to check whether already logged in >>> user's user store domain is included in the allowed user store domain >>> (this >>> allowed user store list will be created through the extensions point as >>> mentioned in point 1). If included only we will allow the user to >>> logged-in >>> else prompt the login page. >>> >>> *Example:-* >>> >>> *bob *is logged in to SP1 using LDAP credential and in the >>> same browser try to access SP2, now he will be redirected to the login page >>> since SP2 will only allow the users in AD. >>> >>> Once we address the above two issues we need to find an approach to >>> support requirement 4. Once the user (bob) logged in to SP1 with LDAP >>> credential and SP2 with AD credential in the same browser, if we try to >>> access the application SP3 then there will be two logged in users (LDAP >>> user and AD user) so we could show a drop-down list and asked the user to >>> choose the logged-in user. >>> >>> Appreciate your suggestions and feedback on this. >>> >>> Thanks, >>> Nila. >>> >>> >>> >>> >>> -- >>> Nilasini Thirunavukkarasu | Senior Software Engineer | WSO2 Inc. >>> (m) +94775241823 | Email: nilas...@wso2.com >>> <http://wso2.com/signature> >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >> >> >> -- >> Best Regards, >> >> * Shammi Jayasinghe* >> >> >> *Senior Technical Lead* >> *WSO2, Inc.* >> *+1-812-391-7730* >> *+1-812-327-3505* >> >> *http://shammijayasinghe.blogspot.com >> <http://shammijayasinghe.blogspot.com>* >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> > > > -- > > Hasanthi Dissanayake | Senior Software Engineer | WSO2 Inc. > (m) +94718407133 | (w) +94112145345 | Email: hasan...@wso2.com > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > Cheers, Ruwan A
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
