发展历程

1/3

在今天的软件环境中，应用程序的来源很多，它们执行很多任务。对应用程序代码的信任是一个主要需求，因为我们谁也不想软件或信息遭到破坏。给予许可的安全策略不会允许对敏感信息的不适当的访问，或将本地机器暴露给恶意的程序或甚至是有平常错误的代码。1

过去，安全结构提供了基于用户帐号的隔离和访问控制--在这些限制内给予代码完全访问权，并假定由特定用户可运行的代码具有相同的信任度。不幸的是，如果所有程序都代表某用户运行，根据用户对代码的隔离对于保护一个程序不被其它用户使用是不够的。另一种情况，不能被完全信任的代码经常被转移到"沙箱"模型中执行，在此代码运行于隔离环境，而不会访问大部分的服务。

对今天应用程序的成功的安全解决方案必须能强化两个安全模型间的平衡。它必须提供对资源的访问，以便以完成有用的工作，它需要对应用程序的安全性作细致的控制以确保代码被识别，检测，并给予合适的安全级别。.NET Framework就提供了一个这样的安全模型。

主要功能

安全性能

调用的"自由"安全性

2一些活动，如读写文件，显示对话框，读写环境变量，可以通过包含在框架安全构架中的.NET Framework方法实现。这就使.NET Framework能根据安全策略允许或不允许一个操作，而不需要程序员做额外的工作。尽管暴露了保护资源的管理类的创建者在他们的库中做了明确的安全需求，使用.NET Framework类库访问受保护资源的开发人员可以自由地利用代码访问安全系统；他们不必作出明确的安全调用。

管理员可以通过决定给予哪些许可来优化安全策略，然后，依靠.NET Framework处理所有的安全操作。代码访问安全能阻止大部分的恶意攻击，对代码的验证减少了缓存溢出和其它会导致安全攻击的不期望的行为。因此，应用程序和组件生来就受到了保护，它们免于大多数安全问题的冲击，而这些安全问题一直困绕着本地代码的实现。

基于角色的安全

有时根据已认证的身份或根据与代码执行上下文相关的角色作出认证决定是合适的。例如，金融和企业软件可以通过评估角色信息的企业逻辑加强策略。根据作出请求的用户角色可以对金融交易的数据进行限制。出纳被允许可以处理一定金额的请求，而多于该金额的所有工作需要监督人的角色来处理。

身份可以映射到登录系统的用户，或由应用程序定义。相应的原则封装了身份和其它相关的角色信息（例如，但并不限于此，用户的"组"由操作系统定义）。

认证和授权

认证是一个过程，它接收来自用户的证书，并对证书的授权进行确认。如果证书是有效的，那么用户就可以说他拥有已认证的身份。而授权的过程是：确定认证用户是否能够访问给定的资源。认证可通过系统或企业逻辑来完成，通过某个API它是或获得的。认证API是完全可扩展的，因此开发人员根据需要使用自己的企业逻辑。开发人员可以对他们的认证需求进行编码，也可以修改底层的认证方法而无需对他们的代码作太大变化。除了微软Windows?操作系统身份认证外，还有的认证方法包括基本HTTP，摘要和 Kerberos，以及微软Passport和基于窗体的认证。这些认证方法已经完全集成到中了。

在窗体认证中，用户提供证书，并提交窗体。如果应用程序簦别请求，系统发送一个cookie ，该cookie以某种形式包含包含了证书或包含重新获得身份的关键字。接下来发送的请求在头中包含了cookie，处理程序通过应用程序所期望的任何有效方法对这些请求认证和授权。如果请求没有经过认证，HTTP客户端将用于把请求发送到认证窗体，在那里用户可能提供信任证书。窗体认证有时用于个性化--为已知用户的内容进行定置。在一些情况下，身份是问题所在而不是认证，因此用户的个性化信息可以简单地通过访问用户或获得。

授权的目的是确定作出请求的身份是否被给予了对给定资源的访问权。提供了两种类型的授权服务：文件授权和URL授权。文件授权根据正在作用的方法和作出请求的身份决定用户使用于哪个访问控制列表。URL授权是URI名称空间和不同用户或角色间的逻辑映射。

隔离存储

.NET Framework提供了一个特殊的功能，隔离存储，用于存储数据，甚至是当不允许对文件进行访问时--例如，当从Internet下载了一个管理控件，并运行它，为它提供了有限的许可权但没有权力读写文件。