Web服务中的安全规范

Web服务中的安全规范

Web服务安全与WS-Security 毫无疑问，SOAP和XML使得Web服务在交互操作和标准上，已经完全改变了电子商务领域的应用格局。 然而，直到近期，在Web服务技术领域仍然存在着一些缺憾，那就是处理消息级别的安全、认证、加密、数字签名、路由和附件等问题的能力有待提高。为了解决这些安全问题，像IBM、Microsoft和Verisign等公司与一些组织机构牵头，合作制定了统一的Web服务安全规范，以便利用他们原有的Web服务交互操作概念和商业模型，推出了WS-Security（也称Web服务安全语言）等规范。可以这么说，自从SOAP规范形成以后，WS-Security规范及其后续的工作可能是Web服务技术领域的一次最重要的进步。 WS-Security 描述通过消息完整性、消息机密性和单独消息认证，提供质量保障对 SOAP 消息传递的增强。这些机制可以用于提供多种安全性模型和加密技术。 WS-Security 还提供关联安全性令牌和消息的通用机制。WS-Security 不需要特定类型的安全性令牌，它在设计上就是可扩展的（例如支持多安全性令牌格式）。举例来说，客户机可能会提供身份证明和他们有特定商业认证的证明。 另外，WS-Security 还描述如何对二进制安全性令牌编码。此规范特别描述如何对 X.509 证书和 Kerberos 票据编码以及如何加入难于理解的加密密钥。它还包括可以用于进一步描述消息中包含的凭证特征的扩展性机制。 随着WS-Security规范的定稿，各大软件厂商开始考虑为其产品提供和使用相同Web服务安全语言的接口和编程工具箱，Web服务的开发者也将使用这些厂商提供的工具，加强开发Web服务的安全性。 用户名安全令牌认证 在数字签名SOAP消息之前，必须先弄清楚谁正在签名。因此，必须先探讨一下用户名安全令牌（UsernameToken）的概念。 用户名安全令牌认证是一种很重要的安全技术。用户名安全令牌非常容易理解：Web服务为每位用户都分配了唯一的用户名和密码，如果该用户需要访问资源或功能，那么需要进行用户名密码验证，从而在一定程度上保护了与该用户名关联的资源和服务。因为大多数用户已经习惯了这种安全技术，所以用户名安全令牌认证对部署并保护Web服务非常有益。 在Web服务中，可以非常容易地实现用户名安全令牌认证：每一种Web方法调用都需要两个额外的参数，这就是用户名和密码。调用Web方法时，第一步就是在数据库中检查该用户名是否存在，第二步则是检验用户所输入的密码是否与数据库中该指定用户名的密码相符。只有通过了这些验证过程，才可以继续Web方法的操作。如果在这些验证步骤中哪怕只有一步不能通过，Web方法也会发送错误消息。 在WS-Security中定义了一个用户名安全令牌元素，它提供了基本用户名/密码验证的方法。如果你有使用HTTP的经验，那么你会发现WS-Security中的用户名安全令牌与HTTP中的基本验证非常相似。 不管使用明文密码，还是使用摘要密码，都需要在Web服务器上存储用户名/密码。这些信息通常保存在数据库中，占用额外的存储空间，并且需要额外的服务请求，这在一定程度上影响了Web服务的性能。同时，企业内部员工和黑客也可能会进入数据库获取这些客户信息，加大了安全隐患。 二进制安全性令牌认证 在WS-Security中，除了用户名/密码验证外，另一种验证用户身份的方法是使用 X.509 证书和Kerberos票据。 X.509 证书能够确切告知用户的身份。可使用 PKI（公钥基础机构） 将此证书映射到Web服务中的现有用户，但是黑客经常会重复攻击证书验证。因此，为防止破坏，消息发送方最好也同时使用他们的私钥来签名消息。这样，当解密消息时，系统会得知它确实来自该用户。 同时，在WS-Security中还定义了一个二进制安全令牌元素BinarySecurityToken，用来保存X.509 v3证书和Kerberos v5票据。当消息发送 X.509 证书时，将在二进制安全令牌中传递此证书的公共版本。证书是以 base64 编码数据的形式发送。在使用 X.509 证书时，还需要进行一些其他操作（例如签名消息）。使用证书的私钥创建的签名，可以证明客户端是该证书的合法拥有者。由于这种消息可能会被重复，因此为了防范与重复相关的问题，必须制订一个策略，以说明消息失效的时间。 要使用 Kerberos，用户需要提供一组凭据（例如用户名/密码或 X.509 证书）。如果通过所有的检验，安全系统将向用户授权一个 TGT（Ticket Granting Ticket，票据授予票据）。票据授予票据是一个用户无法读取的隐藏数据，但必须提供它才能访问其他资源。通常，用户需要提供票据授予票据来获得服务票据。系统的工作流程经历了多种步骤：客户端到密钥发行中心验证身份，并被授予一个票据授予票据；客户端获取证书授予证书并使用它来访问票据授予服务；客户端为访问Web服务而请求一个服务票据。然后，票据授予服务向客户端提供服务票据；客户端向Web服务出示此服务票据，并使用服务票据指示的权限访问资源。 Kerberos包含了客户端向Web服务证明身份以及Web服务向客户端证明身份的机制。服务票据只适用于访问一个Web服务，并可用于发现调用方的身份。当在消息中提供 Kerberos 票据时，需要将该数据加密复制到消息中。 正确使用签名 消息想要在传送过程中不被篡改，必须对消息进行签名操作。使用签名，SOAP 消息的接收方可以知道已签名的元素在传送过程中未被篡改。只要有可能，就应当使用 XML 签名对消息进行签名。WS-Security 只是简单解释了如何使用签名来证明消息没被篡改。 身份验证机制提供了对消息进行签名的方法，从而可以确定两个事项：由用户名安全令牌、X.509证书或Kerberos票据标识的用户已对消息进行了签名；签名后的消息没有被篡改。显而易见，身份验证机制提供了一个可用于签名消息的密钥，可以使用密码对用户名安全令牌进行签名。而X.509 允许发送方使用他们的私钥签名消息。Kerberos则提供了一个由发送方创建并在票据中传输的会话密钥，只有此消息的预期接收方才能够读取票据，发现会话密钥并验证签名的可靠性。 前面说过，签名是使用 XML 签名生成的，如果只对简单的消息签名，那么消息中的每个元素几乎都需要单独进行签名。每当元素发生改变时，都需要更新签名，否则将会出现异常。这是因为内容发生改变，签名将不再匹配。在SOAP消息中，签名所需的数据添加了大量额外信息。 加密数据 但是，只认证消息发送方的身份并证明消息未经篡改还远远不够，还需要加密数据，使得只有预期接收方才能阅读此消息。任何监视网络交换的人，即使获取了此消息，也读不出消息的内容。为此，WS-Security也提供了数据加密的相应规范。它采用了现有标准，并能很好地完成加密工作。 加密数据时，可以选择使用对称加密或不对称加密。对称加密需要一个共享密钥，即使用同一个密钥来加密消息和解密消息。如果同时控制两个端点并且可以信任使用密钥的用户和应用程序，则可以使用对称加密。通常采用邮寄磁盘提供密钥，或者通过协商确定提供密钥的方式，把密钥发送给需要的接收方。 如果您需要使用简单的分布式密钥来发送数据，则可以使用不对称加密。X.509证书允许接收数据的端点可以公布它的证书，并允许任何人使用公钥来加密信息，只有接收方知道私钥。因此，只有接收方可以得到加密的数据并将其重新转换为可读内容。 在许多专家的支持和部分读者的参与下，我们围绕着“Web服务”以及相关话题，前后进行了7次探讨，今天算是为这次探讨暂时画上一个句号。 尽管探讨所涉及的内容还欠缺广泛性和深入性，但是这种探讨，起码让大家对“Web服务”有一个基本的了解和认识。这即是我们的初衷，更是我们组织这次“Web服务专题”的目的。