从一个工作流流转中人员设定的例子看WBISF流程引擎所定义的用户授权安全模型

流程场景

1) 贷款申请者在HTML页面上输入用户贷款的详细信息，主要包括用户身份证号及申请金额等。在完成以上内容的填写后，用户点击提交按钮，此时后台的处理程序首先判断用户输入是否合法，如果不合法则拒绝用户提交的内容，如果合法则调用流程API启动一个新的流程来响应用户请求，并将用户输入数据传入流程实例。

2) 当流程启动成功后，信贷申请首先必须经过信贷审批员的审核。在信贷审批员的工作条目列表中将出现一个新的工作项，信贷审批员点击该项，页面上将会出现信贷申请者的详细信息，如用户身份证号、申请金额及用户以往信用纪录等。如果用户信用记录较好，则信贷审批员可以直接批准。如果用户信息记录较差，信贷审批员可以直接拒绝用户的贷款申请。在以上任何一种情况下，部门经理接下来都必须批准审批员的审核结果。

3) 信贷审批员完成贷款申请审核后，信贷部门经理的工作条目列表中将出现一个新的工作事项。部门经理点击该项，页面上出现信贷申请者的详细信息以及信贷审批员的评估结果。如果部门经理认可审批员的结论，则直接批准。最后，流程将审批结果呈现在贷款申请者的工作事项列表上。贷款申请者点击完成按钮，整个流程成功结束。

从以上需求我们可以看出，整个贷款申请流程共涉及到三类角色：贷款申请者、信贷审批员和信贷部门经理。贷款申请者在流程中是审批结果察看活动的潜在拥有者，并且是流程的启动者。信贷审批员负责第一轮的贷款申请审核，是该活动的潜在所有者。信贷部门经理负责第二轮的贷款申请审核，是该活动的潜在所有者。为简单期间，我们不妨假设用户存储仓库中已经存在三个用户：david是贷款申请者，peter是信贷审批员，john是信贷部门经理。

Specialist Approve活动的潜在所有者选择了Group Search的用户查询模版，即流程会按照组属性来确定用户身份，在GroupID参数域填入LoanSpecialist值，表明该活动只有流程管理员和LoanSpecialist组的成员才拥有相关权限来声明并完成该活动。在我们的用户注册表中，只有peter是 LoanSpecialist组的成员。

Manager Approve活动选择了User by user ID的用户查询模版，在UserID参数域填入john，表明只有流程管理员和部门经理john拥有足够的权限声明并完成该活动。

如果我们还希望在流程结束后能够察看流程运行的相关统计信息，必须为流程设定管理员。点击流程顶部的DebitProcess框，在属性视图中选择人员选项，在UserID属性域输入john，表明john作为管理员在流程运行过程中拥有最高权限，他不仅可以访问流程中任意活动的状态信息，而且可以在流程运行时终止并删除流程实例。