Service-Oriented Architectures offer a number of potential benefits: They can provide new opportunities to connect enterprises with customers, partners, and suppliers; improve efficiency through greater reuse of services across the enterprise; and offer greater flexibility by breaking down IT silos. But these benefits make security more critical than ever. Why? Services are highly distributed, multi-owner, deployed to heterogeneous platforms, and often accessible across departments and enterprises - and this creates major security issues for developers, architects, and security and operations professionals. Fortunately, there are ways to make your SOA more secure. If you're building applications to SOA using J2EE, BPEL, or XML, you can build security into an SOA by addressing security throughout the entire application lifecycle - not just at deployment time.

We'll examine the types of attacks applications are vulnerable to, and then outline a holistic approach to protecting applications and services that encourages secure coding practices and the use of Web Services security infrastructure. You'll learn how to protect services from the outside (with infrastructure) and inside (through static analysis of your code). Finally, you'll see how all the pieces come together as we work through an example of an auto loan application.

Typical Attacks
What types of attacks do you need to be aware of when you're building applications to SOA using Web Services? As it turns out, the key aspects that make your SOA more successful - the ability for developers across your departments and trading partners to be able to find applications exposed as services, and the way that WSDL documents define operations that can be invoked - may also make it appealing to hackers.

Here are some potential vulnerabilities:

• Authentication/authorization. Without the appropriate mechanisms in place, anyone can access a service, invoke it, and perform sensitive operations even if he's not authorized. More often what typically happens is that it takes a while to de-authorize entities from accessing systems. In the meantime, they have free rein. Identity Management and Web Services Management (WSM) solutions, and XML firewalls can help.
• Spoofing. Gaining access to a system by using a stolen identity. If you log and audit service interactions, operations employees can identify who did what and when in the event of a spoof.
• Tampering. Unauthorized modification of data, such as header information including WS-Addressing, as it flows over the network. Digital signatures, which are based on the message, ensure message integrity. Another form of tampering takes the form of JavaScript that alters the contents of the XML document and can redirect the communication from the Web browser.
• Repudiation. Users (legitimate or otherwise) may deny that they made specific transactions. Logging and auditing capabilities address this.
• Information disclosure. The unwarranted exposure of private data when on the wire. Encryption helps ensure confidentiality but doesn't ensure message integrity.
• Denial of service. Making an application unavailable by sending a huge number of requests or very large XML payloads. (This is a problem only if it breaks your application!) XML firewalls and appliances let you protect your services from such attacks.
• Invalid messages. Certain XML messages can contain malicious code such as SQL statements, viruses, or worms that can compromise or corrupt data, applications, and systems, and potentially leave them exposed. This code can appear in the body of the XML document or in CDATA tags. Hackers tamper with the SOAP messages themselves to disable the service through illegitimate or malformed requests.
• Replay attacks. If tokens/cookies are used for secure conversation, the attackers can capture the tokens/cookies and re-use them later by replaying the same.
• XML routing detours/external referencing. XML documents can contain references to external structures.

A Holistic Approach To Protecting Services
To protect against these potential vulnerabilities, you should take a holistic approach to security that includes infrastructures, tools, and software development practices:

• Protect services from the outside at deployment time by using WSM solutions. This addresses issues related to identifying the message sender, authentication, authorization, ensuring message security, and verifying the structure of SOAP headers and XML documents. Security policies can be applied to both inbound and outbound service interactions. Don't worry about these: Your WSM infrastructure sits outside your service and takes care of them for you.
• Protect services from the inside by building security into your software development process. You must validate the input in your code to protect yourself against attacks that result from invalid messages. By validating the content of XML documents, you address attacks that result from invalid messages, such as buffer overflow, SQL injection, XML injection, and XPath exploits. Use static analysis tools to help identify such vulnerabilities.
• Simulate known attack patterns and fix vulnerabilities before going live by using dynamic analysis tools in a running deployment during the QA process. By putting the attackers' hat on and stress-testing your SOA applications, you can help uncover and resolve vulnerabilities before deployment. Although you may have to work a little harder during the QA process, you'll get fewer post-deployment headaches, which more than makes up for it.
• Monitor post go-live using monitoring dashboards (part of WSM solutions) that present data that's collected as security policies are executed on services. These dashboards let administrators monitor compliance with IT operational best practices in real-time, such as audits on security violations on a per-Web Service, per-operation, and per-client basis. To address vulnerabilities, administrators can configure operational rules and propagate them to the appropriate enforcement components across an application deployment of any scale and complexity in real-time.

