Browse DevX
Sign up for e-mail newsletters from DevX


Pocket This Decoder for WS-Alphabet Soup

The alphabet soup of WS-* is difficult to master and yet, very essential for the immediate future. Here's our pocket guide to the basics of the 12 most important WS standards and in what situations they apply, for both .NET and Java.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

he Web Services Interoperability organization (WSI) has developed a whole stable of standards upon which Web services commerce and communication can be executed securely. These standards are in great demand and many developers have already gotten their feet wet with a few of them out of sheer necessity. But it's not been particularly easy to figure out which standard one might need to apply in various circumstances. Hopefully, I'm about to change that.

This article provides a basic roadmap of the main WS-* standards, and some implementation guidelines for both Java and .NET. Many of the implementation libraries for the WS-* standards are found in the Java Web Services Development Pack 1.5 (JWSDP), available for download from Sun at http://java.sun.com/webservices/jwsdp/index.jsp, and in the Microsoft Web services enhancements add- on (WSE) for .NET.

Use this article as a pocket reference to help you get the basic info on each of these important standards so you can get your arms around all that WS-* has to offer and how you can make best use of it in your organization.

Editor's Note: Code samples in this article are adapted from the original specifications.

1: WS-Security

  • What is it?
    A set of enhancements to SOAP that allows you to specify how a message can be secured when passing to and from a Web service.
  • When would you use it?
    Any time you want to pass sensitive information into or get sensitive information out of a Web service.
  • Tell me more!
    WS-Security ensures that a message isn't tampered with en route from the client to the server and that sensitive information (such as passwords) is encrypted. It defines a set of enhancements to the SOAP specification of messaging to enable protection of the message through authentication, confidentiality, and assurance of integrity.

The original specification was drawn up by OASIS (Organization for the Advancement of Structured Information Standards), available at http://www.oasis-open.org/specs/index.php#wssv1.0. There are a number of toolkits in Java that implement it, including the open source axis-wsse, the IBM Web services toolkit, the Apache WSS4J project), and of course the aforementioned JWSDP.

When using .NET the WSE makes implementing WS-Security very simple. Full documentation on using the WSE to implement WS-Security may be found on MSDN, and the documentation contains a number of quickstart samples that you can use and adapt. For Java folks, the JWSDP comes with a number of worthwhile examples that include source code.

2. WS-Policy and WS-SecurityPolicy

  • What is it?
    An XML Schema that allows the author to publish to the outside world what type of security or other policies they enforce.
  • When would you use it?
    When your Web service has many diverse customers, and you want a consistent way to tell them how to access your service.
  • Tell me more!
    You may be familiar with WSDL, which describes the protocol used to talk to a Web service. WS-Policy is an extension on this idea that describes the configuration of the Web service. So, if for example the Web service accepts only Kerberos tokens for security, then, the WS-Policy document associated with the service would document this. Clients calling the service can then make more intelligent decisions about how to call it.

WS-Policy is the baseline specification around which focused policy documents may be defined. An example of a policy type is a security policy (defined by the WS-SecurityPolicy specification) that uses WS-Policy as its basis. Some good documentation and its schema may be found at IBM developerWorks.

A simple example of a WS-SecurityPolicy document that specifies the security token types that a Web service will accept looks like this:

<wsp:Policy> <wsp:ExactlyOne> <wsse:SecurityToken> <wsse:TokenType>wsse:Kerberosv5TGT</wsse:TokenType> </wsse:SecurityToken> <wsse:SecurityToken> <wsse:TokenType>wsse:X509v3</wsse:TokenType> </wsse:SecurityToken> </wsp:ExactlyOne> </wsp:Policy>

Using Java you would then write a handler that parses this XML using SAX or DOM to determine how you will talk to the Web service, using its stated security policy, which in this case would be to use a Kerberos or an x509 token. If your application has neither available, it will be aware that it cannot talk to the service prior to making an attempt at communication.

For.NET folks, if you are using WSE, there is a WS-Policy class that handles many of the details for you.

3. WS-Trust

  • What is it?
    An extension to WS-Security that allows you to extend your security model across different domains or services.
  • When would you use it?
    When your Web service and somebody else's Web service want to share security information and credentials.
  • Tell me more!
    This takes the concept of WS-Security a little further, extending it to allow trusted relationships across domains. It extends on WS-Security to request and issue security tokens and to manage trust relationships between domains.

A snippet of a WS-Trust document that makes a request for a security token is shown here:

