Basic Computer Security/Web Security/Enhancing Web Services Security
|
This section discusses techniques and methods to enhance web services security.
The WS-Policy has been standardized by the W3C group and has become known as the de facto standard web service policy specifications. There have been a number of proposals to translate the WS-Policy into logic. One such proposal uses OWL-DL to provide formal semantics. Using a reasoner, it provides a mechanism that determines if two policies are compatible. The reasoner used is Pellet which is a standard plug-in for the open-source tool called Protégé available through Stanford University. WS-Policy based files are mapped to OWL-DL based on the idea that service policy assertions are mapped to classes, and web service requestors are mapped to OWL individuals. The reasoner provides a number of services in containment, equivalence, incompatibility, incoherence (nothing can satisfy the policy) and policy conformance, among others. Thus, the mapping allows us to use an off-the-shelf OWL reasoner as a policy engine and analysis tool, and an off-the-shelf OWL editor as a policy development and integration environment. OWL editors can also be used to develop domain specific assertion languages (essentially, domain ontologies) with a uniform syntax and well specified semantics. Policy intersection is also used when a web service requestor and provider want to compute the compatible policy alternatives between them. OWL-DL is a W3C standard, a language with clear syntax and semantics that is ubiquitous in the Semantic Web. The number of reasoners and OWL-DL editors has been growing steadily. A policy language based on OWL-DL can capitalize on the popularity of OWL-DL. The previous examples described would not have been possible had not modifications been done to Pellet. Further, a user interface was developed as part of the project called SWOOP. It can be downloaded at the following URL: http://code.google.com/p/swoop/[1].
A another method to extend security for web services is use the JAX-WS specification in conjunction with JAX-WS RI. The standard handlers of JAX-WS have some limitations. For example, LogicalHandler provides access to payload only and does not provide access to SOAP headers and binary data carried as attachments in the SOAP Message, and is more suited for XML/HTTP binding. Further, though SOAPHandlers provide access to whole SOAP Message, it has performance implications as SOAPMessage is based on DOM and tries to load the whole message in memory. On the hand, JAX-WS RI reads the message in a streaming fashion and tries to read the information lazily to provide better performance. The JAX-WS specification supports the common WS-I specifications including WS-I Basic Profile, WS-I Attachments Profile, WS-I Simple SOAP Binding Profile 1.0 WS-Addressing - Core, SOAP Binding, and WSDL Binding. JAX-WS RI defines message abstraction— hiding the actual data representation, either the message to be constructed from a JAXB object or InputStream of an HttpConnection. The Message API provides various ways to access the payload and implementations can implement those methods in the best possible way. JAX-WS runtime chooses the right Message representation when it constructs a new message. Further, it provides some commonly used implementations of the Message Base class (e.g., JAXBMessage, DOMMessage, SAAJ Message, and ProtocolSourceMessage). Each of these Message classes has particular characteristics and may be more useful or suited depending on the situation at hand. With the addition of RI, the developer has access to static factory methods to easily create messages with the Messages API. Using this approach, he can easily access and create messages irrespective of the actual data representation. Utilizing the extensible Handler framework provided by the JAX-WS Specification and the better Message abstraction in RI, a new class handler may be introduced a called MessageHandler to extend your web service applications. MessageHandler is similar to SOAPHandler, except the implementations of gets access to MessageHandlerContext (an extension of MessageContext). Through the MessageHandlerContext class, the Message can be accessed and processed by using the Message API[2].
References
edit[1] Vladimir Kolovski and Bijan Parsia,WS-Policy and Beyond: Application of OWL Defaults to Web Service Policies. Department of Computer Science, University of Maryland, College Park, MD USA, 2008.
[2] JAX-WS 2.1 RI Architecture Document, Sun Microsystems, 2009.