This chapter discusses standard security features available to solutions developed using Java CAPS or hosted in the Java CAPS Integration Server. In particular, HTTP Basic Authentication, Secure Sockets Layer (SSL), Secure batch eWay variants, and configuration of Hypertext Transfer Protocol (HTTP) and Hypertext Transfer Protocol over SSL (HTTPS) Proxy are discussed.
By Peter Vaneris
A Web Proxy is an infrastructure component that mediates HTTP protocol exchanges between internal clients and external servers. In some circumstances, you may be required to connect to an external HTTP Server, whether a Web Server or a Web Service provider, via an HTTP Proxy Server. All Java CAPS components are hosted, at runtime, by the Integration Server. Configuration of HTTP and HTTPS Proxy will vary from Application Server to Application Server. For the Sun SeeBeyond Integration Server and the Sun Java System Application Server 8.x, you need to configure appropriate Java Virtual Machine (JVM) properties. Available proxy configuration options are discussed below.
To require all clients using the HTTP or the HTTPS protocol to use a Proxy Server, the following JVM properties can be set, indicating the host name/address and the port number of the proxy:
-DproxyHost=<ProxyServer.domain.com> -DproxyPort=<ProxyServerPort>
To require all clients using the HTTP protocol, as distinct from the HTTPS protocol, to use a Proxy Server, the following JVM properties can be set, indicating the host name/address and the port number of the proxy:
-Dhttp.proxyHost==<ProxyServer.domain.com> -Dhttp.proxyPort=<ProxyServerPort>
To require all clients using the HTTPS protocol, as distinct from the HTTP protocol, to use a Proxy Server, the following JVM properties can be set, indicating the host name/address and the port number of the proxy:
-Dhttps.proxyHost==<ProxyServer.domain.com> -Dhttps.proxyPort=<ProxyServerPort>
To provide an exclusion list, the list of hosts for which the proxy is not to be used when HTTP protocol is used, the following JVM property can be set, listing fully qualified or wildcarded names of hosts, separated by a pipe character (“|”).
-Dhttp.nonProxyHosts=edesigner*|emanager*|localhost
Note
The Enterprise Manager is referenced by both short host name and fully qualified domain name during a single session, so the hostname* covers both.
Similarly, -Dhttps.nonProxyHosts can be set to exclude hosts when the HTTPS protocol is used.
The diagram in Figure 14-1 shows HTTP communications between a Java CAPS domain and other typical components in an environment when a Proxy Server is used.
This section assumes familiarity with the theory behind the HTTP Basic Authentication mechanism. See RFC 2616 for a detailed explanation of HTTP, HTTP Basic Authentication, and related matters [HTTP].
HTTP Basic Authentication in Java CAPS is configured independently for the HTTP Client and the HTTP Server. The HTTP Client supplies credentials that are validated against some server’s authentication infrastructure. Any authentication infrastructure that might exist at the client does not get used.
You supply HTTP Basic Authentication credentials for the HTTP Client eWay through the HTTP Client external system container in the eDesigner Environment Explorer, as shown in Figure 14-2.
Needless to say if a different username/password is required for different deployments, each variation requires its own HTTP Client external system container. The runtime effect is to supply an Authentication HTTP header with the value of BASIC xxxxxxxxxxx, where xxxxxxxxxxx is a base64-encoded string consisting of the username, the literal “:” and the password.
In contrast, HTTP Basic Authentication at the server side uses the Integration Server’s Authentication infrastructure, so not only must the HTTP Server external system container be configured to require HTTP Basic Authentication, but also the Integration Server’s authentication infrastructure must be configured to support the username, password, and group that the HTTP Server expects.
Among other things, the Integration Server Administrator allows the administrator of the Java CAPS installation to create the Integration Server users–runtime users who can be granted access to resources. To implement the HTTP Basic Authentication for a solution that involves an HTTP Server eWay, you need to create a user. The Integration Server Administration Console User Management tab, shown in Figure 14-3, illustrates this.
Adding a new user requires provision of a username, a password, and one or more group names, as shown in Figure 14-4. These group names are not defined elsewhere, but one is required to configure HTTP Basic Authentication in the HTTP Server external system container.
To force HTTP Clients to use HTTP Basic Authentication, the HTTP Server external system container must be configured to require HTTP Basic Authentication. This is illustrated in Figure 14-5.
Note the Group Name and Role Name properties. Values for these properties must be supplied; otherwise the HTTP Basic Authentication will not be enabled, but, at least through version 5.1.3, they are not used. Note also the group and role J2EE Web Container concepts. HTTP Basic Authentication has no concept of groups and roles; therefore it does not carry this information.
If you build a solution that involves an HTTP Server eWay and deploy the HTTP Server eWay to the HTTP Server container whose HTTP Basic Authentication is configured, at runtime the HTTP Client will be required to provide appropriate credentials.
If the HTTP Client happens to be a Web browser, the user will be presented with an Authentication dialog box, as shown in Figure 14-6.
If the HTTP Client happens to have no interactive user, it will need to provide the Authentication HTTP header as part of the initial request, or it will have to handle the 401 HTTP Response Code and resubmit the original request with the Authentication header when it gets the 401 from the server. For the HTTP Client eWay, this is configured in the HTTP Client external system container in the eDesigner environment, as shown in Figure 14-7.
At runtime, the HTTP Client eWay will use these values to create the required Authentication HTTP header that will be sent as part of the HTTP GET or POST request.
Note that if the HTTP Server eWay is deployed to an HTTP Server external system container in which HTTP Basic Authentication is not enabled, or in which it is misconfigured, no HTTP Basic Authentication will be required of the client. To prevent this from allowing unauthorized access to resources, a Java Collaboration would contain a conditional expression evaluating an authentication type header and returning a 401 Unauthorized status if not present or incorrect.
The code fragment in Listing 14-1, which assumes that the input to the collaboration is an HTTP Server eWay connector, will do the trick.
Example 14-1. Programmatically require HTTP Basic Authentication
if (input.getRequest().getAuthType() == null
|| !input.getRequest().getAuthType().equalsIgnoreCase( "BASIC" )) {
input.getResponse().setErrorStatusCode( 401 );
input.getResponse().setErrorStatusMsg
( "Invalid Request - Expected BASIC Authentication" );
input.sendResponse();
return;
}With the advent of electronic commerce over the Internet, “secure” Web sites were typically required to provide security for submission of credit card details so that the details did not get disclosed to third parties. Transmission Control Protocol (TCP)-based HTTP protocol does not inherently provide confidentiality features necessary to prevent malicious parties from obtaining credit card details by snooping on the wire. Early in the life of the World Wide Web, two competing solutions were proposed: Secure HTTP [S-HTTP][RFC2660] and Secure Sockets Layer [SSL], subsequently standardized as Transport Layer Security (TLS) [TLS]. As history demonstrated, the SSL and its Internet Engineering Task Force (IETF) standardized reincarnation, TLS, became widely deployed for use in both the World Wide Web deployments and other applications layered over HTTP, most notably Web Services. Since TLS version 1 .0 is effectively an IETF officially blessed SSL version 3.0, the acronym SSL is used henceforth to also mean TLS. SSL implementations provide communications privacy for applications using the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.
The need for SSL arose out of the need to ensure that submission of credit card information to an eCommerce Web site is confidential and that the Web site to which credit card information is being submitted is indeed the Web site to which the browser user intended to submit that information. This calls for confidentiality and Web Server Authentication. Confidentiality is obtained by encrypting the channel between the browser and the server. Server Authentication is obtained by requiring that the server sends its X.509 Certificate to the browser. The (human) browser is expected to verify that the X.509 Certificate is indeed the certificate of the Web Server to which the (human) browser is prepared to disclose credit card information. The technical details of how encryption and certificate conveyance are carried out are documented in the Requests for Comments and elsewhere.
There are a few important points to note about the SSL protocol:
SSL protocol has a notion of a session that is established between the client and the server when the SSL handshake has been successfully completed.
When the SSL handshake is in progress, the client and the server negotiate which cryptographic algorithm to use, among other things.
SSL has a notion of anonymous key exchange method; when this method is used no certificates are used for key exchange.
The negotiated cryptographic algorithm may not be the strongest that either the client or the server is capable of supporting.
Outside North America, SSL implementations by default use the “export” cipher suites, which are considered weak.
To use “strong” algorithms, Java-based implementations may require download of unlimited strength cryptographic policy file and reconfiguration of the runtime environment to support these algorithms.
Authentication of server to client, client to server, or mutual authentication are all optional. If anonymous key exchange is used, the server is considered anonymous: it does not send its certificate to the client. Whether the server is anonymous or not depends on its SSL configuration.
Note
The X.509 Certificate does not convey any meaning apart from the fact that some Certification Authority, which issued the certificate, is prepared to vouch that the public key embedded in the certificate is associated with the identity (person or organization) also specified in the certificate.
Note
Possessing a public key that you are sure belongs to Joe allows you to encrypt information with confidence that it can only be read by Joe. This confidence is provided by your trust in Bob’s assertion of the relationship between Joe and Joe’s Public Key and your confidence that the asymmetric cryptographic algorithm you use is strong enough to protect what information you wish to send to Joe in confidence. None of this has any relevance to SSL/TLS, since:
SSL/TLS uses symmetric cryptography for encrypting data on the wire.
A secure channel is established between the client software implementation and the server software implementation, not between you and Joe.
Any data can be carried over an encrypted channel. There is no association between the channel and the data it carries; therefore authenticity of the sender or receiver is not carried over to the data that travels over the channel.
The data that enters the secure channel can come from anywhere and can go anywhere after it leaves—a secure channel does not guarantee data security before it enters the channel or after it exits.
Once data leaves the secure channel, any authenticity implied by it having come out of the channel is no longer valid.
Note
To make it plain: Bob, whom you may or may not know, and whom you may or may not trust, tells you that the public key with Joe’s name on it belongs to Joe. You must decide whether you trust what Bob tells you and whether Joe is the Joe with whom you wish to communicate. Bob does not tell you that Joe is a good and trustworthy person, and even if he did, that is a piece of information that neither the public key nor the certificate has anything to do with.
The SSL allows the server to send its certificate to the client. So that the client does not need to obtain and install beforehand certificates of all possible parties with whom it may communicate, the client accepts this certificate if it is signed by a trusted Certification Authority. The client keeps certificates of trusted certification authorities in a truststore. Effectively, any server whose certificate is signed by a Certification Authority, whose certificate is in the client’s truststore, is trusted.
In normal interaction with a secure eCommerce site, the client is the party that needs assurances as to the identity of the server. The server does not require the client to authenticate as it gets customer’s credit card information, which is enough for payment to be obtained from the customer. Authenticity of the client (customer’s browser) is irrelevant and not sought. This is termed server-side authentication.
In other circumstances the server may require the client to authenticate before service is provided. The SSL supports this by allowing the server to be configured such that after it sends its certificate to the client, it requires the client to send the client’s certificate back as part of the SSL handshake. This is termed mutual authentication.
The identity of the party with whom the Public Key is associated through the X.509 Certificate is expressed using a number of attributes. One of these attributes may be a hostname when the subject of the certificate is a TCP host. SSL implementations can be configured to expect that the hostname attribute embedded in the certificate, which the server sends to the client, matches the hostname that the TCP implementation reports as the hostname of the host with which the client is communicating. Requiring hostname match is intended to prevent rogue sites from masquerading as legitimate sites. If the implementation is configured this way, and the hostname changes, the certificate has to be reissued. This causes expense or inconvenience or both. How to deal with such issues is a site decision.
In summary, endpoints in a secure channel can be configured to support server-side authentication or mutual authentication and can be configured to require or ignore hostname validation.
In Java CAPS, the HTTP eWay and the Web Services communications infrastructure support channel security using SSL. The rest of this chapter discusses how channel security can be configured for HTTP eWay–based applications.
Chapter 12, section 12.2, “Secure Sockets Layer (SSL, TLS),” and its subsections in Part II (located on the accompanying CD-ROM), illustrate the following discussion with complete implementation examples, including log exhibits with SSL handshake interaction traces. Server-side authentication and mutual authentication for the HTTP infrastructure as well as server-side and mutual authentication for eInsight Web Services infrastructure are covered with detailed implementation steps and execution traces.
The HTTP eWay in the Client mode can be configured to attempt to establish an SSL session with the HTTP Server, validate the Server’s X.509 Certificate, and optionally validate the server’s hostname against the Distinguished Name of the host for which the X.509 Certificate has been issued. The eWay can also be configured to respond to the server’s request for mutual authentication with the appropriate X.509 Certificate.
The HTTP Server external container in the environment does not have any properties that pertain to SSL.
By default, port basePort+1 is the plain, clear-text HTTP listener port. The server-side authentication secure channel uses port basePort+4, which is already configured when the domain is created. The mutual authentication channel will need to be created to listen on a port of its own. Default port assignments for an Integration Server start at BasePort+0 and go through basePort+8. Let’s assume we have basePort+9 available and will use it to configure the SSL listener for mutual authentication. Figure 14-8 illustrates typical port assignments.
There is no need to configure the Web container to support a clear-text HTTP channel. The listener on port basePort+1 was created at domain creation time and is ready to use.
Note that whether we are using the clear-text or the secure channel, the responder implementation is identical. SSL handshake and channel encryption operate at the transport layer. The responder implementation does have a way of knowing what kind of channel was used.
The Sun SeeBeyond Integration Server in a domain is configured at domain creation time to support clear-text HTTP channel on port basePort+1 and an SSL channel on an alternate port using an alternate listener. By default, the SSL listener is configured on port basePort+4, it is enabled, it has “access control” turned on, it supports SSL and TLS, and it does not require client authentication. This is the kind of listener that is required for SSL server-side authentication.
When the domain is created, the name and location of the keystore and the truststore, which the SSL listener will use, are defaulted to:
${com.sun.aas.instanceRoot}/config/keystore.jksand
${com.sun.aas.instanceRoot}/config/cacerts.jksthrough the Integration Server Administration console JVM Settings → JVM Options, as shown in Figure 14-9.
A set of JVM configuration properties governs the locations, types, and passphrases for the keystore and the truststore the Integration Server will use. These configuration properties are tabulated in Table 14-1.
Table 14-1. SSL-Related JVM Configuration Properties
javax.net.ssl.keyStore | Specifies the location of the keystore containing the server’s Private Key. There is no default location. |
javax.net.ssl.keyStoreType | Specifies the KeyStore file type. The default is the default KeyStore type: e.g., KeyStore.getDefaultType(). |
javax.net.ssl.keyStorePassword | Specifies the password to be used with this KeyStore. |
javax.net.ssl.trustStore | Specifies the location of the TrustStore. If specified, this overrides jssecacerts and cacerts. |
javax.net.ssl.trustStoreType | Specifies the KeyStore file type. The default is the default KeyStore type: e.g., KeyStore.getDefaultType(). |
javax.net.ssl.trustStorePassword | Specifies the password to be used with this KeyStore. |
Note
Chapter 15, “Cryptographic Objects”, in Part II, walks through the process of obtaining an End Use X.509 Certificate for the test party whose alias is “prtya.” When the steps are followed, a series of cryptographic objects will have been created in directory c: mppkiprtya. Among them are prtya’s Private Key, prty.pem.private.key; prtya’s X.509 Certificate, prtya.pem.cer; and prtya’s Java Keystore, prtya.jks.keystore, which contains both the Private Key and the X.509 Certificate. The Certification Authority that issued prtya’s certificate is DemoCA. The X.509 Certificate of the Certification Authority, c: mppkica DemoCADemoCA.pem.crt, and the JKS truststore containing this CA’s X.509 Certificate will be DemoCA.jks.keystore.
The HTTP Client will need to use the cryptographic provider to use SSL or TLS.
Note
The Integration Server, by default, will use a cipher from a list of cipher suites, shown in Listing 14-2, trying from top to bottom until a cipher suite in common with the client is found.
Example 14-2. Default cipher suites
SSL_RSA_WITH_RC4_128_MD5 SSL_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA SSL_RSA_WITH_3DES_EDE_CBC_SHA SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA SSL_RSA_WITH_DES_CBC_SHA SSL_DHE_RSA_WITH_DES_CBC_SHA SSL_DHE_DSS_WITH_DES_CBC_SHA SSL_RSA_EXPORT_WITH_RC4_40_MD5 SSL_RSA_EXPORT_WITH_DES40_CBC_SHA SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
Unlike the HTTP Server connector in the connectivity map and the external system in the environment, which do not have properties relating to SSL support, the HTTP Client external system in the environment has properties that need to be configured to enable SSL. Figure 14-10 shows a connectivity map with an HTTP Client connector.
The HTTP Client external system in the environment must also be created and its properties configured to support SSL, as shown in Figure 14-11. Table 14-2 enumerates the properties used to configure SSL at the client side and the values used in the example implementation.
Note that because the secure channel is using Server-Side Authentication mode, meaning the client does not need to provide its certificate to the server, the keystore parameters are not configured. Note, too, that the external system is configured to use SSL version 3 protocol, as distinct from TLS version 1, or SSL version 2, all of which are supported by the eWay.
The Web Container/HTTP Listener used to implement server-side authentication was not configured to require a client certificate as part of the SSL Handshake. We could make the trivial configuration change to the HTTP Listener configured on basePort+4 and check the Client Authentication check box. This will, however, affect all connections to this port and therefore may not be desirable.
Note that the following discussion assumes the Integration Server was configured to support server-side authentication, as discussed in section 14.4.3.1.
To support mutual authentication, you must create and configure a completely independent HTTP Listener using port basePort+9, assumed to be available. HTTP Listeners available by default are shown in Figure 14-12.
Note that there already are listeners on ports basePort, basePort+1, and basePort+4.
You would click on the New... button and configure the new HTTP Listener using values similar to those shown in Table 14-3.
Note that some of the cipher suites that the server supports (see section 14.4.3.1) are not available for selection through this interface. Most notably, those in Listing 14-3 are not available.
Example 14-3. Cipher suites not available for selection
TLS_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA
All of the cipher suites in Listing 14-3 use the Advanced Encryption Standard (AES) algorithm.
HTTP Listener configuration is shown in Figure 14-13. Configuring a new HTTP Listener requires restart of the Integration Server.
Unlike the HTTP Server connector in the connectivity map and the external system in the environment, which do not have properties relating to SSL support, the HTTP client external system in the environment has properties that need to be configured to enable SSL.
Note that whereas in the case of server-side authentication the identity of the client was irrelevant, so the keystore-related properties in the HTTP Client external system container were not configured, for mutual authentication identity of the client is important and the keystore properties must be configured. In our case, the client is prtyb and the server is prtya. The server must be able to validate the identity of the client (prtyb), so it must have access to the X.509 Certificate of the Certification Authority that signed the client’s certificate. It so happens that both prtya’s and prtyb’s X.509 Certificates were issued by DemoCA, and DemoCA’s certificate is in the truststore used by both the client and the server. Table 14-4 enumerates properties that must be configured and their values used for the HTTP Client in the example. Figure 14-14 shows these properties and their values in eDesigner.
Table 14-4. HTTP Client Configuration Properties Used for SSL with Mutual Authentication
javax.net.ssl.keyStore | c: mppkiprtybprtyb.eXchange.pkcs12.keystore.p12 |
javax.net.ssl.keyStoreType | PKCS12 |
javax.net.ssl.keyStorePassword | prtybprtyb |
javax.net.ssl.trustStore | c: mppkicaDemoCADemoCA.jks.keystore |
javax.net.ssl.trustStoreType | JKS |
javax.net.ssl.trustStorePassword | democaexport |
Notice that we are still not requiring hostname verification and that the truststore configuration is the same as that used for an HTTP Client in server-side authentication mode.
Configuring the keystore allows the HTTP eWay to find the X.509 Certificate it is required to return to the server when requested.
Even with the mutual authentication configured, the HTTP Requester collaboration is unaware that a secure channel was used to submit the HTTP Request and return the HTTP Response. It can work this out through the schema property value, https, but it is not provided with any indication of what the requester identity was. Mutual authentication happens at the transport level. If authentication fails, the responder collaboration is never invoked.
Java CAPS does not provide the means of conveying a requester’s identity—for example, the Distinguished Name embedded in the X.509 Certificate submitted to the HTTP Responder by the client on request from the server. The HTTP Responder, not knowing requester’s identity, cannot perform further Authentication or Authorization. The only conclusion the responder can draw from the request is that it came from a party whose X.509 Certificate was acceptable to the Integration Server.
With three HTTP Listeners configured in the Integration Server, an HTTP Client can communicate with the same HTTP Responder using either of the listeners. To prevent HTTP Clients bypassing the requirement to use a secure channel, the HTTP Responder must recognize the Schema (http as distinct from https) and/or listener port number and refuse to service the request if it was submitted over an insecure channel.
The alternative to coding an HTTP Responder to discriminate on the basis of Schema or Port Number is to configure only one listener with appropriate security, server-side or mutual authentication, in a given Integration Server. That way, all requests will have to use the secure channel.
To enable strong cipher support outside North America, you may need to download and install Java Cryptography Extension (JCE) Unlimited Strength Policy Files for J2SE 5 (Java CAPS’s Integration Server uses Sun JDK 5). J2SE 5 site is http://java.sun.com/javase/downloads/index_jdk5.jsp. To install Unlimited Strength Policy files, unzip the downloaded archive, jce_policy-1_5_0.zip, and copy the four files it contains to the following directory, then restart the Integration Server.
<JCAPSInstallRoot>logicalhostjrelibsecurity
Once the server is restarted, the cipher suites in Listing 14-4 become available for use, with additional 256-bit cipher suites, enabled by installation of the Unlimited Strength Policy files marked with *.
Example 14-4. Cipher suites added by the Unlimited Strength Policy installation
SSL_RSA_WITH_RC4_128_MD5 SSL_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA * TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA * TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA * SSL_RSA_WITH_3DES_EDE_CBC_SHA SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA SSL_RSA_WITH_DES_CBC_SHA SSL_DHE_RSA_WITH_DES_CBC_SHA SSL_DHE_DSS_WITH_DES_CBC_SHA SSL_RSA_EXPORT_WITH_RC4_40_MD5 SSL_RSA_EXPORT_WITH_DES40_CBC_SHA SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
None of the new cipher suites, nor a number of other cipher suites, show up as choices in the Integration Server Administration console, as illustrated in Figure 14-15.
To force the Integration Server or the HTTP Client to use specific cipher suites, you must add a JVM Option, https.CipherSuites, as discussed in section 14.4.3.1.
Configuration of the Integration Server, required to support Web Services over SSL channel with server-side and mutual authentication, is the same as required to support HTTP eWay–based solutions using server-side or mutual authentication (see sections 14.4.3.1 and 14.4.4.1). Let’s assume that the HTTP Listener on port basePort+4 is configured to support server-side authentication and the HTTP Listener on port basePort+9 is configured to support mutual authentication; now let’s create, configure, and deploy a Web Services Server and Web Services Clients.
In section 14.4.3.1, configuration of the secure channel HTTP Listener, on port basePort+4, was reviewed and modified to support server-side authentication. Server-side authentication for Web Services will use the same HTTP Listener.
Properties of the external system container must reflect our intention here—use SSL (Transport Guarantee CONFIDENTIAL), as shown in Figure 14-16.
The service container configuration, from the port, host, and servlet context perspective, must agree between the client and the server containers. Configuration of the server container is illustrated in Figure 14-17.
Properties of the external system container must reflect our intention—SSL and the servlet context used by the Web Services implementation, as illustrated in Figure 14-18, for the Web Server Client container.
In Figure 14-18, port 20001 is our basePort+4, server-side authentication HTTP Listener, and the servlet context is the context from the WSDL published to the UDDI Registry.
In section 14.4.4.1, configuration of the secure channel HTTP Listener, on port basePort+4, was reviewed and modified to support server-side authentication. Server-side authentication for Web Services will use the same HTTP Listener.
Properties of the external system container must reflect our intention here—use SSL (Transport Guarantee CONFIDENTIAL), as shown in Figures 14-19 and 14-20.
Properties of the client external system container must reflect our intention—SSL and the servlet context used by the Web Services implementation, as shown in Figure 14-21.
In Figure 14-21, port 20009 is our basePort+9, mutual authentication HTTP Listener, and the servlet context is the context from the WSDL published to the UDDI Registry.
Unlike in the case of the HTTP Client eWay, when configuring Web Services for SSL with mutual authentication, the Web Service external system container provides no properties to configure the path, type, and passphrase of the keystore from which to send the client’s certificate. The Web Services external system container uses the keystore configured for the Integration Server to which the project, of which it is a part, is deployed.
Unlike in the case of the HTTP eWay, there is no property to configure to enable or disable Host Name Verification. Web Services Client infrastructure does not verify hostname.
The Web Services implementation in SSL with mutual authentication never gets to know the identity of the client with whom the secure session was established. The Web Services implementation does not even get to know the port number or the scheme used for communication. This means that SSL with mutual authentication cannot be used by the Web Services implementation to further authenticate a Web Services invoker, let alone perform authorization processing of any kind.
Organizations needing to exchange large volumes of data over the Internet seek to protect both their internal systems and the data they are exchanging from malicious individuals. They place firewalls between the Internet and their internal networks to minimize the exposure of internal resources and minimize vulnerability of software exposed to the Internet. If confidentiality is of importance, they seek to secure data transfers by encrypting the channel over which data travels or encrypting the data itself. Interposing a firewall between a client and a server introduces complexities and, depending on the protocol in use for data transfers, prevents data exchange. Requiring data encryption necessitates the use of client and server software with interoperable support for data encryption.
Discussion on setting up the infrastructure necessary to develop and test specific examples of secure variants of the Batch eWay is well beyond the scope of this section. The rest of the section briefly discusses the variants, giving their provenance and major restrictions.
Over the years a number of methods of facilitating firewall traversal and securing data transfers were developed and standardized. Java CAPS Batch eWay includes file transfer variants that support the most common, standardized methods. It supports the plain old FTP protocol, the “firewall-friendly” variant with passive transfers, Socks-based Firewall traversal, and other “secure” variants of file transfer.
The original FTP protocol (RFC 959) suffers from the design flaw that makes it unfriendly to firewalls. It uses two independent channels for transferring “command” messages and “data” messages. The command channel, typically using TCP Port 21, is opened by the client with the server as the destination. The data channel, typically using TCP Port 22, is opened by the server with the client as the destination. This requires that the firewall, if present, allows inbound connections from the Internet to the internal network it is protecting. This is generally a very bad thing from the security perspective. Note that FTP protocol does not include any features that provide confidentiality and integrity for data transfers.
To overcome the security issue of inbound connections for the data channel, a “passive FTP” extension (RFC 1579) was adopted. Rather then attempting to connect to the client for data transfer, the FTP server creates a data channel listener and passes the TCP port the listener uses to the client in the response message. The client uses that port number to establish connection to the server and allow data transfer to commence. Although firewall-friendly, passive FTP still does not provide data integrity and confidentiality protection. In this sense, data transfers are still not secure.
At about the same time, a method was proposed to allow TCP- and User Datagram Protocol (UDP)-based applications to traverse firewalls using modified library implementations and firewall-hosted packet forwarding servers. Socks (RFC 1928) allows an application that does not have direct access to the Internet to reach out through the firewall and connect to an external service. It does so by replacing a standard connectivity library with a “socksified” version. When the application makes a “connect” or a “send” call, the library transparently redirects the call to the “Socks Server” residing at the firewall. The Socks Server makes the connection or performs the send on behalf of the application and thereafter intermediates in the message exchange process for the rest of the session or message exchange. Hopefully, the Socks Server implementation is written in such a way that an attacker cannot exploit vulnerabilities in its code to gain access to internal resources. This security feature still does not provide data integrity and confidentiality protection. Data traverses the firewall but is not encrypted or secured in any other way.
FTP over SSL (RFC 2228, RFC 4217) is implemented in the FTPOverSSL Batch eWay variant. See the RFCs for protocol details. FTP over SSL allows the channels over which data is transferred to be encrypted. Data is secured when in transit. Both Implicit and Explicit modes are supported.
SSH Tunneling support in the Batch eWay allows encryption of the command channel on the premise that user credential must be secured. Since the data channel is not encrypted, the transfer still cannot be considered secure.
Secure file transfer with the Batch SFTP [SecSHFileXfer] and Batch SCP eWay variants uses corresponding features of the Secure Shell (SSH) (RFC 425, 4251, 4252, 4253, 4254) implemented in these eWay variants. Secure FTP (SFTP), a subprotocol of the SSH, is designed to facilitate transfer of files between hosts. Since the SSH channel is encrypted, all data traversing it is encrypted. SFTP is not a derivative of the original FTP but rather is a redefinition of the file transfer protocol leveraging the SSH. Secure Copy Protocol (SCP) is also a subprotocol of SSH. Both SFTP and SCP facilitate transfer of files over an encrypted channel.
Which “secure” file transfer method, if any, to use in specific circumstances will heavily depend on which protocol the remote party supports and what security qualities are required. FTP over SSL requires the use of certificates with considerations similar to these for HTTP over SSL. The use of SSH-based file transfers requires an operating system account on the remote server. SSH Tunneling only secures the command channel but not data exchange. The use of Socks requires a Socks Server. None of the secure file transfer methods protect data before it is transferred or after it is transferred.