Hi Frank, yes, one of the main requirements I am trying to address is handling adding duplicate users. Also as I mentioned in my previous mail, we need a way so that an admin user can see list of people with those who are still in workflows and not accepted.
Thanks On Wed, Jul 22, 2015 at 5:37 PM, Frank Leymann <[email protected]> wrote: > Dear Chamila, > > in summary, you are implementing a "pessimistic offline lock", right? > http://martinfowler.com/eaaCatalog/pessimisticOfflineLock.html > > > Best regards, > Frank > > 2015-07-22 7:23 GMT+02:00 Chamila Wijayarathna <[email protected]>: > >> 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 >> >> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *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
