WCF的安全审核——记录谁在敲打你的门

WCF所谓的安全审核就是针对认证和授权所做的针对EventLog的日志记录。我们不但可以设置进行审核的事件（认证成功/失败，授权成功或失败），还可以选择记录信息被写入的EventLog类型，即应用程序日志（Application）还是安全日志（Security）。WCF的安全审核是通过ServiceSecurityAuditBehavior服务行为实现的。

一、ServiceSecurityAuditBehavior服务行为

针对WCF安全审核的编程只涉及ServiceSecurityAuditBehavior服务行为。下面给出了定义在ServiceSecurityAuditBehavior中具体审核行为进行控制的三个可读写的属性。

 1: public sealed class ServiceSecurityAuditBehavior : IServiceBehavior

MessageAuthenticationAuditLevel和ServiceAuthorizationAuditLevel两个属性分别代表针对认证和授权审核的级别。所谓审核的级别在这里指的应该在审核事件（认证和授权）在成功或者失败的情况下进行日志记录。审核级别通过具有如下定义的AuditLevel枚举表示。Success和Failure代表分别针对认证/授权成功和失败进行审核日志。SuccessOrFailure则意味着不管认证/授权是成功还是失败，都会进行审核日志。None为默认值，表示不进行审核日记记录。

布尔类型的SuppressAuditFailure属性表示审核日志失败是否会影响应用本身。在默认的情况下该属性值为True，意味着为认证和授权进行审核日志的时候出现的异常不会对应用（服务）本身造成任何影响。

既然是服务行为，我们就可以通过将创建的ServiceSecurityAuditBehavior添加到服务的行为列表的方式来进行安全审核的控制。当然我们还是推荐采用配置的方式来进行安全什么的相关设置。服务行为ServiceSecurityAuditBehavior对应的配置节是 serviceSecurityAudit 。在下面的配置中，我定义了一个包含了ServiceSecurityAuditBehavior的服务行为，并对其四个属性进行了显式设置。

二、安全审核的实现

WCF最终进行安全审核的控制信息是从基于某个终结点的分发上下文中获取的。如下面的代码片段所示，对于定义在ServiceSecurityAuditBehavior中的四个属性，在DispatchRuntime中具有相应的定义。WCF在认证和授权成功或者失败的时候，会根据该运行时这四个属性进行相应安全审核日志。

