虽然有许多人对WCF 安全性表示怀疑，但在年复一年的不断发展中，他的安全性也在不断提高。保障WCF 安全性是完全有可能的，但前提是要深入理解到底什么是WCF 安，及他是怎么运作的。
WCF 安全性到目前为止是 Windows® Communication Foundation (WCF) 最复杂的领域。在服务端的每次 WCF 操作调用中，安全都由服务契约、操作契约、错误契约（如果存在）、服务行为、操作行为、宿主配置和方法配置及其代码等控制。其中的每一项都可以具有十二个或更多个与安全相关的属性，如图 1 所示，该图描述了 ServiceHostBase（ServiceHost 的基础）的多个安全属性。
.gif)
不仅有多得吓人的详细信息要掌握，同时在各个部件之间还存在复杂的关系，由此产生了大量可能的排列组合。更加复杂的问题是，并不是所有组合都是允许或受支持的，所有允许的组合亦不全都是合理或有意义的。
毫不奇怪，编程模型非常复杂就强烈意味着在应用程序级别和业务级别容易出现问题。允许跨供应商、信任、平台和技术边界进行安全通信这个目标的底层复杂性导致了上述结果。任何延伸都不是一项简单的任务。但是，与 WCF 的其他方面（如事务、同步和实例化）不同，安全性没有用于进行配置的属性或一站式方法。开发人员仅可以控制现成的原始WCF 安全性模型。
有很好的理由不将高级安全编程模型包括在内：任何此类模型都不可能解决所有应用程序和方案，但是遗漏任何应用程序也是不明智的，因为安全在所有方案中都非常重要。
意识到不可能拿出一个为所有应用程序优化的统一的高级安全模型后，我问了自己这样一个问题：有没有一种模型对大多数应用程序都足够适用？虽然可解决所有方案的全面框架不可能实现，但我希望创建一种解决方案，可轻松为绝大多数情况配置安全设置。#t#
在此专栏文章中，我展示了自己的声明性安全框架。对于服务，我提供了一种安全属性；对于客户端，我提供了一些帮助器类和安全代理类。我的声明性框架使安全配置与 WCF 配置的其他方面相同。我想要一种声明性模型，该模型可单独使用并可将了解安全详情的需要降到最低。作为一名开发人员，您只需要选择正确的方案，我的框架会让配置自动进行。
此外，我的框架要求正确的选项并执行最佳实践。同时，我希望该模型可提供粒度和对底层配置的控制（如果需要此类控制）。
在本文中，我将着重讲述目标方案、我的框架如何实现以及如何使用该框架。我也会展示一些说明 WCF 安全性可扩展性的有趣的 WCF 编程技术（您可以从 MSDN® 杂志网站上下载该安全框架）。
