Introduction
Before introducing WS-Security, we need to know why WS-Security exists. Many people who have just contacted the Web service will see SOAP as a method of exchanging messages between two endpoints through HTTP. You can verify the identity of the caller by HTTP, encrypt the message sign, and the message content. This can ensure the security of the message in the following: The calling party is known, the message recipient can verify that the message is not changed during the transmission process, and the entity that monitors the network communication cannot recognize the exchanged data. However, if you are ready to use SOAP messaging to solve some complex problems, it is not enough based on HTTP-based security. These complex problems typically relate to path send messages along a more complicated relative to request / response, or do not use HTTP to transmit. The caller and the logo, integrity, and security need to be retained in multiple hops. Multiple encryption keys may require multiple encryption keys along the route. Also span the trust domain. HTTP and its safety mechanism are only safe to point to the point. More complex solutions require end-to-end security. WS-Security is solved how you maintain a safe environment in a multi-point message path.
Note This article assumes that the reader is already familiar with the XML standard, XML signature and XML encryption.
WS-Security implements security by using existing standards and specifications, so you don't have to define a complete security solution in WS-Security. The industry has solved many such problems. For example, Kerberos and X.509 are used for authentication; X.509 also uses an existing PKI to perform key management; XML encryption and XML signature describes encryption and signature methods for XML message content; XML standard describes the signature and encryption Prepare XML methods. WS-Security adds a framework to an existing specification to embed these mechanisms into the SOAP message. This is done in a way that is not related to the transmission.
WS-Security defines a SOAP header element for carrying security related data. If you use an XML signature, this header can contain information defined by the XML signature, including the signature method of the message, the key used, and the resulting signature value. Similarly, if an element in the message is encrypted, the WS-Security header can also contain encrypted information (eg, encrypted information defined by XML encryption). WS-Security does not specify a signature or encrypted format, but specifies how to embed security information defined by other specification in the SOAP message. WS-Security is primarily a specification for XML-based security metadata containers.
In addition to using other existing message authentication, integrity and encryption, WS-Security also provides? It specifies a use of UserNameToken. Elements Transfer Mechanism of Simple User Credentials. In addition, in order to send a binary token for encryption or signature messages, a binarysecurityToken is also defined. In this header, the message can store information about the signature method and encryption method of the caller, message. WS-Security saves all security information in the SOAP section of the message, providing end-to-end solutions for Web service security.
In this article, we will learn how to embed a security mechanism in the SOAP message using WS-Security and other mating tools. We will understand the three aspects involved in WS-Security:
• Authentication • Signature • Encryption
These three aspects reflect the security of safety and answered the following questions:
• Who is my authorization object? • Is the message changed between the hop? • Does the message come from the expected sender? • How to hide only what you want to see?
First, let's take a look at some similar situations in your daily life.
Similar situations in daily life
To understand the functionality of WS-Security, you can first look at the similar situation in real life. Specifically, when will you use the documents in your daily life? After all, everyday life is always inseparable from various documents. If someone asks you to prove their age, you will take a driver's license from the wallet. If you don't have to pay for the merchandise, you will use a credit card to prove your identity to the lending agency. When crossing the border or abroad, you need to use a passport to prove your identity. All of this is a document. Its role is to explain that the credit card, the driver's license, and the person of the passport are consistent with people in the documents. But they do not verify your identity. Verification is a behavior, and the document itself does not implement this line. When using a written document, people are actors of authentication. So how is the verification process implemented? When you present a driver's license or passport, the person who views the document will perform some operations to verify that the documents are true, and whether you are the legitimate owner of these documents:
• Both of these documents contain photos and other identity features of document registration holders: height, weight, and eye color. The person viewing the document ensures that you consistent with the people displayed and described. • The documents have certain payments. This ensures that the data in the documents is the latest data. • The document contains the signature and can be compared to the signature of the person presentation. Accurately mimicing the signature of others is difficult, so the documents become a reasonable authentication method by combining the description of the handlers of the documents.
There are other important features of these documents. The tag on the document can enable people to quickly verify the authenticity of the documents. The document is issued by our agency that we trusts to provide valid identity information: local or national government. The credit card is also mentioned above. It is different from the driver's license and passport.
• They are distributed by banks instead of government. • They only contain signs and names for identifying the identity of the card. • They can only be used to verify identity when presenting other supported documents (such as IDs issued by the government).
So what can I do like a credit card?
Credit card usually only rely on signatures for authentication. Some credit cards come with photos to increase authentication of reliability. Since the authentication provided by the credit card is not sufficient, many institutions require the ID of the government to sign with the credit card. For security, when you present a credit card, you are declaring that you have the right to purchase goods and services, and provide you with your credit card will pay your merchant. The merchant can compare the ID of the photo from the government to confirm that you are a valid card. (Of course, if you trader via phone or Internet, it is another matter, but this also shows that there are other security mechanisms in these areas.)
Applicate existing concepts for SOAP messages
WS-security attempts to introduce a large number of identity and authentication concepts into the SOAP message. To make SOAP messages have a practical value, the message must contain information that can complete the following tasks:
• Identify one or more entities involved in the message. • Certificate entity has the correct member identity. • Certificate entity has the correct access set. • Proof messages have not been changed.
Finally, we need a mechanism to make information for unauthorized confidentiality. In daily personal authentication, I use my own driving license or passport to prove my identity; prove that I have some rights through the membership card; use the credit card in the wallet, I can buy goods and services, borrow from the library, Shopping a medical expense document to my insurer, enjoying the property in the local department store. WS-Security allows the same concept to SOAP messages. The message can contain the following information by using the security token to identify the caller and declare its permissions.
• Calling party ID: I am User Joe. • Group member identity: I am a developer of Coldrooster.com. • Permissions declaration: Because I am a developer.com's developer, I can create a database and add a web application to a computer of Coldrooster.com. To create a message, you can create a new database on a Coldrooster.com server using authentication techniques (such as Kerberos), and the application must get some security tokens. First, the application that creates this message needs to get a security token to prove that the application performs actions on behalf of the user Joe. User Joe provides this token when logging in with your username / password or using a smart card login. Suppose the system's security structure uses Kerberos and assumes that the environment used by JoE has a key issuance center for a Ticket Granting Ticket (TGT) when JoE login. When JoE decides to create a new database on Coldrooster.com, this environment goes to Ticket Granting Service, and requests a service ticket that indicates that JoE has the right to create a new database on Coldrooster.com. Environment After obtaining service ticket (ST), it provides it to the database server of Coldrooster.com. The database server verifies the validity of the ticket and then allows Joe to create a new process.
WS-security attempts to encapsulate the above security interaction process into a set of SOAP headers. WS-Security handles credentials in two ways. If the web service uses custom authentication, it defines a special element UserNameToken for passing the username and password. WS-Security also provides an element for providing binary authentication tokens (such as Kerberos Bills and X.509 certificates): binarysecurityToken.
Figure 1 shows a relatively common message flow form.
Figure 1. Typical message flow
Security token services can be Kerberos, PKI or username / password verification services. This service may not be based on a web service. In fact, the Kerberos service tickets allow access to the service through the Kerberos protocol (using the security feature of the operating system). After getting the token to be used in the message, the client embeds these tokens into the message. The client should sign the message using only the data they understand. The server can infer this signature in a variety of ways. If the client uses UserNameToken authentication, the client should send a hash password and use this password to sign the message. If the server matches the signature generated by the message, the server can verify the message sent by the client.
When using an X.509 certificate, you can use private keys to sign messages. The message should include a certificate in BinarySecurityToken. When using X.509, all people who understand the X.509 public key can verify this signature. Finally, if you use Kerberos, you can sign or encrypt the message using the session key embedded in the Kerberos bill. Since the Kerberos bill will be locked for the receiver of the token, only the recipient can decrypt this ticket, discover the session key, and verify the signature.
If authentication is important, it is critical to sign or encrypt SOAP messages. Why is this this? It is not enough because it only adds a valid identity token to the message. Attackers can remove these toys from the valid message and add them to their own messages. We also need to be able to determine that this message is created by objects identified by the message. If you do not use an XML signature to sign messages, you can't explain that the message is not changed or identified to the token is not abused.
At this point, I believe that you have already understood WS-Security. Let us take a deeper to see it. WS-Security SOAP header
From this section, I will use some XML code snippet. In order not to display all XML namespace declarations and messages, I use the following XML namespace:
Table 1: XML namespace
Name Space Description Namespace URI XS XML Schema http://www.w3.org/2001/xmlschema wsse WS-Security http://schemas.xmlsoap.org/ws/2002/07/secext WSU Utility Elements HTTP: / /www.w3.org/2001/xmlschema soap soap elements http://schemas.xmlsoap.org/soap/envelope/
The WS-Security specification defines a new SOAP header. In order to understand the contents of the WS-Security SOAP header, we first take a look at the architecture of this element.
Minoccurs = "0" maxoccurs = "unbounded"> As shown above, the Security header element allows any XML elements or properties to be included therein. This makes the header to adapt to any safety mechanism required for the application. If this sounds a bit blame, we can think about the working way of the SOAP header and the body. The header and the body can contain an XML element collection. In addition to the unable to include XML processing instructions, SOAP specifications have almost no statements for these elements. WS-Security requires this structural type due to the functionality that the header must provide. It must be able to carry multiple security tokens to identify authority and identity of the caller. If the message has been signed, the header must contain information about the signature method of the message and the key information storage location. The key may be included in the message or stored elsewhere and is for reference only. Finally, information about encryption must also be included in this header. So how do the middle part know what it has WS-Security? A SOAP message may contain multiple WS-Security headers. Each header is identified by a unique actor. Two WS-Security headers cannot use the same Actor or omit the actor. This makes the middle side easily identify which WS-Security header contains the information they need. Of course, the middle side does need to know the Actor URI it processed. To associate a URI with the Actor and make sure the middle side knows the operation to be executed, must be implemented by programming. An Actor attribute in any SOAP header indicates that "this header is suitable for any endpoints in the range of the Actor URI indication." The meaning of the URI is provided by the workgroup for constructing a web service. This means that the middle side can operate in various ranges. As a result, this middle side may not use or use one or more headers. In this way, it will even use multiple security headers. WS-security supplement After the introduction of WS-Security, there are several needles to explain, especially in terms of security. In addition, some additional items are required for the usual web services. This article covers some parts of the safety in the replenishment. In this section, I want to introduce two items that are not dedicated to security: WSU: ID and WSU: TimeStamp. These two functions and usage are clearly indicated in the supplementation. WSU: ID ID attribute uses an XML schema ID type. Adding this element is to simplify the processing of the intermediate and receiver of the web service. The value of this property cannot be copied to other locations in the document. In addition to the unique identifier in the GXA specification, the regeneration does not in depth, the usage of this element is specified. Such other specifications can limit the use of IDs. WSU: TimeStamp In a message-oriented system, a common problem is the validity period of the data. Too old data will be discarded. If you receive two mutual conflict messages, you can use the relevant timestamp to determine which message is executed, which is ignored. To deal with the issues that occur in WS-Security and will have problems related to time in other GXA specifications, WSU: TimeStamp elements and several helper elements are defined. In the living life of the message, a more important time is the creation time of the message, and the sender requires the time and message of the message to expire. I know that creating time and expiration time, easy reception can determine if the data is new enough to use it, or if the data is too old, it should be discarded. Elements containing this data include: • WSU: CREATED: The creation time of the message is included. • WSU: Expires: Sets the expiration time for identifying messages by the sender or intermediate. • WSU: Received: Describes the time of the specific middle party to receive the message. All of the above elements may appear alone or as part of the WSU: TimeStamp element. Each element can contain a WSU: ID property to uniquely identify the item. By default, these timestamps indicate time in the form of XS: DateTime type. To provide some flexibility for other non-standard timestamps (which may be used in other issues), each item contains an attribute called ValueType. If the time is represented in the form of XS: DateTime, this property is not required. The WSU: Received element also allows the use of WSU: CREATED or WSU: EXPIRES. There are no two additional properties. This element can use the actor attribute and the delay amount of the milliseconda to represent the URI of the relevant actor. The delay is caused by the actor using the Delay property. As mentioned earlier, you can use WSU: Received, WSU: CREATED and WSU: Expires elements in other structures. For example, we can often see the time to use a WSU: Created element to indicate a particular element to the message. When more information about the message is indicated, these elements can be packaged into the WSU: Timestamp Element when using multiple elements at a time. In a timestamp, each of these three elements can only appear once. The timestamp can be used as a whole in the message, and it will appear in the sub-node form of the SOAP: Header node. For example, a message can use the following WSU: TimeSTAMP header, indicating that it is valid in the next five minutes: "ID-2AF5D5BD-1F0C-4365-B7FF-010629A1256C"> 2002-08-19T16: 15: 31Z "ID-4C337C65-8AE7-439F-B4F0-D18D7823E240"> 2002-08-19T16: 20: 31Z At this point, I believe that you have mastered enough background information. Let's take a deep understanding of how to use WS-Security to implement authentication, sign, and encryption. Authentication WS-Security provides an unlimited number of ways to verify users. The three methods are described in the specification: • Username / Password • PKI • Kerberos via X.509 certificate In this section, we will understand the working principle of these authentication methods, and how to encode this information into the SOAP message. Username Password One of the most common methods used to deliver the credit credentials is to use the username and password. This is a technique for HTTP basic authentication and brief authentication. In fact, if you are familiar with the working principle of HTTP's brief identification, this authentication mechanism can be flexibly applied. In order to deliver user credentials in this way, WS-Security defines the UserNameToken element. The architecture of this element is as follows: This architecture snippet references two other types: UserName and Password. These two types are substantially string, which can contain additional properties as needed. Password contains an attribute called Type indicating the password delivery. The password can be passed on plain text or brief format. When UserNameToken is passed in the SOAP message, XML may contain the following content: The above is the password example sent in plain text format. This solution looks easily destroyed. If you want to send your password in a safer manner, you can send its brief hash. Ke6QUGOPKPYT3EO0SEGT30W4KEG = "http://schemas.xmlsoap.org/ws/2002/07/UTILITY"> 2002-08-19T00: 44: 02Z Use the SHA1 hash to make the password unrelated, thus can increase security. Password briefs are random content, create a combination of time and passwords. The length of the random content is 16 bytes, passed in the form of the base64 encoded value. The working principle is that the client uses all of this information to add a password to create a password hash. The receiver verifies this data by acquiring the password in which it is created again. If the result is consistent, the password is correct. But this protection cannot prevent repetitive attacks. If you use this protection, make sure to include a WSU: TimeSTAMP header, which contains a small time to provide creating time values and expiration time values. Then, the WSU: TimeSTAMP element in the message is signed to detect any tampering of the timestamp. Otherwise, an attacker may use the full UserNameToken to attack your web services. To prevent repetitive attacks, you also need to include a mechanism to track a unique feature of incoming messages. This mechanism needs to save this property to the cache and last until the message timeout. X.509 certificate When verifying user identity, another option is to send an X.509 certificate. The X.509 certificate is exactly the identity of the user. You can use PKI to map this certificate to existing users in your application. Use certificates to verify that you are very susceptible to duplicate attacks. Therefore, it is best to force the message sender to use their private key to sign messages. This way, when you decrypt the message, you know that it does come from the user. When the message sends an X.509 certificate, public versions of this certificate will be passed in a WS-Security token named binarysecurityToken. The certificate itself is sent in the form of Base64 encoded data. BinarysecurityToken has the following architecture: ProcessContents = "Strict" /> Its most basic structure contains a string, a unique identifier, and some types of information indicating the value of the value and encoding. ValueType can be any of the following (definitions defined by the ValueTyPeenum in the WS-Security Architecture): • WSSE: X509V3: An X.509 version 3 certificate. • WSSE: Kerberosv5TGT: A TGT defined by the Kerberos specification 5.3.1. • WSSE: Kerberosv5st: A service ticket defined by the Kerberos specification 5.3.1 section. If you don't understand these Kerberos information, I will introduce more detailed in the next section. ENCODingType is another enumeration. It can be set to WSSE: Base64Binary or WSSE: HEXBINARY. You may have already guessed that this value is only the encoding method used. In the WS-Security header, this element is similar to the following pieces when passing the X.509 certificate: ValueType = "WSSE: X509V3" EncodingType = "WSSE: Base64Binary" ID = "SECURITYTOKEN-F49BD662-59A0-401A-AB23-1AA12764184F" > MiiHDJCCB ... Keep in mind that when you use the X.509 certificate, you have to do something else (such as signature messages). The signature created using the certificate of the certificate can prove that the client is the legal owner of the certificate. This message can be repeated. To help prevent and repeat the relevant issues, you can develop a policy that explains that the message is overlooked before. This time should be passed in the WSU: TimeStamp element (as a SOAP header in the message). Kerberos To use Kerberos, users need to provide a set of credentials (such as username / password or X.509 certificate). If all content verification is qualified, the security system will grant a TGT of the user. TGT is a hidden data that cannot be read, but it must be provided to access other resources. Typically, users need to provide TGT to obtain a service ticket (ST). The system's way of operation is as follows: • 1. Client to Key Distribution Center (KDC) Verify the identity and grant a TGT. • 2. Client Get TGT and use it to access Ticket Granting Service (TGS). • 3. The client requests a ST for accessing a specific network resource. The TGS then provides ST to the client. • 4. The client presents this ST to network resources and access resources using the ST instructions. Kerberos is very attractive because it contains the mechanism of the client to demonstrate identity and service to the client. ST is only available to access a network resource and can be used to discover the identity of the caller. When providing Kerberos bills in the message, you need to encrypt the data into the message. WS-Security does not explain how to get TGT and ST. signature The news after the signature is almost unable to be tampered. Message signatures cannot ban external parties from viewing message content. With signature, the receiver of the SOAP message can know that the signed element has not changed in the route. As long as it is possible, the message should be signed with the XML signature. Why is this this? Because the XML signature has been processed many difficult problems. WS-security is just simplicity explains how to use a signature to prove that the message is not changed. All three authentication mechanisms mentioned above provide methods for signing messages so that you can determine the following two items: • Users identified by X.509 certificates, UserNameToken or Kerberos tickets have signed the message. • The message after the signature is not tampered with. Each method provides a key that can be used for signature messages. X.509 allows the sender to sign messages using their private key. Kerberos provides a session key created by the sender and transmitted in the ticket. Only the expected recipient of this message can read the bill, discover the session key and verify the reliability of the signature. Finally, you can use your password to sign UserNameToken. Signature is generated using XML signature. To be a simple message signature such as "Hello World", each element in the message needs to be signed separately. WSU: TimeSTAMP has an interesting question because the middle side may add a WSU: Received element to WSU: TimeStamp. Whenever the element changes, update the signature, otherwise an exception will appear. Why is this this? Because if the content changes, the signature no longer matches. In the SOAP message, the signs and additional data needed have added a lot of additional information. encryption Sometimes, just prove the identity of the message sender and indicate that the message is still not enough. If you send a credit card number or a bank account through the signed plain text, an attacker can actually verify that there is no other attacker to change the content of the message. Therefore, they can be very affirmative data is effective. This is of course not wonderful for you. To do this, you need to encrypt data so that only expected recipients can read your message. None of the monitoring network exchange should not know the message content. Like the processing message sign, WS-Security also provides the corresponding specification, using existing standards, and can complete encryption work well. In fact, they incorporate XML encryption. When encrypting data, you can choose to use symmetric encryption or asymmetric encryption. Symmetrical encryption requires a shared key. That is, the encrypted message and the decryption message are the same key. If you control both endpoints simultaneously and you can trust the user and application of the key, you can use symmetrical encryption. Symmetric encryption There is a problem in key distribution. At some point in time, the key needs to be sent to the receiver. How to achieve this? Do you want to provide or negotiate it by mailing disks when needed? Both methods can be. If you need to send data using a simple distributed key, you can use asymmetric encryption. X.509 Certificate allows for asymmetric encryption. The endpoint that receives data can publish its certificate and allow anyone to encrypt information using the public key. Only the recipient knows the private key. Therefore, only the recipient can obtain encrypted data and re-convert it into readable content. So, what is the form of encrypted message? If you are using Triple-DES, the sender and the receiver must swap the key in a safe way. Symmetric keys can be hidden in the Kerberos bill, or have been exchanged. Messages based on WS-Security and Embedded XML encryption information are similar to: XMLns: soap = "http://schemas.xmlsoap.org/soap/envelop/" XMLns: Xenc = "http://www.w3.org/2001/04/xmlenc#"> XMLns: wss = "http://schemas.xmlsoap.org/ws/2002/07/secext" XMLns: WSU = "http://schemas.xmlsoap.org/ws/2002/07/UTILITY"> WSU: ID = "ID-3BEEB885-16A4-4B65-B14C-0CFE6AD26800" > 2002-08-22T00: 26: 15Z WSU: ID = "ID-10C46143-CB53-4A8E-9E83-EF374E40AA54" > 2002-08-22T00: 31: 15Z URI = "# EncryptedContent-F6F50B24-3458-41D3-AAC4-390F476F2E51" /> URI = "# EncryptedContent-666B184A-A388-46CC-A9E3-06583B9D43B6" /> ID = "EncryptedContent-F6F50B24-3458-41D3-AAC4-390F476F2E51" Type = "http://www.w3.org/2001/04/xmlenc#content"> "http://www.w3.org/2001/04/xmlenc#tripledes-cbc" /> > INMSSXQCBV5UIT ... Y7RVZQQNPPZYMG == The above message contains information about which data is encrypted and how to encrypt. Anyone without a key cannot decrypt the encrypted text in the body: body. When performing asymmetric encryption, the recipient of the message needs to know the private key to decrypt the message. The exchange of public keys must be carried out in advance. summary WS-Security allows the SOAP message to identify the caller, signature message and encrypt the message content. It uses existing specifications as much as possible to reduce the development efforts required to secure SOAP messages. Since all information is passed in the message, the message is not related to the transmission mode, and secure messages can be performed through HTTP, email, or on the CD-ROM. Resource • Standard • Signature • Encryption • WS-Security Specification • WS-Security Replenishment
