Composite applications are made up of discreet services that have been tried and proven reliable, but building an orchestration that incorporates services that come from several sources, some of them outside of the company, could introduce testing hazards beyond just bad output. For example, let's say that your business has a process that includes activities to run a credit check with an external credit agency or to schedule a package delivery with an external shipping service.

Is SOA ready to move from the whiteboards and into production IT? As you might have guessed, the answer remains a disappointing sort of. The issue comes down to tools and infrastructure, and the fact that only some SOA components are mature and easy to source.

As the name suggests, a Service Oriented Architecture is one where application functionality is packaged as autonomous services that adhere to industry standard interfaces (WSDL, SOAP), and the services are then deployed in an IT architecture that makes for their most effective use. The component services can be rapidly reused and composited, plugged and played as it were, to create new business offerings and they can be individually upgraded for increased business agility. However, to achieve the promise of a SOA it's imperative that critical non-business logic-related functionality, the foremost of which is security, should also be provided and used as a service. And for this to occur it has to be externalized, accessed, and managed independently from the business logic-related services.

I recently attended a security conference where thousands of security products from hundreds of vendors were all vying for attention. While most of these products filled a legitimate need, the array of products reminded me of an orchestra warming up. Each instrument may sound good by itself, but together they would be cacophonous without a conductor.

When SOAP-based Web Services solutions began appearing five years ago, one of the major challenges was securely propagating end-user identity in Web Service chaining scenarios. Certainly a user could authenticate to a portal, and that portal could talk to a Web Service that talks to another Web Service that talks to another Web Service (and so on), but the big question was - how could each point in the Web Service chain be assured who the requesting end user really was?

Developing under a Service Oriented Architecture (SOA) is different from traditional development. A large set of business changes will now be funneled through a relatively small number of enterprise services. An inefficient or bad build system can impact a greater number of business changes. As services are exposed to more consumers and so to more potential threats having a robust and secure development environment is more important than ever. Centralized role-based control of builds and reporting of build activities is critical for incorporating a greater number of changes and managing the security and auditability of Web Services.

Over the past five years, the promise of enterprise information sharing has made great strides with the evolution of Web Services and the promise of Service Oriented Architectures (SOA). An architectural shift that moves us away from point-to-point client/server systems.

McAfee the leading dedicated security company, announced that Foundstone Professional Services will launch a series of free tools that teach developers, programmers, architects and security professionals how to create more secure software. The tools will also review the root causes of increasingly prolific crimes such as e-shoplifting, session hi-jacking and identity theft.

The WS Secure Conversation specification describes a mechanism letting multiple parties establish a context (using the WS Trust Request Security Token standard) and secure subsequent SOAP exchanges. Each WS Secure Conversation session has an associated shared secret. Instead of using this shared secret directly to sign and encrypt the conversation's messages, symmetric keys are derived from the secret itself. Deriving new keys for each message and different keys for signature and encryption limits the amount of data that an attacker can analyze in attempting to compromise the context.

Typically when we think about security for a Web service, our focus is on how to protect it from unauthorized and malicious users. Thus, we tend to concentrate on such things as authentication of the requestor, checking to see that the requestor is authorized to access the service, validation of the request message, and so forth - all things that happen on the way in or during a request for the service. However, there is an equally important set of security functions that need to occur on the way out or after the service has finished processing the request.

As organizations move to service-oriented architecture (SOA), security becomes one of the key concerns impacting deployment. After all, a company's most sensitive information is frequently stored in the business systems that are now being accessed by the Web services employed within an SOA. As such, security concerns have become part of the enterprise decision-making process relating to the adoption of a SOA.

'The best approach to selecting the optimal Web services security solution is to assess the needs to be met and then to identify a solution that best fits those needs, precisely and affordably,' according to Forum Systems. Key to this approach is the avoidance of one-size-fits-all solutions that may be over-engineered to underperform.

I'm sure I'm like many of you in this respect: I got into engineering because I love the idea of being able to address complex problems with a combination of my talent, my friends' talent, and the tools that I can come up with to make our work as easy as possible (work smart not hard!). It is this approach that has guided me in my work as an application and technical architect.

Web services and the Grid are converging! The prospect of grid-based, commodity computers delivering run anywhere, anytime Web services across the Internet has hype-o-meters showing a speedy rise and marketing departments gearing up everywhere.

According to the latest Web services 'hype cycle' from Gartner, both Web services security standards and the deployment of Web services with security are rushing headlong into the dreaded 'Trough of Disillusionment.' This means that the greatest levels of hype in these areas are supposedly behind us and the reality of just what can and cannot be done is collectively dawning on us.

Traditional development produces applications that are closed to wide usage. Custom development is required to open these programs to wide-scale integration. In contrast, Web services applications are by default open to other systems and additional configuration is required to block access.

With increasing Web-based transactions, the need for secure communications between applications increases.

Traditional development produces applications that are closed to wide usage. Custom development is required to open these programs to wide-scale integration. In contrast, Web services applications are by default open to other systems and additional configuration is required to block access.

