Hi all, Currently we are in the process of implementing Workflow support for user operations in IS 5.1.0. Recently we have identified following issue in the implementation. For the sake of the conversation let’s focus only on workflow support for 'addUser' operation.
Usually when a user is added to a user store it will go through following 3 steps. 1. UserOperationEventListener.doPreAddUser 2. UserStoreManager.doAddUser 3. UserOperationEventListener.doPostAddUser Workflow integration for 'addUser' operation is currently implemented as follows. We have implemented a UserOperationEventListner in workflow-mgt component whose 'doPreAddUser' hook is called when a user is added through addUser of the UserStoreManager. Then it will trigger a workflow for this task, save the request data and workflow related metadata in a database table (not in user store, separate table introduced), and then will return false, which will stop the further processing of addUser listeners and the operation itself. When the workflow is completed, in its callback method, it will again call 'addUser' method of UserStoreManager where this time it executes all 3 steps, pre-hooks, operation and post hooks, except for the workflow pre-hook. So user will be added to the user store only when the workflow is completed. We came up with 2 limitations of this approach which needs to be addressed. 1. When a ‘addUser’ workflow is triggered, it should not be possible to add another user with same userName. Right now we can’t find this out until the second workflow to be approved, tries to insert the user to the userstore. 2. Admin user should be able to see the list of users who are in the queue to be added once the workflows are approved. To overcome these limitations, first we came up with the following approach. When user is added and workflow is started, he should be added to the userStore (so adding new users will be prevented from userStore level and list users is also possible as usual). To do this we have to execute 'doPreAddUser' and 'doAddUser' methods when user is added, but also keep a claim saying he is locked or pending, which will prevent modifications or authentication for the user. However we need to prevent the post listeners from executing because the actual user provisioning is not actually completed. E.g. one of the post listeners we have provisions users to external Identity Providers, which can’t happen until the workflow is approved. Of course we can provision him to external system and in case the workflow is rejected we can deprovision the same user in the callback, but the drawback is between such time the user will be like a valid user in the external system. Then once the workflow is accepted it will unlock user as well as execute doPostAddUser which do the outbound provisioning, etc. Basically what we need is to be able to control the execution of the pre-hooks, operation and post-hooks independently from the rest. But for now we can't implement it in this way, since this needs few API changes in user core, which is in carbon4-kernel and there won't be a release of kernel with API changes before IS 5.1.0 release. So we decided to do this in following way. User addition will remain the same, i.e. user will not be added the userstore until workflow is approved, but using the workflow related metadata table we can cater the 2 requirements stated above. That is identify the conflicting scenarios, e.g. adding users with same username and listing the users that are still under processing. The same scenario can be extended to all other user operations as well, such as addRole, updateRoleListOfUser, etc. Thank You! -- *Chamila Dilshan Wijayarathna,* Software Engineer Mobile:(+94)788193620 WSO2 Inc., http://wso2.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
