IIS授权以及身份验证

身份验证

如果 Web Services 输出敏感的、受限制的数据，或者提供受限制的服务，则需要对调用者进行身份验证。可用的身份验证方案有许多，大致可以分为以下三类：
• 平台级别的身份验证
• 消息级别的身份验证
• 应用程序级别的身份验证

平台级别的身份验证

如果可以同时控制这两个终结点，并且它们在相同的域或信任域中，则可以使用 Windows 身份验证对调用者进行身份验证。
基本身份验证

可以使用 IIS 来配置 Web Services 的虚拟目录，以便进行基本身份验证。如果使用此方法，客户必须配置代理服务器，并提供用户名和密码形式的凭据。然后代理服务器将其与通过此代理服务器的每个 Web Services 请求一起传输。凭据是以明文形式传输的，因此应仅使用有 SSL 的基本身份验证。

下列代码片段显示了 Web 应用程序如何提取最终用户提供的基本身份验证凭据，然后使用这些凭据调用 IIS 中的下游 Web Services 进行基本身份验证。

// 检索客户端凭据（可用于基本身份验证）
string pwd = Request.ServerVariables["AUTH_PASSWORD"];
string uid = Request.ServerVariables["AUTH_USER"];
// 设置凭据
CredentialCache cache = new CredentialCache();
cache.Add( new Uri(proxy.Url), // Web Services URL
"Basic",
new NetworkCredential(uid, pwd, domain) );
proxy.Credentials = cache;

集成的 Windows 身份验证
可以使用 IIS 来配置 Web Services 的虚拟目录，以便进行集成的 Windows 身份验证，从而根据客户端和服务器环境的不同进行 Kerberos 或 NTLM 身份验证。相对于基本身份验证，这种方法的优点是凭据不通过网络传递，从而排除了网络窃听的威胁。

要调用配置为集成 Windows 身份验证的 Web Services，客户必须显式地配置代理服务器上的“凭据”属性。

要以客户端的 Windows 安全上下文（来自模拟的线程令牌或进程令牌）覆盖 Web Services，可以将此 Web Services 代理的“凭据”属性设置为 CredentialCache.DefaultCredentials，如下所示。

proxy.Credentials = System.Net.CredentialCache.DefaultCredentials;

还可以使用如下所示的一组明确凭据：
CredentialCache cache = new CredentialCache();
cache.Add( new Uri(proxy.Url), // Web Services URL
"Negotiate",       // Kerberos 或 NTLM
new NetworkCredential(userName, password, domain));
proxy.Credentials = cache;

如果需要指定明确凭据，请不要将其硬编码或存储到明文中。可以使用 DPAPI 加密帐户凭据，并将加密数据存储在 Web.config 的 <appSettings> 元素中或受限制的注册表项下。

有关平台级别的身份验证的详细信息，请参阅“Microsoft patterns & practices Volume I, Building Secure ASP.NET Web Applications:Authentication, Authorization, and Secure Communication”中的“Web Services Security”部分，其网址为：http://msdn.microsoft.com/library/en-us/dnnetsec/html/secnetlpMSDN.asp?frame=true（英文）。
消息级别的身份验证

可以使用 WSE 来实现符合最新 WS-Security 标准的消息级别的身份验证解决方案。此方法允许使用 SOAP 头信息以标准形式传递身份验证令牌。

注意：如果双方同意使用 WS-Security，也必须就身份验证令牌的准确格式达成一致。

WSE 可以使用和支持下列类型的身份验证令牌：
• 用户名和密码
• Kerberos 票证
• X.509 证书

用户名和密码

可以在 SOAP 头信息中发送用户名和密码凭据。然而，由于它们是以明文发送的，存在网络窃听的威胁，因此该方法应与 SSL 一起使用。凭据是作为 SOAP 头信息中的 <Security> 元素的一部分发送的，如下所示。

<wsse:Security
xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext">
<wsse:UsernameToken>
<wsse:Username>Bob</wsse:Username>
<wsse:Password>YourStr0ngPassWord</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>

用户名和密码摘要

您可以发送密码摘要，而不是发送明文密码。摘要是 Base64（UTF8 的编码 SHA1 哈希值）编码的密码。然而，除非在安全通道上使用此方法，否则拥有网络监视软件的攻击者仍然可以截获数据，并重新使用这些数据来非法访问您的 Web Services。要解决这种重播攻击的威胁，该摘要可以结合 Nonce 和创建时间戳一起使用。

