Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Secure your SOA

Enterprise-grade SOAs require a plan for addressing diverse security needs

By Ash Parikh, Anthony Sangha and Murty Gurajada, JavaWorld.com, 04/10/06

Page 4 of 6

As previously mentioned, these standards use XML. XML enables technologies to be conveniently extended to meet special requirements in a way not possible using older formats. In addition, XML allows implementers to use the many software tools available for processing. In the case of WSS, it is designed to integrate closely with the syntax and processing model of SOAP, which is defined in XML.

Furthermore, XML is a markup language, capable of labeling the information content of diverse datasources, including structured and semi-structured documents, relational databases, and object repositories. With so much relevant data available in XML form, it becomes imperative that this data be queried and mined for further applicability. The query language that understands XML and can express queries across all forms of XML data, whether physically stored in XML or viewed as XML via middleware, is XQuery. XQuery is broadly applicable across many types of XML datasources.

The recommended practice for persisting XML data is to use a native XML database technology that treats XML not as another relational artifact, but as a natural XML artifact. XML database management servers (XDMSs) are enterprise-grade XML persistence mechanisms with all the bells and whistles that come with a traditional relational database. XDMSs that feature powerful XML indexing, profiling, and acceleration are a big plus.

WS-Policy

As shown in Figure 1, the Web Services Policy Framework provides a general-purpose model and corresponding syntax to describe and communicate the policies of a Web service. WS-Policy defines a base set of constructs that can be used and extended by other Web services specifications to describe a broad range of service requirements, preferences, and capabilities.

WS-Policy provides a flexible and extensible grammar for expressing the capabilities, requirements, and general characteristics of entities in an XML Web services-based system. WS-Policy defines a framework and a model for the expression of these properties as policies. Policy expressions allow for both simple declarative assertions as well as more sophisticated conditional assertions.

WS-Policy defines a policy to be a collection of one or more policy assertions. Some assertions specify traditional requirements and capabilities that will ultimately manifest on the wire (e.g., authentication scheme and transport protocol selection). Some assertions specify requirements and capabilities that have no wire manifestation, yet are critical to proper service selection and usage (e.g., privacy policy and quality-of-service characteristics). WS-Policy provides a single policy grammar to allow both kinds of assertions to be consistently considered.

Note that the new OASIS Web Services Secure Exchange (WS-SX) Technical Committee is the new OASIS working group for WS-Policy and other related standards.

The XML representation of a policy assertion is called a policy expression. Policy assertions are combined by using policy operators: All, ExactlyOne, OneOrMore, etc.

The following illustrates a simple example of a policy:

 <policy Priority="200">
   <All>
      <Language Usage="Required" Language ="it" />
         <ExactlyOne>
            <SecurityToken TokenType="UsernameToken" Usage="Required">
               <Claims>
                  <Username>Claudio</Username>
                  <UsePassword/>
                </Claims>


            </SecurityToken>
            <SecurityToken TokenType="X509" Usage="Required">
               <Claims>
                  <SubjectName>Role=Student</SubjectName>
               </Claims>
            </SecurityToken>
         </ExactlyOne>
   </All>
</policy>

Other policy-related specifications are:

• Web Services Policy Assertions Language
• Web Services Security Policy Language
• Web Services Policy Attachment
• Policies for other technologies such as WS-Privacy, WS-Authorization, and WS-ReliableMessaging

For administration purposes, a policy repository is required. The administration tool should provide an interface for inserting, modifying, and removing policies. It should provide all the related policies to the requestor, and the policies should be realized through an XML database. A SAX (Simple API for XML) parser, which is fast and uses little memory, should parse the XML data.

WSS

WSS, developed by the Organization for the Advancement of Structured Information (OASIS) per the Web Services Security Technical Committee, defines a standard way of applying digital signatures and encryption to SOAP documents using XML security standards. WSS specifies how to protect SOAP messages as they pass over a network. It includes authentication, integrity protection, and confidentiality. It does not specify how to implement access control, but instead provides information that may be used for such control. WSS allows encryption to be applied selectively. For example, it allows application firewalls to inspect the unencrypted portion.

In addition, WSS allows more flexibility in infrastructure choices. It can not only utilize X.509 technology, but also Kerberos, SAML, or plain-old username and password. Since WSS operates at the SOAP layer, it can travel with the message throughout the network and even persist when the message is queued or stored.

WSS uses the XML-Signature Syntax and Processing and XML Encryption standards developed at the W3C. WSS operates by inserting an XML element called security into the SOAP header. The SOAP header contains all of the information about authentication, digital signatures, and encryption that have been applied to the message. It gives the receiver the information necessary to decrypt and validate the message. The keys and authorization information may be specified using X.509 certificates, Kerberos tickets, SAML assertions, or other methods.

An example of a SOAP envelope with <security> element is as follows:

 <S:Envelope>
<S:Header>
<wsse:Security S:mustUnderstand="1"
xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext">
<wsse:BinarySecurityToken EncodingType="wsse:Base64Binary">
MIIDQTCC4ZzO7tIgerPlaid1q ... [truncated]
</wsse:BinarySecurityToken>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
....XML Signature...
</ds:Signature>
</wsse:Security>
</S:Header>
<S:Body>
<m:OrderAircraft quantity="1" type="777" config="Atlantic"
xmlns:m="http://www.rdta.com/XMLDatabaseOrderSubmission"/>
</S:Body>
<S:Envelope>

Web Services Secure Conversation Language is another useful specification—it allows a session to be created between a Web service requester and a Web service, using symmetric keys. WS-SecureConversation is analogous to SSL, which also involves the negotiation of a symmetric key to streamline encrypted message transfer. WS-SecureConversation is available in Microsoft's Web Services Enhancement 2.0 toolkit, but no Java implementation is available at present. WS-SecureConversation is now also part of WS-SX.