[Architecture] IS Workflow Implementation - Issues in AddUser Workflow
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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] IS Workflow Implementation - Issues in AddUser Workflow
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 : > 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 > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] IS Workflow Implementation - Issues in AddUser Workflow
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 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 : > >> 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 >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
Re: [Architecture] IS Workflow Implementation - Issues in AddUser Workflow
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 : > 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 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 : >> >>> 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/ >>> >>> ___ >>> Archite
Re: [Architecture] IS Workflow Implementation - Issues in AddUser Workflow
Yes, the list of people who are not in the userstore since they are in a workflow. On Thu, Jul 23, 2015 at 4:12 PM, Frank Leymann wrote: > 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 : > >> 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 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 : >>> 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,
Re: [Architecture] IS Workflow Implementation - Issues in AddUser Workflow
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 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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
