XML Gateway Rollout

This final case study examines the use of an XML security product in order to provide security for an organization’s XML-based communications with its partners. This case study includes the concept of an XML firewall. It also walks through the configuration of a product for the security of Web Services.

Project Overview

A large financial services company required the ability to secure and monitor all XML traffic entering and leaving their private network. This large organization had multiple entry points and multiple exit points, which required security. XML data would be received from a wide variety of partners, though not from the general public. The organization required the establishment of an XML gateway prior to the actual deployment of Web Services.

Security Factors Identified

Because this XML gateway must receive XML data from the outside world, it must not be susceptible to direct attack itself. This would include vulnerabilities to a denial of service attack or to a buffer-overflow attack. It was important, therefore, that a security gateway should not itself be a point of vulnerability. A policy was devised for the use of locked-down operating systems and Web servers. This involved the application of security patches as they were issued and the blocking of all unused TCP/IP ports. A firewall was configured to ensure that low-level attacks were blocked, and it was mandated that SSL would always be used for encryption and mutual authentication of all HTTP traffic received by the XML gateway.

The next security factor that was identified was the existence of multiple entry points to the organizations, all of which may receive XML traffic. If XML security was only deployed at a single gateway, then it would be like deploying border guards at only a single border crossing and asking smugglers to “helpfully” only use that border crossing. A distributed solution, enforcing security across all XML entry points, was required instead. However, a further security issue was triggered by the use of a distributed architecture. If policies must be replicated across different gateways, there were dangers that version control would become out of sync.

A further security factor was that a variety of protocols and XML filtering functionality was required. When XML data was received, it first had to be checked to ensure that it was targeted at a Web Service intended to be available to partners. Once the target of the XML data was discovered, a policy had to be enforced for that Web Service. This meant that XML security policies had to be configurable per service, because some services may require more security than others. Requests to Web Services that were not supposed to be publicly available had to be blocked. The organization also required that the XML sent to each Web Service was appropriate, requiring it to be validated against an XML Schema at the gateway.

Incoming messages were to be authenticated using digital certificates contained within SOAP messages. It was important that the signature would convey proof of possession of the corresponding private key. This was achieved by including a timestamp within the signed data. In the future, it is planned to use WS-SecureConversation in order to negotiate a session key for the communication.

Finally, the organization wished to be alerted when XML messages were blocked by their XML gateway. They did not require this information for each individuate blocked XML message, but wanted to be able to raise an alert if the number of blocked messages for any given security rule exceeded a certain level.

Security Measures Deployed

Part of this project involved XML firewalling functionality. XML firewalling was defined as filtering XML traffic based on the content of the traffic, as opposed to identity-based access control that involves filtering XML traffic based on the sender of the traffic. An XML firewall performs similar functionality to a traditional firewall, except at the SOAP application layer.

An XML firewall is similar in concept to an application-level gateway firewall. Application-level gateways filter packets at the application layer. They are aware of what traffic meant for specific applications should look like. For example, an application layer gateway knows the difference between Web traffic and telnet traffic, even though both use TCP/IP. Application-specific commands and user activity can be logged. These firewalls are relatively processor-intensive. An application-level gateway will know that if it is protecting an e-mail POP server, the command “USER” is allowed and takes one parameter (that is, the username). Anything else is not allowed. For example, traffic that looks like telnet traffic directed to the POP server will be blocked.

Many firewalls have been configured to only allow Web (HTTP, SSL) and e-mail (POP, SMTP) traffic to pass. Other TCP/IP ports, and other protocols, are routinely blocked. SOAP is often “tunneled” through the Web ports (80 for HTTP, 443 for SSL), effectively disguised as normal Web traffic. This is generally not done for malicious reasons, but rather for pragmatic reasons because all other ports are blocked. In particular, SOAP is very frequently bound to HTTP. When a traditional firewall examines a SOAP request received over HTTP, it might conclude that this is valid HTTP traffic and let it pass. Firewalls tend to be all or nothing when it comes to SOAP. A SOAP-level firewall should be capable of the following:

• Identifying if the incoming SOAP request is targeted at a Web Service that is meant to be available.

• Identifying if the content of the SOAP message is valid. This is analogous to what happens at the network layer, where IP packet contents are examined. However, at the application layer it requires data that the Web Service expects.

Note that an XML firewall only provides part of the functionality that is required in this case study. This is because, as well as requiring only the appropriate data to enter the organization, only the appropriate senders of the data should be allowed. Firewalls do not typically provide security based on identity. However, firewalls are often combined with VPNs, which provide this functionality. The firewall/VPN combination is comparable to an XML gateway that combines XML Firewalling with identity-based access control using WS-Security and SAML.

For this case study, the organization used the VordelSecure product, which combines XML firewalling functionality with access control using WS-Security and SAML. Let’s walk through the configuration of this product in order to re-create the settings used in this case study.

