Security Specifications in Web Services |
|
Web Service Security and WS-Security There is no doubt that SOAP and XML have completely changed the application pattern in the field of e-commerce in terms of interoperability and standardization of Web services. However, until recently, there have been some shortcomings in the field of Web services technology, that is, the ability to deal with message-level security, authentication, encryption, digital signatures, routing and attachments needs to be improved. In order to solve these security problems, companies such as IBM, Microsoft and Verisign have taken the lead with some organizations and cooperated to develop a unified Web service security specification, in order to use their original Web service interoperability concepts and business models, and launched WS-Security (also known as Web Services Security Language) and other specifications. It can be said that since the formation of the SOAP specification, the WS-Security specification and its follow-up work may be one of the most important advancements in the field of Web services technology. WS-Security describes enhancements to SOAP messaging that provide quality assurance through message integrity, message confidentiality, and individual message authentication. These mechanisms can be used to provide a variety of security models and encryption techniques. WS-Security also provides a common mechanism for associating security tokens and messages. WS-Security does not require a specific type of security token, it is extensible by design (eg supports multiple security token formats). For example, clients may provide proof of identity and proof that they have specific business credentials. Additionally, WS-Security describes how to encode binary security tokens. In particular, this specification describes how to encode X.509 certificates and Kerberos tickets and how to include obscure encryption keys. It also includes extensibility mechanisms that can be used to further characterize the credentials contained in the message. With the finalization of the WS-Security specification, major software manufacturers have begun to consider providing and using the same Web service security language interface and programming toolbox for their products. Web service developers will also use the tools provided by these manufacturers to strengthen the development of Web services. Security of Services. Username Security Token Authentication Before digitally signing a SOAP message, it must be figured out who is signing it. Therefore, the concept of UsernameToken must be explored first. Username security token authentication is an important security technique. Username security tokens are very easy to understand: the web service assigns each user a unique username and password, and if the user needs to access resources or functions, then username and password authentication is required, thus protecting the The resources and services associated with the username. Because most users are accustomed to this security technique, username security token authentication is very beneficial for deploying and securing Web services. In web services, username security token authentication can be implemented very easily: each web method call requires two additional parameters, the username and password. When calling the Web method, the first step is to check whether the user name exists in the database, and the second step is to check whether the password entered by the user matches the password of the specified user name in the database. Only after passing these verification procedures can the operation of the web method continue. If even one of these verification steps fails, the web method will send an error message. A username security token element is defined in WS-Security, which provides methods for basic username/password authentication. If you have experience with HTTP, then you will find that username security tokens in WS-Security are very similar to basic authentication in HTTP. Whether you use clear text passwords or digest passwords, you need to store the username/password on the web server. This information is usually kept in the database, which takes up additional storage space and requires additional service requests, which affects the performance of web services to a certain extent. At the same time, internal employees and hackers may also enter the database to obtain these customer information, increasing security risks. Binary Security Token Authentication In WS-Security, in addition to username/password authentication, another way to authenticate users is to use X.509 certificates and Kerberos tickets. X.509 certificates tell exactly who the user is. This certificate can be mapped to an existing user in the web service using a PKI (Public Key Infrastructure), but hackers frequently attack certificate validation repeatedly. Therefore, to prevent corruption, it is best for the sender of the message to also use their private key to sign the message. This way, when the message is decrypted, the system knows that it really came from that user. 同时，在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服务专题”的目的。 |