Dr. Mark Stamp
Web service is a service-oriented architecture (SOA), which provides a
standard based communication protocol between software components/applications over
Web service protocol stack consists of four layers as described below:
1. Transport layer: Transports packets between web service and its clients, e.g.,
HTTP over TCP, FTP etc.
2. Messaging: XML based protocol for the messages between web service and its
clients. SOAP (Simple Object Access Protocol) is commonly used as the
3. Interface description: Describes the interfaces supported by web services.
WSDL (Web Services Definition Language) is used for describing a web service.
4. Publish and Discovery: Stores the location and the description of web services
that can be discovered by the clients. UDDI (Universal Description discovery and
integration) is used to support this.
SOAP, WSDL and UDDI are based on XML. Since web services use XML as a standard
in all its layers, it helps applications running on different platforms written in different
languages communicate easily in a heterogeneous environment.
I believe that web service architecture is the wave of the future that will make distributed
computing over the network seem less. For example if I want to include a search engine
in my web portal I would simply call the web service APIs developed by “google” and I
will have sophisticated searching capabilities within my web portal.
Web services use SOAP which being XML based is clear text on the network and not
binary blobs. This opens up to anybody on the network to view the packets sent between
web services and their clients. This security issue is a huge roadblock for the industry to
standardize on web services. This is also one of the reasons, web services have not
exploded in the market. So for web services to be widely accepted in the market, basic
security requirements have to be satisfied.
At a high level for any cryptosystem, there are three basic security requirements:
1. Authentication of users
2. Confidentiality of messages
3. Integrity of messages
WS-Security (Web Services Security) is the specification that defines enhancements to
SOAP to fulfill the above requirements. It specifies a header to carry security related
Client has to prove its identity to a web service to invoke its functions. WS-Security
provides security tokens to ensure authentication. Username/Password, Kerberos tickets,
X.509 certificates or custom binary tokens are some examples of security tokens. This
paper discusses security tokens specified by WS-Security in more detail in the following
Preventing unauthorized reading of messages. WS-Security uses XML Encryption for
encrypting/decrypting SOAP messages. XML encryption is a W3C standard, and can be
used to encrypt portions of SOAP messages or the whole message. XML Encryption uses
“EncryptedData”, “EncryptedKey”, “CipherData” and “CipherValue” elements to
encrypt XML documents. Shown below is an example of an XML encrypted document:
Preventing unauthorized modification of messages. WS-Security uses XML Signature for
ensuring integrity of SOAP messages. XML signature is a W3C standard based upon
public key cryptography. It uses “CanonicalizationMethod”, “SignatureMethod”, the
“Transform” algorithm and the “DigestMethod” algorithm is inside the Signed document.
WS-Security specifies a header element <security>. This element contains all the security
related information showing the security mechanisms an application needs like security
tokens, encryption techniques and signatures. Rest of the SOAP message is not altered.
All the security related mechanisms like security tokens, encryption and signatures goes
A SOAP message could contain more than one Security elements with different <role>
values. No two Security elements can contain the same <role> value.
WS-Security defines UsernameToken and BinaySecurityToken for authenticating clients
invoking Web services.
This is a custom authentication scheme using user name and password. This token
specified by WS-Security provides a basic user name and password validation. Following
are the elements of UsernameToken:
• Username: Represents the user name.
• Password: Password of the user name.
• Password type: Type of password being used. This can be either a plaintext
(PasswordText) password or an encrypted password (PasswordDigest).
• Nonce: This is a value that keeps changing to avoid replay of the messages.
• Created: Time and date token creation.
There are three ways of using UsernameToken:
Username only: The password is optional. This is not very secure unless used over
SSL. This is represented within the SOAP envelope as follows:
Username and Password in clear text: Password in addition to username is good
but since its in clear text, its not very secure unless used over SSL. The type attribute
indicates that the password is in clear text. Now the SOAP header would contain:
Username and encrypted Password: This is the best approach. In this case the
password is sent in an encrypted digest format. It’s a hashed value that makes it very
difficult for the intruder to figure out the password. The SHA-1 algorithm is used for
encryption and the password is transmitted in Base-64 encoding. Now the SOAP
header would contain:
The third approach is good as it is not easy to break the password but one could use the
hash function to create his/her own password. WS-Security avoids this by using some
additional obfuscation. It uses the date and time of creation of message and a string called
nonce. A nonce is a unique random string for every SOAP message. Following formula is
used for creating the password digest:
Base64 Encoding (SHA-1 (Nonce + Created + Password))
The SOAP header would contain the following:
Now when the client sends this hashed password, the web service obtains the password
from its password repository (e.g., user/password database) for the corresponding user
and calculates the hash value. It then compares this value to the one sent by the client and
if they are same, then the client is authenticated successfully.
This method is better, but it also does not prevent intruder from taking the whole Security
header of a user’s message and putting in its message. WS-Security specifies
<TimeStamp> to prevent this kind of attack. A <TimeStamp> element contains the
following in UTC format:
So if the message arrives beyond the expiration time, web service will not validate the
client successfully. This is a good technique but requires client and server to be
synchronized, which is easy to implement. Another way to prevent this attack is by
keeping track of nonces on the server side and if a message comes with the same nonce,
then it can be discarded.
A binary security token contains three attributes as shown below:
<BinarySecurityToken Id=”somename” ValueType=”Kerberos”
• Id: Name of the token
• ValueType: Type of the encoded binary data, e.g., X.509 certificates, Kerberos
• EncodingType: The encoding format of the binary data e.g., Base64
Kerberos is a protocol to authenticate users/services over a network. The clients get
authenticated at Kerberos Distribution Center (KDC) and request service tickets to access
These are the certificates issued by a trusted certification service that are extremely
difficult to duplicate. This provides a trusted identity of the user. The certificates are sent
as Base64 encoded data to the web services and they can verify it with the certification
service to validate them.
In this paper, I have tried to explain the concept of web service and its security
limitations. I gave a very brief overview of XML Encryption and XML signature that are
used by WS-Security for encryption and digital signature respectively. Rest of the paper,
discusses in detail the mechanisms used by Web services for authentication
(UsernameToken and BinarysecurityToken). Microsoft has released WSE 2.0 that helps
implement these mechanisms without getting into gory details.
1) Expert Web Services Security in the .Net Platform: Nantz and Moroney
2) Understanding Web Services Specifications and the WSE: Jeannine Hall Gailey
3) Web Services Essentials: Ethan Cerani
4) WS-Security: http://msdn.microsoft.com/library/default.asp?url=/library/en-