Thanks, Chamila :-) And you get the list of people easily from the database table...
Best regards, Frank 2015-07-22 14:31 GMT+02:00 Chamila Wijayarathna <[email protected]>: > 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 > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
