How to Configure Your Preferred User Stores to Authenticate Users using WSO2

allows keeping multiple user stores for your system to store users and their roles. There should be one primary user store (mandatory) and any number of secondary user stores(optional). When creating a secondary user store we can provide a user store domain name for the secondary user stores. “PRIMARY” is the user store domain of the primary user store. WSO2 Identity server Now think about a service provider who uses WSO2 Identity Server to authenticate users who log into the application and it maintains multiple user stores in IS. Now we are going to look at two different ways that users can provide their usernames during the login process: 1. The user provides the user name with the user store domain (eg: PRIMARY/peter). Then WSO2 IS validate username and password against the values stored in the PRIMARY user store. 2. The user provides only the username without specifying the user store domain (eg: peter). Then, WSO2 IS starts to authenticate the user starting from the PRIMARY user store. If one user store fails to authenticate the user even if there is the username(i.e password is not matching), authentication will be executed in chained UserStore managers recursively. You can understand the second point from the highlighted lines in the wso2/carbon-kernel AbstractUSerStoreManager . (!authenticated && !domainProvided) { AbstractUserStoreManager userStoreManager; ( IterativeUserStoreManager) { IterativeUserStoreManager iterativeUserStoreManager = (IterativeUserStoreManager) ; userStoreManager = iterativeUserStoreManager.nextUserStoreManager(); } { userStoreManager = (AbstractUserStoreManager) abstractUserStoreManager.getSecondaryUserStoreManager(); } (userStoreManager != ) { authenticated = userStoreManager.authenticate(userName, credential, domainProvided); } } if if this instanceof this else if null Let’s say the service provider now wants to narrow down the number of user stores that will be searched to authenticate a user when he/she doesn’t provide user store domain-specific username. How can we do this?? NOTE: This feature is available in IS-5.7.0 WUM updated version and IS-5.9.0 onwards Let’s head-on with the following example to understand this process more clearly. — Product-IS 5.9.0 (download ) Identity Server here — travelocity.com (deploy it according to the given instructions ) Service provider here : “DRIVER”, “MANAGER”, “CUSTOMER” (instructions: ) Three Secondary JDBC user stores Named here (instructions: ) Add users according to the following table: here Only the users in PRIMARY, DRIVER and MANAGER user store can access travelocity.com services. Users in the CUSTOMER user store can’t use services in travelocity.com. Authenticating condition: Moreover, users don’t know their user store domain. Thus, they input username without the user store domain. (i.e username is just ‘peter’ not like ‘MANAGER/peter’). Without any further configurations, try to login to travelocity.com app and using four different username-password combinations in the table. You will be succeeded. Let’s narrow down the number of user stores allowed for travelocity.com login. You need to do two things: 1. Implement with your own logic to retrieve the allowed user stores. UserStorePreferenceOrderSupplier interface { ; } public interface UserStorePreferenceOrderSupplier T /** * Generate the user store order. * * UserStoreException */ @return @throws T UserStoreException get () throws 2. Then extend and create an object of your custom UserStorePreferenceOrderSupplier. CallBackHandlerFactory { UserStorePreferenceOrderSupplier > createUserStorePreferenceOrderSupplier (AuthenticationContext context, ServiceProvider serviceProvider) { DefaultUserStorePreferenceOrderSupplier(context, serviceProvider); } } public class CallBackHandlerFactory /** * Create user store preference order supplier. */ public return new This is the logic implemented according to the above requirement. (Find the sample ) here CustomUserStoreOrderCallbackFactory class . extends CallBackHandlerFactory SimpleUserStoreOrderCallbackHandler . implements UserStorePreferenceOrderSupplier > RegistryBasedUserStoreOrderCallbackHandler . extends SimpleUserStoreOrderCallbackHandler : Users who are in PRIMARY, MANAGER, and DRIVER user stores can log in to travelocity.com service provider. This configuration is read from Registry. Logic NOTE: In the pom.xml file, you need to update the dependency version according to the IS pack you are using. org.wso2.carbon.identity.framework org.wso2.carbon.identity.framework org.wso2.carbon.identity.application.authentication.framework .97 5.14 Also, Make sure the carbon-kernal which is used in the IS pack lies in the defined range. [ .0, .0) package import 4.4 5.0 package import NOW what should we do ?? 1. Build the repository which contains the login using command. mvn clean install 2. Inside target folder, you will find org.wso2.carbon.identity.custom.callback.userstore-1.0-SNAPSHOT.jar 3. Copy and paste the generated jar file “ ” into org.wso2.carbon.identity.custom.callback.userstore-1.0-SNAPSHOT.jar /repository/components/dropins/ 4. Configure the extended CallBackHandlerFactory in file, under /repository/conf/identity/application-authentication.xml ... org.wso2.carbon.identity.custom.callback.userstore.CustomUserStoreOrderCallbackFactory … "http://wso2.org/projects/carbon/application-authentication.xml" NOTE: From IS-5.10.0 onwards this modification should be done through file. Add the following lines to deployment.toml /repository/conf/deployment.toml . [authentication.framework.extensions] callback_factory = "org.wso2.carbon.identity.custom.callback.userstore.CustomUserStoreOrderCallbackFactory" 5. Start the server by issuing (Linux)/ (Windows) on terminal navigating to ./wso2server.sh ./wso2server.bat /bin 6. Navigate and click on Main -> Registry -> Browse Browse . 7. Navigate to You will find a file named (This file is defined in the class as ) Click on _system -> config . userstore-metadata.xml CustomCallbackUserstoreServiceComponent REG_PATH userstore-metadata.xml . 8. Click button in tab. It will appear as follows. These values will be used when authenticating users. + Properties Now try to log into the travelocity.com using the username-password pairs we introduced at the beginning. The result: Users in PRIMARY/ MANAGER/ DRIVER user stores will log into the system. Users in the CUSTOMER user store will fail to login. We are done!! Don’t forget to applause if you get something by this blog. Previously published at https://medium.com/@anuradha.15/how-to-configure-your-preferred-user-stores-to-authenticate-users-for-a-service-provider-in-wso2-cdadf43f9366