有 Nonce 和时间戳的用户名和密码摘要

在此方法中，摘要是 Nonce 值、创建时间戳和密码的 SHA1 哈希。

digest = SHA1(Nonce + creation timestamp + password)

此方法中的 Web Services 必须维护一个包含 Nonce 值的表，并拒绝包含重复 Nonce 值的任何消息。尽管此方法有助于保护密码，并为防止重播攻击提供了基础，但在计算过期日期时，客户与提供商之间会出现时钟同步的问题，而且它不能防止攻击者捕获消息、修改 Nonce 值，然后将此消息重播给 Web Services。要解决此威胁，必须对消息进行数字签名。通过 WSE，可以使用自定义的令牌或 X.509 证书对消息进行签名。此方法可以基于公钥/私钥对来防止篡改和提供身份验证。
Kerberos 票证

可以发送包含 Kerberos 票证的安全令牌，如下所示。
<wsse:Security
xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext">
<wsse:BinarySecurityToken
ValueType="wsse:Kerberosv5ST"
EncodingType="wsse:Base64Binary">
U87GGH91TT ...
</wsse:BinarySecurityToken>
</wsse:Security>

X.509 证书

还可以发送一个作为身份验证令牌的 X.509 证书来提供身份验证。
<wsse:Security
xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext">
<wsse:BinarySecurityToken
ValueType="wsse:X509v3"
EncodingType="wsse:Base64Binary">
Hg6GHjis1 ...      
</wsse:BinarySecurityToken>
</wsse:Security>

有关以上方法的详细信息，请参阅 WSE 附带的示例。
应用程序级别的身份验证

通过让应用程序使用自定义的 SOAP 头信息，可以设计和构建您自己的自定义身份验证。在此之前，应检查平台和 WSE 提供的功能，以查看这些功能是否可用。如果必须使用自定义身份验证机制，而且需要加密，可以使用 System.Security.Cryptography 命名空间提供的标准加密算法。
返回页首
授权

身份验证以后，根据调用者的身份或角色成员关系，可以将其限制在 Web Services 提供的部分功能内。可以限制对服务终结点（在 .asmx 文件级别上）、各个 Web 方法或 Web 方法内的特定功能的访问。
Web Services 终结点身份验证

如果将 Web Services 配置成集成的 Windows 身份验证，则可以基于最初的调用者的安全上下文，在 Web Services (.asmx) 的文件上配置 NTFS 权限来控制访问。这种授权是由 ASP.NET 的 FileAuthorizationModule 执行的，而且不需要模拟。

不管哪种类型的身份验证，都可以使用 ASP.NET 的 UrlAuthorizationModule 来控制对 Web Services (.asmx) 文件的访问。通过将 <allow> 和 <deny> 元素添加到 Machine.config 或 Web.config 中的 <authorization> 元素中，可以实现此配置。

有关这两种形式授权的详细信息，请参阅模块 19 确保 ASP.NET 应用程序和 Web 服务的安全中的“授权”部分。
Web 方法授权

可以根据调用者的身份或角色成员关系，使用说明性的主要权限需求来控制对每个 Web 方法的访问。调用者的身份和角色成员关系是由与当前的 Web 请求（通过 HttpContext.User 来访问）相关的主要对象来维护。

[PrincipalPermission(SecurityAction.Demand, Role=@"Manager")]
[WebMethod]
public string QueryEmployeeDetails(string empID)
{
}

有关主要权限需求的详细信息，请参阅模块 10 构建安全的 ASP.NET 网页和控件中的“授权”部分。
编程授权

通过调用 Web 方法中的 IPrincipal.IsInRole，可以使用命令性的权限检查或明确的角色检查，进行精确的授权逻辑，如下所示。

// 在此假设使用非 Windows 身份验证。使用 Windows 身份验证
// 将 User 对象转换为 WindowsPrincipal 对象并使用 Windows 组作为
// 角色名
GenericPrincipal user = User as GenericPrincipal;
if (null != user)
{
if ( user.IsInRole(@"Manager") )
{
// 授予用户执行管理功能
}
}
===========================