通过行为扩展WF和WCF之间的集成已经很广泛。行为可以在消息到达WorkflowRuntime之前或者在消息离开之后检测并增强它们。行为有访问完全消息的权限， 包括SOAP消息头。依赖于在服务描述中确定的安全模型， 不同的安全信息在SOAP消息头中从客户端发送给服务端。

  列表11.6中的例子显示了正在使用<windowsAuthentication>。 这指示WCF在SOAP消息头中序列化并发送Windows认证信息(通过线上加密)。includeWindowsGroups=true 设置指示WCF来包含当前用户所属的所有Windows组。这些设置一起使能工作流程序使其可以基于用户和组成员作出决定。

  对工作流特有的访问控制，接收活动内部构建了两个结构。首先，一个接收活动可以被配置来允许访问特定用户或者特定组中的用户。这是通过声明实现的。其次，一个接收活动可以有一个通过设置标志来分配或者拒绝访问操作权限的操作认证方法。这是通过程序实现的。这部分主要说明这些不同。

声明访问控制

有很多方式来控制对WCF服务的访问控制。第八章，”安全”，在细节中描述了这些，包括ASP.NET 角色，证书和Kerberos以及其他。除了WCF方法，WF也在接收活动中提供了一些。

  WF中的接收活动可以暴露服务的一个操作契约。当操作契约被添加到工程中后，一个对话框会提示配置参数，属性和权限。图片11.14显示了这个对话框。一个domain\username 可以输入到Name 字段，或者domain\group 输入到Role 字段。在运行时，在消息已经被服务接收到但没有分发给WorkflowRuntime时，将会有一个行为检查组成员权限。它通过查看消息头并再次比较对话框中的声明。如果消息从一个合法用户或组发出，操作就会被调用。否则，会访问一个安全异常。

计划性的访问控制

每个接收活动可以确定一个用来授权访问的方法。这个方法在操作契约被调用之前而且有机会允许或拒绝访问的时候被调用。方法名字存储在接收活动的OperationValidation属性中而且可以从WF设计器生成。在运行时，此方法在调用操作契约之前由WCF行为调用。它传输一个由客户端配置的包含所有声明的对象。这使它相对容易实现基于声明的授权。

 

图片11.14 在一个接收活动中声明认证

  让我们向货物交易/允许例子中添加一个新的需求: 初始化交易与允许这个交易的人不能是同一个。为了实现这个，我们需要做两件事情。在第一个接收活动(图片11.10)， 一个操作验证规则找到并存储初始化交易的用户名。在第二个接收活动中(图片11.11)一个操作验证规则比较请求授权的用户和初始化交易的用户。如果它们是同一个人，或者如果其中一个是空的，授权将会被禁止。

  列表11.12显示了一个用来确定发送给服务端的基于ClaimsSet的用户名的简单函数。这个函数与一些可预见的声明一起使用将会更具鲁棒性，比如那些在证书中的，但是对评估如何访问计划控制的服务操作，它是足够的。

列表11.12 从一个Windows ClaimSet 寻找声明名称的函数

  列表11.13 显示了如何使用findClaimName. receive1_OpValidation和receive2_OpValidation 两个函数由WF设计器生成。第一个函数把用户名存储在工作流类中一个变量里。如果它找不到用户名，它把IsValid设置为false, 拒绝调用。第二个函数比较当前用户名与之前用户名。如果它们一样，它把IsValid设置为false，再次拒绝调用。在这两种情况中，当它把IsValid=false，接收活动不调用操作契约。

列表11.13 操作验证方法