| Using WSE 3.0
Introduction
What is WSE? The acronym is short for Web
Service Extensions. Around the time that .Net 1.0 was released, a
consortium of interested parties (including IBM, Microsoft and Sun)
were working on XML namespaces that extended web service
communications. The aim was to extend the capabilities of web
services at the message level. These are often referred to as WS-*.
What do we mean by 'message level'?
Most infrastructure professionals are familiar with the TCP/IP network
stack.
The TCP/IP protocol is concerned with communication between network
hosts, not the data itself. As data is sent from one host, the various
layers of the stack are 'wrapped' around the data, so that it can arrive
successfully. After it arrives at the intended host, the layers are stripped
off and the data is read by the receiving host. The network stack is
independent of the data being sent.
WS-* works at the message layer, and adds information to the data itself.
What sort of information would be specific to the data?
A good example would be digital signatures. These relate specifically to
the data being sent, and by implementing these signatures within WS-*,
aspects of security are moved to the message layer, rather than the protocol
used for transmission. Digitally signing a request for a banking transaction
would then provide non-repudiation to the service receiving the message - it
could be proven that the request was made by the person that created the
signature.
Digital signatures are not the only solution provided by WS-*, and this
article will look at various aspects.
Another reason for moving security to the message layer would be
if a protocol other than HTTP was to be used for communication. WS-*
supports a number of protocols.
Microsoft's technology for implementing WS-* is called Web Service
Extensions (WSE) and is currently on version 3.0.
Building blocks of WS-*
There are a number of standards within WS-*, and these include:
WS-Security WS-SecureConversation WS-Federation WS-Policy
WS-Trust Rather than developers having to understand all of the
different namespaces used within WS-*, WSE gives a programming API
that can implement security requirements. The first step in
implementation is to create a policy that specifies what message
level information is required. Here is an example policy.
Gosh, this is a lot of XML, isn't it? Don't worry - this will become less
confusing as we go on. There are actually two policies here - one that
specifies that a message should include a username token, and another that
specifies more advanced encryption options. Lets look at the first policy.
 This policy
is named 'UsernameTokenTransportSecurity'. It specifies that a username
token, with password, should be included in the message. Both the client and
the web service have a copy of this policy, and this is enforced at both the
sending and receiving ends by WSE. It specifies that a username token, with
a password, should be included in the exchange. By installing WSE 3.0 on a
PC that has Visual Studio 2005 installed, policy creation is easy. First,
right click on the application (you have to perform this on both the client
and the web service). Choose the 'WSE settings 3.0' option. This allows you
to enable Web Services Enhancements.
 Moving to the policy tab and selecting 'Add' brings up a wizard which
walks you through the implementation of your requirements.
That creates the policy file - I told you this would get less confusing,
didn't I?
Now, how do we add the username and password to the message? This is
something that's done in code.
UsernameToken ut = new UsernameToken("myuser", "mypassword", PasswordOption.SendPlainText);
ObjectService.ServiceWse swe = new ObjectService.ServiceWse();
swe.SetClientCredential(ut);
swe.SetPolicy("usernameTokenSecurity");
ObjectService.ServiceData sd = swe.GetServiceData("hello");
The first line creates a UsernameToken, containing the username, password
and another parameter that specifies that the password should be sent in
plain text. Next, and instance of the web service proxy is created. The
UsernameToken is then attached to the instance of the proxy. Finally, the first policy that we looked at is applied to the communication via the
SetPolicy method.
The last line is a call to a method on the service proxy. It passes a
string parameter, 'hello'.
So what does the message look like? The 'Diagnostics' tab on the WSE
settings window allows both client and service to save the outgoing SOAP
message. First, we'll look at the unprocessed message (without Web Service
Extensions).
This looks like an ordinary SOAP message, the sort that we produced when
we worked with the first version of Visual Studio.Net.
Further down the output file, we can see the actual message sent - with
the WSE added.
In the <wsse:Security /> element, we can see sub elements that include a
timestamp (for preventing message replay) and a username token (including
the username and password that was sent). The username token also includes a
nonce, again for preventing message replay attacks. Obviously, this message would
be sent over SSL so that the username and password cannot be read by
eavesdropping on the network communication.
The service contains the following code to extract the username token.
SecurityToken st = RequestSoapContext.Current.IdentityToken;
string userName = st.Principal.Identity.Name;
The WSE extensions, by default, authenticate the username and password
against a Windows security store - Active Directory or the SAM. So we can
extract the username and rely on the Windows authentication that has taken place. We
can also impersonate the token if required, for accessing files restricted
to that user.
WSE 3.0 provides 'turnkey' scenarios. This means that handlers have been
provided to cope with many common requirements. For instance, a handler has
been created for adding both digital signatures and encryption to a message.
This can be applied via a policy.
This policy specifies that a message should be signed, encrypted, and
also have the signature encrypted. It only allows the user WSETEST\WSEUser
to access the service.
Upgrading to WSE 3.0
What are the advantages of the newest version of Web Service Extensions?
WSE 3.0 is required for implementing WSE on Visual Studio 2005. WSE 2.0
is not compatible.
Version 3.0 provides 'turnkey' scenarios. These are applications of
policy that cover many of the most common uses of Web Service Extensions. It
means that you don't have to 'roll your own' each time you secure a web
service.
The latest version also allows security policy to be applied for each
individual communication, rather than a blanket approach to all messages of
a certain type.
The future
We're hearing a great deal from Microsoft about Windows Communication
Foundation. This will be the strategic framework for applying WS-* to web
services. In the meantime, WSE has been created to allow developers to use
this technology while WCF is still in beta. WSE 3.0 applications will be
interoperable with WCF services and clients.
Summary
WS-* is becoming integral to more web services, and is becoming mandatory
in some cases in the industry. WSE provides an easy to use API and
configuration for implementing this technology.
WSE 3.0 makes this technology more flexible and easier to implement, as
well as offering interoperability with WCF.
In a future article, we'll look at how to use WCF to secure web service
communications, and also explore more advanced aspects of WS-* such as WS-SecureConversation.
|