Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. WS-Security Protocol By Ramkumar Chandrasekharan CS 265 Dr. Mark Stamp 03/25/2005
  2. 2. Introduction Web service is a service-oriented architecture (SOA), which provides a standard based communication protocol between software components/applications over a network. 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 messaging protocol. 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. Security Requirements 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 information. 2
  3. 3. Authentication 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 sections. Confidentiality 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: <?xml version=”1.0”?> <EncryptedData> <CipherData> <CipherValue>1234ABCDEF</CipherValue> </CipherData> </EnryptedData> Integrity 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 header 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. For e.g., <soap:Envelope xmlns:soap=http://schemas.xmlsoap.ord/soap/envelope xmlns:wsse=”http://schemas.xmlsoap.ord/ws/2002/12/secext”> <soap:Header> <wsse:Security soap:role=”….”> All the security related mechanisms like security tokens, encryption and signatures goes here </wsse:Security> 3
  4. 4. 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 Tokens WS-Security defines UsernameToken and BinaySecurityToken for authenticating clients invoking Web services. UsernameToken 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: <UsernameToken> <Username>somename</Usernname> </UsernameToken> 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: <UsernameToken> <Username>somename</Usernname> <Password Type=”PasswordText”>password_clear_text</Password> </UsernameToken> 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: <UsernameToken> <Username>somename</Usernname> <Password Type=”PasswordDigest”>ghsf3434gdhjg3434s</Password> </UsernameToken> 4
  5. 5. 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: <UsernameToken> <Username>somename</Usernname> <Password Type=”PasswordDigest”>ghsf3434gdhjg3434s</Password> <Nonce>AVBSCDdfdfhd567dfdf</Nonce> <Created>2005-03-24T12:34:37Z</Created> </UsernameToken> 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: <TimeStamp> <Created>2005-03-24T11:34:37Z</Created> <Expires>2005-03-24T11:35:077Z</Expires> </TimeStamp> 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. BinarySecurityToken A binary security token contains three attributes as shown below: <BinarySecurityToken Id=”somename” ValueType=”Kerberos” EncodingType=”Base64Binary” > absdbABA1233434GH </BinarySecurityToken> • Id: Name of the token • ValueType: Type of the encoded binary data, e.g., X.509 certificates, Kerberos tickets • EncodingType: The encoding format of the binary data e.g., Base64 5
  6. 6. Kerberos Tickets 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 web services. X.509 Certificates 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. Summary 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. Reference: 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: us/dnglobspec/html/ws-security.asp 6