W.C. Fields once said, 'The practice of keyhole-listening is usually confined to hotels and boarding houses. It is absolutely indefensible to stoop so low. If the transom is not ajar, remember there are plenty of other rooms in the building.' Hackers on the Web can take a similarly cavalier attitude - surfing from site to site until they find one whose 'transoms are ajar.' The question for you is whether yours are among them.

DataPower and Computer Associates have extended their existing partnership for providing unified XML Web services security and management by integrating DataPower's XS40 XML Security Gateway with CA's eTrust Identity and Access Management Suite.

The Web Services Interoperability Organization (WS-I) has announced the availability of the WS-I Basic Security Profile Working Group Draft.

Last month (WSJ, Vol. 4, issue 2), we looked at how Web services should not depend on specific security environments and rules but should be managed as part of all of an enterprise's corporate data assets such as Web applications, ERP systems, and in-house applications.

As we move from the 'Hello World' days of Web services toward development that can truly support the enterprise, there are some advanced functional requirements for Web services, including secure messaging, reliable messaging, and Web service policies. Since interoperability is the 'Holy Grail' of XML and Web services, we must maintain this interoperability while supporting such advanced Web service functionalities.

Deploying XML Web services in the enterprise has many compelling advantages. Web services provide a powerful foundation for building loosely coupled distributed applications and service-oriented architectures (SOAs). Enterprises use Web services to lower the integration cost of business-to-business solutions, allowing partners to share business documents without custom coding.

Web services are past the initial marketing hype. Early Web services were part of experimental one-off projects within a single enterprise department. Now, larger Web services deployments are moving outside of the enterprise firewall to better leverage existing business partnerships and value chains.

Once merely so much hype, Web services are finally taking root in corporate IT. However, as organizations grow their Web services from pilots to internal integration projects to extra-enterprise deployments, they face a tangle of new security challenges.

Security is cited as the number one concern in building and deploying Web services today. Web services are inherently a different architecture that presents a whole new set of challenges. You will have to reexamine many of the security aspects of your infrastructure, such as confidentiality, integrity, authentication, nonrepudiation, and cohesion.

Security is not a new concern for companies that want to protect key information and systems from unauthorized access. Protection from such attacks has traditionally been achieved by placing those systems in a tightly controlled intranet accessed through a hardware firewall, possibly over secure TCP/IP connections. However, as more information and functionality are made available over the Web and distributed computing begins to cross corporate Internet boundaries, these mechanisms are no longer adequate. In addition, new concerns arise as a result of distributed computing and transacting business over the Web.

It's well known that Web services need security. It's also a truism that lack of security is the barrier to the adoption of Web services. Let's dig a little deeper: What is it about Web services that provoke the security concerns? What is being done to answer the challenge? By answering these questions, this article attempts to dispel some of the confusion around Web services security.

Remember the old days when we only installed applications that were purchased from the local computer store? Actually, this was the only way to get the application media. Also, because we had mass-produced disks or tapes this provided an additional sense of security.

This article focuses on the value of Web services security. It is important to understand what Web services are and their challenges, particularly related to security. Traditionally, companies have relied on conventional, transport-level security but this approach has its limitations. The market now offers complementary XML-based solutions designed to secure documents used in Web services requests and responses. We will explore these solutions and outline 'typical case scenarios' to provide a comprehensive landscape on the current offering of Web services security solutions.

In survey after survey, security is the most frequently cited barrier to developing distributed applications using Web services technology. In some cases, the findings indicate that the overall level of security concerns among information technology professionals appears to be increasing (Evans Data). Yet in spite of these trends, enterprise adoption of Web services technology is clearly accelerating. Smart organizations recognize that they must move forward with Web services deployments - employing a variety of security tactics - to avoid the greater risk of being left behind as their competitors embrace and benefit from Web services technology.

Businesses need to provide their users with a method for securely connecting to their networks while minimizing the costs associated with providing this service - and also providing end users with as much convenience as possible.

Web services is a promising technology with the potential to greatly simplify B2B enterprise application integration. This is good news for any organization trying to provide seamless access to their business applications for their customers and partners.

The actual definition of a Web service is a matter of some debate because the world of Web services can extend from small closed networks to global discovery services implemented using UDDI (Universal Description, Discovery, and Integration). But at a practical implementation level it is useful to think of a Web service as any software service that can be defined using WSDL (Web Services Description Language) and which uses SOAP for communication between a requester and a listener. This communication uses SOAP as the enveloping protocol.

Web services have enormous promise, but not a single company today is yet fully tapping their potential. Indeed, early adopters are experimenting through carefully controlled pilots that take advantage of the evolutionary nature of the technology, and CIOs and IT organizations - fatigued by yet another 'new new thing' - are adopting a show-me attitude that requires Web services companies to prove that their offering works...and will create measurable value.

When you hear the word security, what comes to mind? SSL? Firewalls? Authentication? Authorization? B-52 bombers? Security means different things to different people, but in the context of securing applications, we can think of security in two parts: access control and secure communication.

Labeled as the coming nirvana for enterprise application integration and business-to-business (B2B) integration, Web services technology is nonetheless vulnerable to a wide array of security threats such as denial of service and spoofing. In this article, we'll review Web services security requirements, the factors that determine them, and how Microsoft's .NET Framework supports them.