You are on page 1of 17


WS-Security Copyright © 2010 Purple Desk All Rights Reserved. PurpleDesk.and its logo are Trademarks of Purple


WS-Security WS-Security is a family of specifications designed to augment wirelevel security by providing a unified, transport-neutral, end-to-end framework for higher levels of security such as authentication and authorization. WS-Policy

This specification describes general security capabilities, constraints, and policies. For example, a WS-Policy assertion could stipulate that a message requires security tokens or that a particular encryption algorithm be used.


This specification deals primarily with how security tokens are to be issued, renewed,

and validated. In general, the specification covers broker trust relationships, which are illustrated later in a code example.


This specification explains how services can state and enforce privacy policies. The

specification also covers how a service can determine whether a requester intends to follow such policies.


This specification covers, as the name indicates, secure web service conversations across different sites and, therefore, across different security contexts and trust

domains. The specification focuses on how a security context is created and how security keys are derived and exchanged.


This specification addresses the challenge of managing security identities across different platforms and organizations. At the heart of the challenge is how to maintain

a single, authenticated identity (for example, Alice’s security identity) in a

heterogeneous security environment.


This specification covers the management of authorization data such as security tokens and underlying policies for granting access to secured resources.

Wire-level security

Security begins at the transport or wire level; that is, with basic protocols that govern communications between a web service, whether SOAP-based or RESTstyle,

and its clients. Security at this level typically provides three services. First,

the client and service need transport-level assurance that each is communicating with the other rather than with some impostor. Second, the data sent from one side to the other needs to be encrypted strongly enough so that an interceptor cannot decrypt the data and thus gain access to the secrets carried therein

User authentication and authorization

Web services provide clients with access to resources. If a resource is secured, then a client needs the appropriate credentials to gain access. The credentials are presented and verified through a process that usually has two phases. In the first phase,

a client (user) presents information such as a username together with a credential

such as a password. If the credential is not accepted, access to the requested resource

is denied. The first phase is known as user authentication. The second phase, which is optional, consists of fine-tuning the authenticated user’s access rights. For example, a stock-picking web service might provide all paying customers with a username and password, but the service might divide the customers into categories, for instance, regular and premier. Access to certain resources might be restricted to premier clients. The second phase is known as role authorization


WS-Security, or WSS for short, is a collection of protocols that specify how different levels of security can be enforced on messaging in SOAP-based web services. For example, WSS specifies how digital signatures and encryption information can be

inserted into SOAP headers. Recall that SOAP-based services are designed to be

transport-neutral. Accordingly, WSS is meant to provide comprehensive end- Toend security regardless of the underlying transport.

HTTPS Basics

HTTPS is easily the most popular among the secure versions of HTTP. HTTPS provides three critical security services over and above the transport services that HTTP provides. Following is a summary of the three, with Figure 5-2 as a reference. In the figure, Alice needs to send a secret message to Bob. Eve, however, may be eavesdropping. Eve may even try to dupe Alice and Bob into believing that they are communicating with one another when, in fact, each is communicating instead with Eve. This variation is known as the MITM (Man In The Middle) attack. For secure communications, Alice and Bob thus need these three services:

Peer authentication

Peer authentication Alice needs Bob to authenticate himself so that she is sure about who is

Alice needs Bob to authenticate himself so that she is sure about who is on the

receiving end before she sends the secret message. Bob, too, needs Alice to authenticate

herself so that he knows that the secret message is from her rather than

an impostor such as Eve. This step also is described as mutual authentication or mutual challenge. Confidentiality

Once Alice and Bob have authenticated each other, Alice needs to encrypt the secret message in such a way that only Bob can decrypt it. Even if Eve intercepts the

encrypted message, she should not be able to decrypt the message because doing so requires enormous computational power or incredibly good luck.


The message that Alice sends should be identical to the one that Bob receives. If

not, an error condition should be raised. The received message might differ from

the sent one for various reasons; for instance, noise in the communications channel

or deliberate tampering by Eve. Any difference between the sent and the received message should be detected.