VordelSecure uses a tool called a Security Management Wizard to set security policies for XML traffic. Policies are set up per service, with the Web Service identified using a combination of SOAP endpoint, method name, method URI, and SOAP action. Look at Figure A-1 and you will notice that a Web Service called Calc has already been set up.

Figure A-1: The Security Management Wizard in VordelSecure

Click Add Policy in order to set a policy for an XML gateway. The enforcement of this policy can be distributed across multiple XML gateways, using VordelSecure’s distributed architecture. Notice that there is an option to load a policy from a WSDL file, rather than configuring it manually (see Figure A-2).

Figure A-2: Loading a Web Service description in VordelSecure

Because policies are enforced on a per-service basis, it is important that the service is defined accurately so that VordelSecure can identify the target of traffic it receives. If the target cannot be identified, the XML communication in question is dropped by VordelSecure.

The configuration screen shown in Figure A-3 gives the option to use a preexisting security policy to configure the traffic to this Web Service.

Figure A-3: Basing a security policy on a preexisting policy

Notice in Figure A-3 that the security options for the Web Service are listed on the right of the screen. These range from XML firewall functionality (that is, “content filtering”) through to identity-based functionality (that is, authentication and authorization). Press Next to move to the next screen in order to configure XML Signature validation over the incoming SOAP message. This screen is shown in Figure A-4.

Figure A-4: Integrity filter, using XML Signature

Figure A-4 shows an XML Signature filter being configured in such a way that it will be enforced over the entire SOAP body. The SOAP body is identified using the XPath expressing “//soap:Envelope/soap:Body/*.” This is the minimum content of the SOAP message, which must be digitally signed. Note that the SOAP namespace is configured using the Edit button below the XPath selection box. If the WS-Security option is chosen, the administrator can choose which SOAP actor for which XML Signatures will be enforced, or the administrator may choose to enforce XML Signatures for all SOAP actors referenced within the SOAP message.

The next option is to configure an XML Schema to be enforced over the incoming data. This is shown in Figure A-5. Again, an XPath expression is used to narrow down the portion of the SOAP message that must be validated against the XML Schema.

Figure A-5: XML Schema enforcement

Tip

The use of Schema validation is processor-intensive, and is only recommended if the machine on which it is implemented is suitable for high-volume XML processing.

We have already seen XML firewalling based on the integrity of the SOAP body (using XML Signature to validate the integrity) and XML Schema to validate the structure of the SOAP body. It may be required to go a level deeper and look at the content of individual XML elements and attributes. This was not required for this case study, which only required the integrity and schema validation aspects of XML firewalling.

Next we move on to identity-based security. Figure A-6 shows message authentication using X.509 certificate validation being configured. Recall from Chapter 2 that message authentication using an X.509 certificate requires proof of possession of the associated private key; otherwise, an intruder could simply copy and paste the certificate into a different SOAP message.

Figure A-6: Configuring message-based authentication

By pressing the Configure button shown in Figure A-6, the administrator can determine which certificate is to be used for authentication, because a single SOAP message may contain multiple XML Signatures, each associated with a different X.509 certificate. The steps for X.509 certificate authentication used in this case study were as follows:

1. Validate the XML Signature associated with the X.509 certificate. Ensure that the appropriate data has been signed. The signed data included a timestamp. This ensured that attempts at replay attacks would be detectable.

2. Ensure that the certificate is still valid. This is done using a SOAP message sent to an XKMS trust service.

3. Ensure that the certificate has been issued by a trusted certificate authority.

Once these steps have been performed, VordelSecure can be configured to send successfully authenticated messages to the target Web Service.

Figure A-7 shows routing being configured for an internal Web Service, so that messages that successfully pass the XML gateway can reach the Web Services that sit inside the organization. In this case study, it was decided not to use SAML because the partners using the Web Service did not have the capability to issue SAML assertions to insert into SOAP messages. In addition, the overhead of issuing SAML assertions to insert into messages sent from the gateway to an internal Web Service was seen as unnecessary.

Figure A-7: Routing successful messages from the XML gateway to an internal Web Service

Recall that the organization in this case study wished to raise an alert if the number of blocked XML messages exceeded a certain amount. Figure A-8 shows this functionality being configured in VordelSecure.

Figure A-8: Configuring alert conditions in VordelSecure

In conclusion, this case study shows an XML security product being used to secure a Web Service, based on XML firewalling—that is, characteristics of the data, and based on which service is being targeted—and based on access control information from within the incoming XML message (in this case, an X.509 digital certificate). In Chapter 9, we saw how a SOAP request containing an X.509 certificate as a security token can be created using C#. Now we have seen how a security policy can be configured to enforce a server-side security policy based on the existence of security tokens within incoming SOAP messages.