News Stay informed about the latest enterprise technology news and product updates.

Microsoft brings secure Web services closer

As the noise of secure communications and identity management continues unabated and vendors clamour at the door, Microsoft's recent announcement of Web Services Enhancements 2.0 might have been missed. John McIntosh reviews WSE 2.0 and comments on its impact on the industry.


Market Analysis

Microsoft brings secure Web services closer
As the noise of secure communications and identity management continues unabated and vendors clamour at the door, Microsoft's recent announcement of Web Services Enhancements 2.0 might have been missed.

This is a significant announcement, not because it comes from Microsoft but 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 version 2.0 offers new security features should simplify development and deployment of secure Web service applications that span company boundaries and trust domains, connecting and exchanging information with customer and partner systems.

According to the Company, 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 and not all the security capabilities that organisations might require to deploy live Web Service-based applications may be available.

There is within the .NET Framework and WSE 2.0 the ability 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 that is 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.


Copyright 2003. Originally published by IT-Director.com, reprinted with permission. IT-Director.com provides IT decision makers with free daily e-mails containing news analysis, member-only discussion forums, free research, technology spotlights and free on-line consultancy. To register for a free e-mail subscription, click here.

For more information:

  • Looking for free research? Browse our comprehensive White Papers section by topic, author or keyword.
  • Are you tired of technospeak? The Web Services Advisor column uses plain talk and avoids the hype.
  • For insightful opinion and commentary from today's industry leaders, read our Guest Commentary columns.
  • Hey Codeheads! Start benefiting from these time-saving XML Developer Tips and .NET Developer Tips.

  • Visit our huge Best Web Links for Web Services collection for the freshest editor-selected resources.
  • Visit Ask the Experts for answers to your Web services, SOAP, WSDL, XML, .NET, Java and EAI questions.
  • Couldn't attend one of our Webcasts? Don't miss out. Visit our archive to watch at your own convenience.
  • Choking on the alphabet soup of industry acronyms? Visit our helpful Glossary for the latest lingo.
  • Discuss this article, voice your opinion or talk with your peers in the SearchWebServices Discussion Forums.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchSoftwareQuality

SearchAWS

SearchCloudComputing

TheServerSide.com

Close