Java Web Services

Security is critical for exchanging business data using WEB services. If the data is intercepted by a third party, or if deceptive data is received as valid data, it can cause serious financial or legal consequences. It is always possible to design and implement security for your application for WEB services (any form of data interchange), but this approach is risky because even a small error and omission can lead to serious security vulnerabilities. One of the advantages of SOAP compared to other simpler data exchanges is that it supports modular scaling. Since SOAP was first released, security has been a major focus of expansion, prompting the standardization of Ws-security and related technologies, allowing for the appropriate configuration of security for each service.

The need for security for information exchange usually consists of three aspects:

Confidentiality: Only the target recipient of the message has access to the message content.

Integrity: The message received did not change.

Authenticity: The source of the message can be tested.

Ws-security allows you to easily meet these three requirements. In this article, you will understand how to implement this by using the Axis2 and Rampart ws-security extensions. However, we'll start with a brief overview of the principle of public key cryptography-which is the primary basis for the Ws-security encryption and signature features.

Public key Encryption

Throughout history, security message exchange has been based on some form of shared secrecy. The secret may be in the form of code, in which both sides of the exchange use the agreed content to replace words or operations. Or it can be the form of a cipher that converts a text to another text through an algorithm. Secrets can even be used in other forms, such as for languages unknown to other parties that may have access to the message. Sharing secrets can make message exchange very secure. However, if the other party discovers the secret, the message exchange leaks and potentially damaging results for the message Exchange party. (for example, think about military communications between Enigma and German in World War II).

Public key cryptography is a security method that is intrinsically different from other encryption, and it does not require a shared secret. It is based on the idea of a mathematical "trap-door" function that can be easily computed in one direction, but difficult to compute in the opposite direction. For example, it is easy to find the product of two prime numbers (if you use a computer, you can even be a very large prime number), but it is difficult to analyze the product to find the original two factors. If you construct a cryptographic algorithm around the simple direction of a function, anyone who wants to crack the encryption needs to decrypt it in the opposite direction. As with any carefully chosen algorithm, attempts to crack the encryption will be difficult to complete (at least until someone has developed a usable quantum computer, or really effective psychic powers) within a time limit that can threaten the exchange of messages.

With public key encryption, a pair of key values will be created by the party who wants to receive the encrypted message. Each key value can be used separately for encrypting messages, but it cannot be used to decrypt messages that are encrypted by itself. Instead, the other key for the key value must be used for decryption. As long as the owner of the key is keeping one of the keys secret, the other key can be disclosed to others. Anyone who accesses this public key can use it to encrypt the message, and only the key owner can decrypt the message. This form of encryption is called asymmetric encryption because of the use of different keys for encrypting and decrypting messages.

Message signature

When you encrypt a message using your public key, only you, the holder of the private key, can decrypt the message. This ensures confidentiality and satisfies one of the three aspects of secure message exchange. But you can also use your private key to encrypt the message, so that anyone with your public key can decrypt the message. At first glance it doesn't seem to work-what's the use of encrypted messages that anyone can read? -but this approach can serve as a good mechanism for verifying authenticity. People who are allegedly receiving encrypted messages from you can use your public key to decrypt the message and compare it to the expected value. If the values match, then they know that you created the message.

In practice, the process of message signing is more than using private keys to encrypt messages. First, you need to use some method to establish the expected value for decrypting the message. This is usually done using another variable mathematical trap-door function: This is a hash (hash) function that is easy to compute but difficult to replicate (that is, it is difficult to modify the message without modifying the hash value of the message, or to find another message with the same hash value as the provided message). Using this hash function, you can generate a hash value for the message you want to sign (commonly referred to as a Digest (digest) in the security discussion), and then use the private key to encrypt the digest and use the message to send the encrypted digest value. Anyone who receives this message can use the same hashing algorithm for the message, and then use your public key to decrypt the accompanying encrypted digest and compare the values. If the value matches, then the receiver can determine (within the current technology's scope and assume that you have kept your private key secret) that the message was sent by you.

When working with XML, the message signing process also involves another step. XML messages are represented as text, but some aspects of text representations are considered irrelevant by XML (such as the Order of attributes on an element, or whitespace used within the start and end tags of an element). Because of this problem with textual representations, the consortium (owner of the XML specification) decides to convert the XML message to a standard text form before calculating the digest value. Some of the standardized algorithms are also defined and can be used for XML messages. As long as both sides of the message exchange agree to use the same algorithm, it does not have any effect on which algorithm to use.

Using a signed message digest can also guarantee message integrity (because changes to the message will change the digest value) and authenticity (because your private key is used to encrypt the digest). Because encryption with public keys ensures the privacy of messages, all major aspects of message exchange security can be covered by using a public-private key pair. Of course, for a key pair, only one side of the message exchange is secure-but if the other party to the exchange has its own public/private key pair, it can provide sufficient security for both parties to the message exchange.