Microsoft brings Secure Web Services closer

As the noise of secure communications and identify management continues unabated and vendors clamour at the door, Microsoft's recent announcement of Web Services Enhancements 2.0 might have been missed, writes John McIntosh of Bloor Research.

This is a significant announcement, because of what it potentially means to the Web Services market and the security market. We all know that security for Web Services is the great inhibitor and until that is sorted out, no-one is going to drop their perimeter.

WSE 2.0 offers new security features which should simplify development and deployment of secure Web Service applications spanning company boundaries and trust domains, connecting and exchanging information with customer and partner systems.

According to Microsoft, WSE 2.0 means that developers can apply security policies to Web services with minimal lines of code and support interoperability across heterogeneous systems.

WSE 2.0 does this by building on the security, routing and attachment capabilities of version 1.0 and adds a foundation for building applications based on Web services specifications published by Microsoft and its industry partners including WS-Security, WS-Policy, WS-SecurityPolicy, WS-Trust, WS-SecureConversation and WS-Addressing.

It should be said that WSE 2.0 is a technology preview; the security capabilities that organisations might require to deploy live Web Service-based applications may not all be available.

Within the .NET Framework and WSE 2.0 is the capability to do many interesting things in terms of secure application development to support integration and federation of security through the value chain.

WSE is important because it introduces for the first time the ability to test the theories behind emerging WS-Security standards. Essentially, is it possible to build a system that can securely expose internal systems to partners as Web services, leveraging existing technology investments to generate future revenue opportunities?

Without the following new capabilities, the answer to that question would probably be no.

• Token-issuing framework (WS-Trust, WS-SecureConversation) provides capabilities that build on WS-Security and define extensions to request and issue security tokens and to manage trust relationships and secure conversations.
• Roles-based authorisation with integration into Windows security enables corporations to leverage their existing Windows domain credentials when accessing Web services or to integrate their own access control engine.
• Declarative programming model (WS-Policy, WS-SecurityPolicy) enables developers to author policies that operate a runtime component, responsible for processing the SOAP headers in Web services that contain security and routing information and play a role in the validation of incoming and outgoing messages. For example, the runtime can automatically sign and encrypt a message based on the authored policy without the developer having to write code.
• Message-based object model (WS-Addressing) provides customers with a message-based programming model over TCP and HTTP, allowing them to explore alternative types of SOAP-based applications such as ad hoc peer-to-peer applications.

To my mind, the bit still missing, other than resolving internal .NET Framework trust hierarchies, is that WS-Security lacks properties to mediate trust relationships. It assumes organisations developers will work this out for themselves.

And while developments in the area of Web Service security are to be welcomed, one cannot help but wonder why the security keys are still in the hands of the developers. It seems a strange position and suggests Microsoft have yet to fully grasp service-orientated architectures as the way forward.

© IT-Analysis.com