而作为服务行为的ServiceSecurityAuditBehavior，最终的目的就是将定义在自身的这四个属性赋值给分发上下文。而具体操作定义在ApplyDispatchBehavior方法上，整个逻辑大体上如下面的代码所示。

 4: public void ApplyDispatchBehavior(ServiceDescription serviceDescription, 

 10: foreach (EndpointDispatcher endpointDispatcher in channelDispatcher.Endpoints)

 14: dispatchRuntime.MessageAuthenticationAuditLevel = this.MessageAuthenticationAuditLevel;

 15: dispatchRuntime.ServiceAuthorizationAuditLevel = this.ServiceAuthorizationAuditLevel;

三、实例演示：如何实施安全审核

接下来我们通过一个简单的实例来演示如何进行针对认证和授权的安全审核，并且看看在认证或者授权成功或者失败的情况下，会有怎样的日志信息被记录下来。

基于认证的安全审核

先来演示针对认证的安全审核。我们还是直接使用一直在使用的计算服务的例子，服务契约和服务的定义我们已经很熟悉了，我们现在只来介绍采用的服务端的配置。从下面的配置可以看出，被寄宿的服务具有为一个基于WS2007HttpBinding的终结点，该绑定采用默认的Windows认证。通过服务行为，我们将安全审核的AuditLogLocation和MessageAuthenticationAuditLevel分别设置为Application和SuccessOrFailure。

客户端利用如下的代码进行服务的调用，两次服务调分别采用Foo和Bar两个本地Windows帐号进行，其中基于帐号Foo给定的密码是正确的，而基于帐号Bar给定的密码是错误的。而辅助方法Invoke旨在避免避免认证失败导致的异常是程序终止。

 1: ChannelFactory ICalculator channelFactory = new ChannelFactory ICalculator ("calculatorService");

 2: NetworkCredential credential = channelFactory.Credentials.Windows.ClientCredential;

由于我们通过配置将应用在服务上的ServiceSecurityAuditBehavior服务行为的AuditLogLocation和MessageAuthenticationAuditLevel分别设置为Application和SuccessOrFailure，意味着不论是认证成功或者失败都会进行安全审核日志。而审核日志最终会被写入EventLog的应用程序日志。当程序执行后，在事件查看器的应用程序节点，你会发现具有如下图所示的4条新的日志（之前的日志在程序运行前被清空）。

下面列出了这4条日志的内容。其中前3条基于认证成功的信息（Information）日志，最后一条是基于认证失败的错误（Error）日志。[源代码从这里下载]

 4: ClientIdentity: Jinnan-PC\Foo; S-1-5-21-3534336654-2901585401-846244909-1006

 11: ClientIdentity: Jinnan-PC\Foo; S-1-5-21-3534336654-2901585401-846244909-1006

 17: ClientIdentity: Jinnan-PC\Foo; S-1-5-21-3534336654-2901585401-846244909-1006

 26: Win32Exception: The Security Support Provider Interface (SSPI) negotiation failed.

基于授权的安全审核

接下来我们演示授权的安全审核，并查看分别在授权成功和失败的情况下分别由怎样的日志被写入到EventLog中。我们首先按照如下的方式在服务类型CalculatorService的Add方法上应用PrincipalPermissionAttribute特性使该方法只有在管理员才有权限调用。

然后我们将服务端配置中关于安全审核的相关配置进行了如下的修改。我们只关心授权相关的安全审核，所以将messageAuthenticationAuditLevel属性替换成serviceAuthorizationAuditLevel。

客户端在进行服务调用的时候需要为帐号Bar指定正确的密码。和前面一样，这里的帐号Foo被预先添加到管理员用户组中，而Bar则没有，所以只有第一次服务调用才是被成功授权的。

 1: ChannelFactory ICalculator channelFactory = new ChannelFactory ICalculator ("calculatorService");

 2: NetworkCredential credential = channelFactory.Credentials.Windows.ClientCredential;

当客户端完成两次服务调用后，如下两条基于授权的审核日志被写入应用程序日志。虽然只有第一次服务调用才是真正被授权的操作，但是从日志的内容我们却发现两条均是“授权成功”的审核日志。[源代码从这里下载]

 4: ClientIdentity: Jinnan-PC\Foo; S-1-5-21-3534336654-2901585401-846244909-1006

 12: ClientIdentity: Jinnan-PC\Bar; S-1-5-21-3534336654-2901585401-846244909-1007

实际对于安全审核中所谓的授权失败指的是调用ServiceAuthorizationManager的CheckAccess方法返回False的情况。在默认的情况下，ServiceAuthorizationManager的CheckAccess方法总是返回True，所以授权总是会“成功”。

为了迎合安全审核对“授权失败”的判断，我在Service项目中创建了如下一个简单的自定ServiceAuthorizationManager。在重写的CheckAccessCore方法中，如果当前用户是Foo（Jinnan-PC\Jinnan）就发返回True，否则返回False。

 4: public class MyServiceAuthorizationManager : ServiceAuthorizationManager

 6: protected override bool CheckAccessCore(OperationContext operationContext)

 8: string userName = operationContext.ServiceSecurityContext.PrimaryIdentity.Name;

然后通过如下的配置将这个自定义的MyServiceAuthorizationManager应用到ServiceAuthorizationBehavior服务行为上。再次运行我们的程序，将会得到分别代表授权成功和失败的两条审核日志，并且在日志中还包含了我们自定的ServiceAuthorizationManager类型（ServiceAuthorizationManager: MyServiceAuthorizationManager）。[源代码从这里下载]

 7: serviceAuthorization serviceAuthorizationManagerType="Artech.WcfServices.Service.MyServiceAuthorizationManager, Artech.WcfServices.Service" 

 4: ClientIdentity: Jinnan-PC\Foo; S-1-5-21-3534336654-2901585401-846244909-1006

 12: ClientIdentity: Jinnan-PC\Bar; S-1-5-21-3534336654-2901585401-846244909-1007

微信公众账号：大内老A
微博：www.weibo.com/artech
如果你想及时得到个人撰写文章以及著作的消息推送，或者想看看个人推荐的技术资料，可以扫描左边二维码（或者长按识别二维码）关注个人公众号（原来公众帐号蒋金楠的自媒体将会停用）。
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。 原文链接

基础逻辑门 Verilog HDL 设计语言支持3种设计风格： 门级，数据流级和行为级。 门级和数据流级设计风格通常用于设计组合逻辑电路，而行为级设计风格既可以用于设计组合逻辑电路又可以设计时序逻辑电路。本次实验通过使用Vivado 2015.1软件工具，以Basys3和Nexys4 DDR开发板为目标板，设计简单的组合逻辑电路来展示3种设计风格的用法。请参考Vivado手册了解如何使用Vivado工具创建工程并验证数字电路。