Protecting Services from the Outside
Most Web Services are based on the same technology as the Web, namely HTTP. As a result, all common technologies used to secure the Web, such as Web authentication and SSL, work equally well with Web Services - for point-to-point security. With SSL alone, you can do authentication (the communication is established between two trusted parties); confidentiality (the data exchanged is encrypted); and, message integrity (the data is checked for possible corruption). However, solutions such as SSL are a little heavy-handed since they secure the entire channel. Furthermore, for many message-based interactions, intermediary steps are required before the messages arrive at their target endpoint. This leaves XML messages unsecured at each intermediary checkpoint - exposed to tampering, information disclosure, and message altering.

To get a finer level of control and avoid intermediary security issues, it's best to secure the message rather than the complete transport. The idea is to replace SSL capabilities with message-level security, where the security information is carried in the message itself. This way, unless the intermediary or endpoints have the correct security infrastructure in place and are trusted, the message will remain secure and unreadable and can be forwarded to the next endpoint.

So how do you secure the message rather than the transport? WS-Security defines a mechanism for adding three levels of security to SOAP messages:

1. Authentication tokens. WS-Security authentication tokens let the client provide a user name and password or X509 certificate for the purpose of authentication headers.
2. XML encryption. WS-Security's use of W3C's XML encryption standard enables the XML body or portion of it to be encrypted to ensure message confidentiality.
3. XML digital signatures. WS-Security's use of W3C's XML digital signatures lets the message be digitally signed to ensure message integrity. The signature is based on the content of the message itself (by applying the hash function and public key), so if the message is altered en route, the signature becomes invalid.

There are two ways to implement this: You can embed the logic for processing tokens, handling encryption, and applying hash functions and digital signatures in the service implementation itself, or you can use a WSM solution. The first option is shown in Figure 1.

WSM solutions intercept incoming and outgoing service communications and apply a set of policies in a pipeline fashion, including authentication, authorization, decryption, signature validation, and XML schema validation. They move the active enforcement of the policies and agreements to the boundaries of an application, letting the application developer concentrate on the business logic. These solutions typically provide a policy management tool for building new security and operations policies, storing policies, and managing distribution and updates to runtime policy enforcement points. In this way, policies are defined and changed centrally but enforced locally. If you have to authenticate to an Identity Management System that's not supported by the WSM solution out-of-the box, such as a JAAS login module, Oracle Web Services Manager, as well as many WSM products, provides an SDK for developing policy steps. They provide operational dashboards for monitoring policies as they execute to ensure service levels, incorporating alerts so corrective actions can be taken in a timely fashion.

WSM solutions typically provide two types of enforcement components and policy enforcement points: Gateway and Agents. Gateways are deployed in front of a group of applications or services. They can intercept inbound requests to these applications to enforce policy steps, adding application security and other operation rules to applications that are already deployed. They also allow (or deny) inside users access to predetermined outside services. Agents provide an additional fine-grained level of security by plugging directly into an application or service.

Service virtualization is also a key capability. Typically an Internet user makes a service request using a username and password combination, but the service may be expecting a SAML assertion. With a WSM solution, you can have a gateway on the requester side that intercepts the request, authenticates the user with the username/ password combination, and inserts a SAML assertion that can be validated at the service by a WSM agent. In effect, the user calls a service in a virtual way through the credentials that he knows, not the credentials that the Web Service is expecting.

Figure 2 shows the context in which a WSM solution can be deployed. Note that you could deploy an XML firewall or appliance before the gateway. These appliances are typically good at applying macro policies and protecting against attacks such as buffer overflow attacks, which don't require application context.

Securing Services from the Inside
Securing applications from the outside isn't enough to protect your application. Web Services gateway solutions, whether implemented in an appliance or software, can't confidently check the content of XML messages since they don't have the application context. Hackers use this knowledge to embed malicious content in the XML documents that pass straight through the WSM software to the service interface of the application.