Hi all, Matrix in [1] shows how userStore operation we are currently considering with workflows affects to each other and how we are planning to handle them.
Please add you suggestions on if there is anything to be changed or added. Thanks. 1. https://docs.google.com/a/wso2.com/spreadsheets/d/1CwPSOfe_ROlWj2WvMSqyn4S-N0JKmLFvYPpgWQUCqUM/edit?usp=sharing On Wed, Jul 22, 2015 at 10:53 AM, Chamila Wijayarathna <[email protected]> wrote: > 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/ > -- *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