<S11:Envelope xmlns:S11="..." xmlns:wsu="..." xmlns:wsse="..." xmlns:xenc="..." xmlns:wst="..."> <S11:Header> ... <wsse:Security> <xenc:ReferenceList>...</xenc:ReferenceList> <xenc:EncryptedData Id="encUsername">...</xenc:EncryptedData> <ds:Signature xmlns:ds="..."> ... <ds:KeyInfo> <wsse:SecurityTokenReference> <wsse:Reference URI="#myToken"/> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> ... </S11:Header> <S11:Body wsu:Id="req"> <wst:RequestSecurityToken> <wst:TokenType> http://example.org/mySpecialToken </wst:TokenType> <wst:RequestType> http://schemas.xmlsoap.org/ws/2005/02/trust/Issue </wst:RequestType> </wst:RequestSecurityToken> </S11:Body> </S11:Envelope>

MSDN offers a great resource for investigating WS-Trust at http://msdn.microsoft.com/library/en-us/dnglobspec/html/WS-trust.pdf. The specification itself and some background information are available at http://www-106.ibm.com/developerworks/library/specification/ws-trust/.

WS-Trust is a specification for a language, and a WS-Trust document is implemented in XML. The WSE has a WSTrust class (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wseref/html/T_Microsoft_Web_Services2_Security_WSTrust.asp) that abstracts many of the details of the SOAP message for WS-Trust, allowing you to develop WS-Trust enabled services in .NET.

4. WS-Privacy

  • What is it?
    An XML Schema that defines your privacy policies regarding acceptance and use of personal information.
  • When would you use it?
    If you need to collect a lot of information from your Web services clients, such as credit card information, you can publish a WS-Privacy document detailing how this information is handled.
  • Tell me more
    You will be able to state how you conform to various privacy policies using the WS-Privacy specification. It encapsulates WS-Policy (it is a policy after all), WS-Security (to associate privacy claims with each message), and WS-Trust (to specify how claims around message privacy is met). It is a very ambitious effort, and to date hasn't yet been formalized or released.

5. WS-SecureConversation

  • What is it?
    A set of enhancements to SOAP that allow you to specify how a message can be secured throughout a long-running message exchange.
  • When would you use it?
    If your Web service and your client interact over a long-running process with a lot of data going over and back between them.
  • Tell me more!
    WS-Security provides mechanisms that allow you to build security for each message in a message exchange. However, in many cases you'll require more complex interactions, with many messages being exchanged. You could secure each of these in isolation, but it would be much more efficient if you could establish a context that reduces the overall burden of securing each message. The WS-SecureConversation specification defines a Security Context Token that does just that.

An example of a context token is shown below:

<wsc:SecurityContextToken xmlns:wsu='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss- wssecurity-utility-1.0.xsd' xmlns:wsc='http://schemas.xmlsoap.org/ws/2004/04/sc' wsu:Id='MySCT'> <wsc:Identifier></wsc:Identifier> <wsu:Created>2004-05-07T21:24:06</wsu:Created> <wsu:Expires>2004-05-08T09:24:06</wsu:Expires> </wsc:SecurityContextToken>

The specification itself is available at http://msdn.microsoft.com/library/en-us/dnglobspec/html/WS-secureconversation.pdf.

6. WS-Federation

  • What is it?
    A set of enhancements to SOAP that allow you to federate trust credentials among a group of Web service partners.
  • When would you use it?
    If you, and a number of other services share the same set of customers.
  • Tell me more!
    This specification defines mechanisms to enable identity, account, attributes, authentication, and authorization federation across different trust realms. The specification is in the review stage. The WS-Security, WS-Trust, and WS-Policy models define the basis for federation. WS-Federation extends these by describing how they may combine to enable richer trust across and between domains and federated services.
Figure 1. Federated Trust: The image shows how the WS-Trust model can be applied to a federation scenario.

Where this would work is in a network that requires a degree of federation. For example, say you have a network of bulletin boards, some of which are public to all organizations that subscribe to your system, while others are private to specific companies. If the private boards are to be shared between company A and company B, but not company C, then you would use federation of credentials between companies A and B.

Figure 1 shows how the WS-Trust model can be applied to a federation scenario. In this case security tokens (1) are passed from the requestor's trust realm and are used to acquire authentication on the respondent's trust realm (2), in order to access the resource (3). So tokens from one domain are used on another, allowing for federation across the domains. The specification defines a schema for the various messages that would be used in this scenario.

Thanks for your registration, follow us on our social networks to keep up-to-date