Symmetric and Asymmetric Encryption/Decryption Modern approaches to encryption follow two different approaches, symmetric and asymmetric. Under either approach, the bits to be encrypted (plain bits) are one input

to an encryption engine and an encryption key is the other input. The encrypted bits are the cipher bits. If the input bits represent text, then they are the plaintext and the output bits are the ciphertext. The cipher bits are one input to

the decryption engine, and a decryption key is the other input. The decryption produces the original plain bits. In the symmetric approach, the same keycalled the secret key or the single keyis used to encrypt and decrypt

In the asymmetric approach, the starting point is a key pair, which consists of a private key and a public key. As the names suggest, the private key should not be distributed

but safeguarded by whoever generated the key pair. The public key can be distributed

freely and publicly. If message bits are encrypted with the public key, they can be decrypted

only with the private key, and vice-versa.The asymmetric approach solves the key distribution problem, but asymmetric encryption and decryption are roughly a thousand times slower than their symmetric counterparts.


This is the public key cryptography algorithm, named after Rivest, Shamir, and Adleman, the former MIT professors who designed it. RSA is the most commonly

used public key algorithm. It is used to encrypt the pre-master that is sent from the

client to the server.


The stream cipher algorithm, which is used to encrypt and decrypt the bit traffic between client and server, has a key length of 128 bits. The R is for Rivest in RSA,

and the C is for cipher. (Sometimes RC is said to be shorthand for Ron’s Code, as Rivest’s first name is Ron.) RC4 is the most commonly used stream cipher. RC4_128 is used to encrypt the data traffic once the handshake is completed.


The certificate’s 128-bit identifying hash, also called its fingerprint, is generated with the Message Digest algorithm 5. MD5 supplies what is officially known as the

cryptographic hash function. Rivest designed MD5 as an improvement over MD4.

Although MD5 is not fatally flawed, it is gradually losing ground to alternatives such as the Secure Hash Algorithm (SHA) family of hash algorithms


<S:Envelope xmlns:S="">

<S:Header> <wsse:Security xmlns:wsse="



<wsse:UsernameToken xmlns:wsu="



<wsse:Username>fred</wsse:Username> <wsse:Password



rockbed </wsse:Password> <wsse:Nonce EncodingType="









<ns2:echo xmlns:ns2="http://wss.jft/">

<arg0>Hello, world!</arg0>




<S:Envelope xmlns:S=""> <S:Header/> <S:Body> <ns2:echoResponse xmlns:ns2="http://wss/"> <return>Echoing: Hello, world!</return>




Tomcat (Enable https)

Password changeit

D:\onesource\webservices\source>keytool -genkey -alias tomcat - keyalg RSA

Keylocation C:\Documents and Settings\Administrator

Server.xml <Connector port="8080" protocol="HTTP/1.1"


redirectPort="8443" />



clientAuth="false" sslProtocol="TLS"

keystoreFile="C:\Documents and Settings\Administrator\.keystore"/>\Documents and Settings\Administrator\.keystore \ \\Documents and Settings\Administrator\.keystore \

Container-Managed Authentication and Authorization

Tomcat provides container-managed authentication and authorization. The concept of a realm plays a central role in the Tomcat approach. A realm is a collection of resources, including web pages and web services, with a designated authentication and authorization facility.

JDBCRealm The authentication information is stored in a relational database accessible through a standard Java JDBC driver. DataSourceRealm The authentication information again is stored in a relational database and accessible through a Java JDBC DataSource, which in turn is available through a JNDI JNDIRealm The authentication information is stored in an LDAP-based (Lightweight Directory Access Protocol) directory service, which is available through a JNDI provider.


The authentication information is read into the container at startup from the file

conf/tomcat-users.xml. This is the simplest choice and the default. JAASRealm

The authentication information is available through a JAAS (Java Authentication and Authorization Service) provider, which in turn is available in a Java Application Server such as BEA WebLogic, GlassFish, JBoss, or WebSphere.

Questions and Comments Copyright © 2010 Purple Desk All Rights Reserved. 17

Questions and Comments

Copyright © 2010 Purple Desk All Rights Reserved.