《WF编程》系列之47 第八章 工作流中的通信

核心提示： 尽管相关性记号在连接活动时很有用，我们不应该将其作为安全特性而依赖，《WF编程》系列之47 第八章 工作流中的通信(7)，只为，如果一个投票说它是来自技术组长， 为了支持不同的角色实现，WF提供了一个可扩展的角色管理方案，但并不表示这个投票真的来自于技术组长，在下一节

尽管相关性记号在连接活动时很有用，我们不应该将其作为安全特性而依赖。只为，如果一个投票说它是来自技术组长，但并不表示这个投票真的来自于技术组长。在下一节，我们将学会如何使用HandleExternalEvent活动的另一个属性——Role。

基于角色的授权

保护计算机资源的过程包括两个步骤。第一步是验证。验证确定了用户的身份。验证可能很简单，就像询问一个人的用户名和密码那样，或者更多地利用相关的生物特征信息，如指纹识别和视网膜扫描。WF不验证用户，但是当需要验证时，运行时将会依赖于软件中的验证机制。例如，以ASP.NET应用程序为宿主的工作流可能需要集成Windows验证的支持，或者可能依赖于ASP.NET的membership provider来对用户进行验证。

一旦用户的身份得到确定，我们就可以决定允许用户执行什么操作。这就是第二步——授权。授权规则通常听起来像是——只有经理才能审批报销单，或只有管理员才能取消操作。注意到这些规则涉及到像经理或管理员这样的用户分组。这是因为我们代表性地为用户指派角色并对它们基于角色的请求进行授权（这里，“基于角色的授权”是一个术语）。

在软件的世界中，角色管理软件别有一番风味。对于Windows领域中的软件而言，我们可能从它们的活动目录组成员中得到用户的角色。在面向公众的 ASP.NET的web应用程序中，我们可以从ASP.NET的Role Provider中得到用户的角色。

为了支持不同的角色实现，WF提供了一个可扩展的角色管理方案。WF提供了一个名为WorkflowRole的抽象基类。这个类的内嵌实现为Windows活动目录和ASP.NET 2.0角色提供者提供了角色管理：