White PapersA demilitarized zone is a network area that sits between an organization’s internal network and an external network, usually the Internet. The typical approach is to create a DMZ between two firewalls. The network DMZ must be monitored carefully, because sensitive objects are exposed to higher risk than services behind the firewall.
It is important to carefully control administrative access to services on the DMZ. Most likely, access should be allowed only from the internal network, and preferably over a cryptographically protected connection, such as SSH.
A DMZ is an example of our general philosophy of defense in depth: Multiple layers of security provide a better shield than a simple firewall. If an attacker penetrates the first firewall, he or she gains access to the DMZ, but not necessarily to the internal network.
BEA White PaperBEA AquaLogic"Service Bus behindthe Firewall in Service-OrientedArchitectureUsing BEA AquaLogic Service Bus in Service-OrientedArchitecture with Firewalls, Demilitarized Zone, and Two-Way Inbound and Outbound SSL AuthenticationUntitled DocumentCopyrightCopyright 1995 - 2006 BEA Systems, Inc. All Rights Reserved.Restricted Rights LegendThis software is protected by copyright, and may be protected by patent laws. No copying or other use of this soft-ware is permitted unless you have entered into a license agreement with BEA authorizing such use. This document isprotected by copyright and may not be copied photocopied, reproduced, translated, or reduced to any electronicmedium or machine readable form, in whole or in part, without prior consent, in writing, from BEA Systems, Inc.Information in this document is subject to change without notice and does not represent a commitment on the part ofBEA Systems. THE DOCUMENTATION IS PROVIDED AS IS WITHOUT WARRANTY OF ANY KIND INCLUDINGWITHOUT LIMITATION, ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.FURTHER, BEA SYSTEMS DOES NOT WARRANT, GUARANTEE, OR MAKE ANY REPRESENTATIONS REGARDINGTHE USE, OR THE RESULTS OF THE USE, OF THE DOCUMENT IN TERMS OF CORRECTNESS, ACCURACY,RELIABILITY, OR OTHERWISE.Trademarks and Service MarksCopyright 1995-2006 BEA Systems, Inc. All Rights Reserved. BEA, BEA JRockit, BEA WebLogic Portal, BEAWebLogic Server, BEA WebLogic Workshop, Built on BEA, Jolt, JoltBeans, SteelThread, Top End, Tuxedo, andWebLogic are registered trademarks of BEA Systems, Inc. BEA AquaLogic, BEA AquaLogic Data Services Platform,BEA AquaLogic Enterprise Security, BEA AquaLogic Service Bus, BEA AquaLogic Service Registry, BEA Builder, BEACampaign Manager for WebLogic, BEA eLink, BEA Liquid Data for WebLogic, BEA Manager, BEA MessageQ, BEAWebLogic Commerce Server, BEA WebLogic Communications Platform, BEA WebLogic Enterprise, BEA WebLogicEnterprise Platform, BEA WebLogic Enterprise Security, BEA WebLogic Express, BEA WebLogic Integration, BEAWebLogic Java Adapter for Mainframe, BEA WebLogic JDriver, BEA WebLogic Log Central, BEA WebLogic NetworkGatekeeper, BEA WebLogic Personalization Server, BEA WebLogic Personal Messaging API, BEA WebLogicPlatform, BEA WebLogic Portlets for Groupware Integration, BEA WebLogic Server Process Edition, BEA WebLogicSIP Server, BEA WebLogic WorkGroup Edition, Dev2Dev, Liquid Computing, and Think Liquid are trademarks of BEASystems, Inc. BEA Mission Critical Support, BEA Mission Critical Support Continuum, and BEA SOA Self Assessmentare service marks of BEA Systems, Inc. All other names and marks are property of their respective owners.CWP1441Ex0906-1A Untitled DocumentBEA White Paper BEA AquaLogic Service Bus behind the Firewall in Service-Oriented ArchitectureContents1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11.1. AquaLogic Service Bus Domain behind the firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12. Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22.1. Definitions of terms, acronyms, and abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22.2. BEA WebLogic Server support of one-way and two-way SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32.3. References and related documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63. Problem definition: How to establish two-way inbound and two-way outbound SSL authentication betweenclient, BEA AquaLogic Service Bus, and business service separated by firewalls . . . . . . . . . . . . . . . . . . . . .74. Deployment architecture, set-up, and configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74.1. Deployment architecture example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84.2. Inbound and outbound two-way SSL authentication configuration . . . . . . . . . . . . . . . . . . . . . . . . . . .104.2.1. Two-way SSL authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104.2.2. BEA WebLogic Server configuration of one-way and two-way SSL . . . . . . . . . . . . . . . . . . . . . . .104.2.3. About PKI credential mappers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114.2.4. Configuration steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135.1. Business service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135.2. Proxy service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175.3. Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .176. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .247. About BEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .248. Join the BEA community . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24Untitled Document1BEA White Paper BEA AquaLogic Service Bus behind the Firewall in Service-Oriented Architecture1. Abstract1.1. BEA AquaLogic Service Bus domain behind the firewallAs organizations move to Service-Oriented Architecture (SOA), security becomes one of the key concernsimpacting deployment. A company s sensitive information is accessed by services deployed on the distributedcomponents in a SOA. Therefore, security concerns have become part of the enterprise decision-makingprocess relating to the adoption of an SOA.Typically, a company sends request messages from BEA AquaLogic Service Bus behind its internal firewall tobusiness services hosted outside its firewall. In such a scenario, BEA AquaLogic Service Bus acts as a for-ward proxy. The company receives response messages from business services through the demilitarizedzone (DMZ) into BEA AquaLogic Service Bus, which is deployed behind the company firewall. In this case, BEAAquaLogic Service Bus would act as a reverse proxy.This paper discusses the security set-up and configuration for clients, BEA AquaLogic Service Bus (version 2.1,2.5, and 2.6) proxy services, and business services. The set-up assumes that a client Web application sendsan HTTPS request message from outside a company s firewall to the BEA AquaLogic Service Bus server locat-ed behind its firewall (the inbound request ). BEA AquaLogic Service Bus then routes the HTTPS request mes-sage to a business service hosted outside its firewall (the outbound request ). The business service sends theresponse message through BEA AquaLogic Service Bus to the client. This set-up involves an inbound one- ortwo-way and an outbound one- or two-way SSL authentication. It capitalizes on BEA WebLogic Server andBEA AquaLogic Service Bus security.The paper provides an example of how to configure the inbound two-way and outbound two-way SSL authen-tication from the command line, the BEA WebLogic Server Administration Console, and the BEA AquaLogicService Bus Console. The example includes a description of the deployment architecture and how to test thesystem with request/response messaging.Untitled DocumentBEA White Paper BEA AquaLogic Service Bus behind the Firewall in Service-Oriented Architecture222. Background2.1. Definitions of terms, acronyms, and abbreviationsFirewallA firewall limits traffic between two networks. Firewalls can be a combination of software and hardware, includingrouters and dedicated gateway machines. They employ filters that allow or disallow traffic to pass based on thetransport protocol, the service requested, routing information, and the origin and destination hosts or networks.They may also allow access for authenticated users.Figure 2.1 illustrates a typical set-up with a firewall that filters the traffic destined for a BEA WebLogic Server cluster.Demilitarized zone (DMZ)A demilitarized zone is a network area that sits between an organization s internal network and an external net-work, usually the Internet. The typical approach is to create a DMZ between two firewalls. The network DMZ mustbe monitored carefully, because sensitive objects are exposed to higher risk than services behind the firewall.It is important to carefully control administrative access to services on the DMZ. Most likely, access should beallowed only from the internal network, and preferably over a cryptographically protected connection, such as SSH.A DMZ is an example of our general philosophy of defense in depth: Multiple layers of security provide a bettershield than a simple firewall. If an attacker penetrates the first firewall, he or she gains access to the DMZ, butnot necessarily to the internal network. (See a description of DMZs in Firewalls and Internet Security: Repellingthe Wily Hacker, by William R. Cheswick, Steven M. Bellovin, and Aviel D. Rubin, listed in Chapter 2.3:References and related documents.)E x t e r n a l C l i e n tB E A W e b L o g i c S e r v e r C l u s t e rI n t e r n a l C l i e n tN e t w o r k AN e t w o r k AF i r e w a l lFigure 2.1Typical firewall set-up.Untitled Document3BEA White Paper BEA AquaLogic Service Bus behind the Firewall in Service-Oriented ArchitectureSecure Sockets Layer (SSL)SSL enables secure communication between applications connected through the Web. For a discussion of thecomponents of SSL communication and why each component is necessary, see OpenSSL Documents andSSL and TLS: Designing and Building Secure Systems by Eric Rescorla, Addison-Wesley, 2001 in Chapter 2.3:References and related documents.BEA WebLogic Server uses the Certicom SSLPlus Java version 4.0 SSL implementation. The RSA Cert-J andCrypto-J have been upgraded to Cert-J version 2.1.1 and Crypto-J version 3.5.Network interface card (NIC)A network interface card (also called a network adapter or network card) is a piece of computer hardwaredesigned to allow computers to communicate over a computer network.(Wikipedia, http://en.wikipedia.org/wiki/Network_card)2.2. BEA WebLogic Server support of one-way and two-way SSLSSL featuresBEA WebLogic Server provides a pure-Java implementation of SSL. Generally, SSL provides the following:" A mechanism that the communicating applications can use to authenticate each other s identity" Encryption of the data exchanged by the applications.When SSL is used, the target (the server) always authenticates itself to the initiator (the client). Optionally, if thetarget requests it, the initiator can authenticate itself to the target. Encryption makes data transmitted over thenetwork intelligible only to the intended recipient. An SSL connection begins with a handshake during whichthe applications exchange digital certificates, agree on the encryption algorithms to be used, and generate theencryption keys to be used for the remainder of the session.SSL provides the following security features:" Server authentication-BEA WebLogic Server uses its digital certificate, issued by a trusted certificateauthority, to authenticate to clients. SSL minimally requires the server to authenticate to the client using itsdigital certificate. If the client is not required to present a digital certificate, the connection type is called one-way SSL authentication." Client identity verification-Optionally, clients can be required to present their digital certificates to BEAWebLogic Server, which then verifies that the digital certificate was issued by a trusted certificate authorityand establishes the SSL connection. An SSL connection is not established if the digital certificate is notpresented and verified. This type of connection is called two-way SSL authentication, a form of mutualauthentication." Confidentiality-All client requests and server responses are encrypted to maintain the confidentiality of dataexchanged over the network." Data integrity-Each SSL message contains a message digest computed from the original data. On thereceiving end, a new digest is computed from the decrypted data and then compared with the digest thatcame with the message. If the data has been altered, the digests don t match and tampering is detected.Untitled DocumentBEA White Paper BEA AquaLogic Service Bus behind the Firewall in Service-Oriented Architecture4" Data that flows between a client and BEA WebLogic Server is protected from tampering by a third-partyvalidation of user identities." If you are using a Web browser to communicate with BEA WebLogic Server, you can use the Hyper-TextTransfer Protocol with SSL (HTTPS) to secure network communications.SSL tunnelingBEA WebLogic Server supports tunneling with HTTP, T3, and IIOP protocols over SSL. SSL can be used byWeb browsers and Java clients as follows:" A Web browser makes an SSL connection to a server over HTTPS. The browser then sends HTTP requestsand receives HTTP responses over this SSL connection. For example: https://myserver.com/mypage.html" BEA WebLogic Server supports SSL versioning. This means it can communicate with any client, includingWeb browsers that use SSL v2, SSL v3, and TLS v1." Java clients using HTTP/T3 protocols can tunnel over SSL. For example: t3s://myserver.com:7002/mypage.html" Java clients running in BEA WebLogic Server can establish either T3S connections to other instances of BEAWebLogic Server, or HTTPS connections to other servers that support SSL, such as Web servers or secureproxy servers.BEA WebLogic Server support for one-way and two-way SSL authenticationBEA WebLogic Server supports both one-way and two-way SSL authentication. With one-way SSLauthentication, the target (the server) is required to present a digital certificate to the initiator (the client) to proveits identity. The client performs two checks to validate the digital certificate:" The client verifies that the certificate is trusted (meaning it was issued by the client s trusted CertificateAuthority), is valid (not expired), and satisfies other certificate constraints." The client checks that the certificate subject s common name (CN) field value matches the host name of theserver to which the client is trying to connect. This is called host-name verification." Advanced options include inbound or/and outbound certificate lookup and validation (CLV). This featureprovides additional protection by validating the certificate against the list of certificate authorities compiled bythe server administrator. The BEA WebLogic security service provides the CLV API that finds and validatesX509 certificate chains.A CertPath is a JDK class that stores a certificate chain in memory. The term CertPath is also used to refer tothe JDK architecture and framework that is used to locate and validate certificate chains. The CLV frameworkextends and completes the JDK CertPath functionality. CertPath providers rely on a tightly coupled integrationof BEA WebLogic and JDK interfaces. Your application code can use the default CertPath providers providedby BEA WebLogic Server to build and validate certificate chains, or use any custom CertPath provider.If all of the above checks return true, the SSL connection is established.With two-way SSL authentication, both the client and the server must present digital certificates before the SSLconnection is enabled between the two. Thus, in this case, BEA WebLogic Server not only authenticates itselfto the client (which is the minimum requirement for certificate authentication), but also requires authenticationfrom the requesting client.Untitled Document5BEA White Paper BEA AquaLogic Service Bus behind the Firewall in Service-Oriented ArchitectureTwo-way SSL authentication is useful when you must restrict access to trusted clients only. BEA WebLogicServer SSL connections support one-way SSL, two-way SSL, or both. The Web browser client, Web server, fatclient, Web services client, and SSL server connections can be configured for either one-way or two-way SSL.BEA WebLogic Server determines whether an SSL connection is configured for one-way or two-way authenti-cation, and SSL is configured using the Administration Console.Host-name verificationHost-name verification is the process of verifying that the name of the host to which an SSL connection ismade is the intended or authorized party. Host-name verification prevents man-in-the-middle attacks in which aclient requests an SSL connection to a remote application server.By default, the SSL client, as a function of the SSL handshake, compares the common name in the SubjectDNof the SSL server s digital certificate with the host name of the SSL server to which it is trying to connect. Ifthese names do not match, the SSL connection is dropped.Trust managersThe trust manager provides a way to override the default SSL trust validation rules. It allows the server todecide whether or not it trusts the client that is contacting it. Using a trust manager, you can perform customchecks before continuing an SSL connection. For example, you can use the trust manager to specify that onlyusers from specific localities, such as towns, states, or countries, or users with other special attributes, cangain access via the SSL connection.BEA WebLogic Server provides the weblogic.security.SSL.TrustManager interface. This interface allows customtrust-manager implementations to be called during the SSL handshake. The custom implementation can over-ride the handshake error detected by the SSL implementation validation check or indicate an error based on itsown certification rules.BEA WebLogic Server also provides the weblogic.security.SSL.CertPath.TrustManager interface, which applica-tions and custom code can use to control outbound SSL uses certificate lookup and validation.Note: The weblogic.security.SSL.CertPath.TrustManager interface replaces theweblogic.security.SSL.TrustManagerJSSE interface, which is superseded in the BEA WebLogic Server 9.1 release.Asymmetric key algorithmsAsymmetric key (also referred to as public key) algorithms are implemented through a pair of different but math-ematically related keys: a public key and a private key.The public key (which is distributed widely) is used for verifying a digital signature or transforming data into aseemingly unintelligible form. The private key (which is always kept secret) is used for creating a digital signa-ture or returning the data to its original form.The Public Key Infrastructure (PKI) in BEA WebLogic Server also supports digital signature algorithms. Digitalsignature algorithms are simply public-key algorithms used to generate digital signatures. BEA WebLogicServer supports the Rivest, Shamir, and Adelman (RSA) algorithm.Untitled DocumentBEA White Paper BEA AquaLogic Service Bus behind the Firewall in Service-Oriented Architecture62.3. References and related documents2.3.1. Security for BEA WebLogic Server 9.1http://e-docs.bea.com/wls/docs91/security.html2.3.2. Understanding BEA WebLogic Security: Security Fundamentalshttp://e-docs.bea.com/wls/docs92/secintro/concepts.html2.3.3. BEA AquaLogic Service Bus 2.1 and 2.5 Documentation: SecurityConfigurationhttp://e-docs.bea.com/alsb/docs21/consolehelp/securityconfiguration.htmlhttp://e-docs.bea.com/alsb/docs25/consolehelp/securityconfiguration.html2.3.4. BEA AquaLogic Service Bus 2.1 User Guide: Securing Inbound andOutbound Messageshttp://e-docs.bea.com/alsb/docs21/userguide/security.htmlBEA AquaLogic Service Bus 2.5 Security Guidehttp://e-docs.bea.com/alsb/docs25/security/2.3.5. BEA Dev2Dev Code-Sample ID S183: Outbound Transport Security Samplehttps://codesamples.projects.dev2dev.bea.com/servlets/Scarab/remcurreport/true/template/ViewIssue.vm/id/S183/nbrresults/1842.3.6. Programming BEA WebLogic Security: Using SSL Authentication in Java Clientshttp://e-docs.bea.com/wls/docs91/security/SSL_client.htmlhttp://e-docs.bea.com/wls/docs92/security/SSL_client.htmlFor information on how to configure BEA WebLogic Server for two-way SSL authentication, see theConfiguring SSL section in Securing WebLogic Server. Follow the links to the sections that describe the different ways two-way SSL authentication can be implemented in BEAWebLogic Server." Two-Way SSL Authentication with JNDI" Using Two-Way SSL Authentication Between BEA WebLogic Server Instances" Using Two-Way SSL Authentication with Servlets2.3.7. OpenSSL Documentshttp://www.openssl.org/docs/2.3.8. Grinder Frameworkhttp://sourceforge.net/projects/grinder/2.3.9. Firewall Overviewhttp://www.seifried.org/security/network/firewall/20011025-firewall-overview.htmlUntitled DocumentBEA White Paper BEA AquaLogic Service Bus behind the Firewall in Service-Oriented Architecture72.3.10. SSL and TLS: Designing and Building Secure Systems, by Eric Rescorla,Addison-Wesley, 2001http://www.rtfm.com/sslbook/2.3.11. Setting up a test networkhttp://www.networkworld.com/columnists/2004/0712nutter.html2.3.12. Firewalls and Internet Security: Repelling the Wily Hacker, Second Edition;William R. Cheswick, Steven M. Bellovin, and Aviel D. Rubinhttp://www.wilyhacker.com/3. Problem definition: How to establish two-wayinbound and two-way outbound SSL authenticationbetween client, BEA AquaLogic Service Bus, andbusiness service separated by firewallsThe goal is to establish inbound two-way and outbound two-way SSL authentication, each through the firewall,for the scenario in which:" A client sends an HTTPS request to a BEA AquaLogic Service Bus proxy service." A BEA AquaLogic Service Bus proxy service routes the request to a BEA WebLogic Server 9.x-hostedbusiness service over HTTPS." A business service receives a request and sends an HTTPS response to the client via the BEA AquaLogicService Bus proxy service.4. Deployment architecture, set-up, and configurationIn general, the details of the installation and configuration depend on the operating system, the number ofmachines, and the desired cluster sizes of BEA WebLogic Server domains. Typically in a production environ-ment, the client, the BEA AquaLogic Service Bus proxy service, and the business service are hosted on sepa-rate machines. In addition, each BEA WebLogic Server cluster node is hosted on a separate hardware system.The following section describes a simplified example of how to set up and configure request/response messag-ing between a client, a BEA AquaLogic Service Bus proxy service, and a business service for testing. Theexample uses minimum hardware consisting of two systems, each running a Microsoft Windows operating sys-tem. The first machine hosts the client and business service. The second machine hosts the BEA AquaLogicService Bus proxy service.The first and second machines are separated by two firewalls, with a lab network between firewalls. The labnetwork simulates a public network like the Internet. This is a simplification of a typical set-up in which eachUntitled DocumentBEA White Paper BEA AquaLogic Service Bus behind the Firewall in Service-Oriented Architecture8company hosting the client, the BEA AquaLogic Service Bus proxy service, or the business service has twofirewalls with a DMZ in between. The example outlines common configuration steps, which can be extrapolatedto suit production requirements.4.1. Deployment architecture exampleFigure 4.1.1Client, BEA AquaLogicService Bus proxy service,and business service deploy-ment configuration. The DMZis not shown.S e r v e r 2A q u a L o g i c S e r v i c e B u s S e r v e r D o m a i nP r o x y S e r v i c e E n d p o i n tN I C 1 ( i n t e r n a l ) h t t p s : / / : 7 0 0 2N I C 2 ( e x t e r n a l ) h t t p s : / / : 7 0 0 2S e r v e r 3B E A W e b L o g i c S e r v e r B u s i n e s s S e r v i c e D o m a i nB u s i n e s s A p p l i c a t i o nN I C 1 ( i n t e r n a l ) h t t p s : / / : 7 0 0 2N I C 2 ( e x t e r n a l ) h t t p s : / / : 7 0 0 2S e r v e r 1C l i e n t D o m a i nC l i e n t A p p l i c a t i o nN I C 1 ( i n t e r n a l ) h t t p s : / / : 7 0 0 2N I C 2 ( e x t e r n a l ) h t t p s : / / : 7 0 0 2L a b N e t w o r k F i r e w a l lF i r e w a l lL a b N e t w o r k F i r e w a l lF i r e w a l lUntitled DocumentBEA White Paper BEA AquaLogic Service Bus behind the Firewall in Service-Oriented Architecture9Figure 4.1.2 shows the network set-up for a firewall/DMZ BEA AquaLogic Service Bus test. The following char-acteristics describe the set-up:" The firewall between FW-B and WLI Lab Network is a hardware firewall: Cisco PIX 506." The firewall between FW-E and WLI Lab Network is a software firewall: Checkpoint Firewall/1 ." Solid lines represent the paths followed by the messages that are sent from FW-B." Dotted lines represent the paths followed by the messages sent from FW-E." Ports 7001 and 7002 are opened on the external IPs for the internal boxes." The client and BEA WebLogic Server business service domain are hosted on FW-B." The BEA AquaLogic Service Bus domain is hosted on FW-B.Figure 4.1.2BEA AquaLogic Service BusDMZ/firewall test hardwarenetwork set-up.L a b N e t w o r kx x x . x x . x . x( S i m u l a t i n g I n t e r n e t )5 P o r t S w i t c h f o r x x . x . x . x / x x N I C 2 ( e x t e r n a l ) I P : x x x . x x . x . x x xN I C 1 ( i n t e r n a l ) I P : x x . x . x . xP o r t s 7 0 0 1 , 7 0 0 2 , 5 9 0 0 o p e nN I C 2 ( e x t e r n a l ) I P : x x x . x x . x . x x xN I C 1 ( i n t e r n a l ) I P : x x . x . x . xP o r t s 7 0 0 1 , 7 0 0 2 , 5 9 0 0 o p e nH T T P S C l i e n tB u s i n e s s S e r v i c eB E A A q u a L o g i c S e r v i c e B u s P r o x y S e r v i c eF i r e w a l l : C h e c k P o i n t F W / 1N I C 2 ( e x t e r n a l ) I P : x x x . x x . x . x x xN I C 1 ( i n t e r n a l ) I P : x x . x . x . xC i s c o P I X 5 0 6N I C 2 ( e x t e r n a l ) I P : x x x . x x . x . x x xN I C 1 ( i n t e r n a l ) I P : x x . x . x . x5 P o r t S w i t c h f o r x x . x . x . x / x x Untitled DocumentBEA White Paper BEA AquaLogic Service Bus behind the Firewall in Service-Oriented Architecture10A typical set-up includes two firewalls (Figure 4.1.3), one in front of the public servers, and one between thepublic servers and the internal LAN. This set-up is typically referred to as the DMZ, because the zonebetween the two firewalls is un-trusted and heavily restricted. Additionally you can set up application proxies(such as www and FTP proxies), then block outbound access from the internal LAN on the exterior firewall andforce all clients to go through your application proxies (which can have anti-virus capabilities, for example). TheDMZ should be a quiet zone; that is, any hostile packets trying to enter it (from the Internet, or the internalLAN) should be blocked at either firewall, increasing the effectiveness of any intrusion-detection systems. (Thisresults in fewer false positives.)(Firewall overview by Kurt Seifried, http://www.macrollc.com/FAQs/FAQ-firewall_overview_seifried.htm.)4.2. Inbound and outbound two-way SSL authentication configuration4.2.1. Two-way SSL authenticationIn this scenario, two-way SSL certificate authentication is used between the client, the proxy service, and thebusiness service. Each of them can be deployed on its own BEA WebLogic Server. If this is the case, eachBEA WebLogic Server sends a digital certificate to the requesting client. The client examines the digital certifi-cate to ensure that it is authentic, has not expired, and matches the BEA WebLogic Server instance that pre-sented it.The requesting client also presents a digital certificate to BEA WebLogic Server. Requesting clients must pres-ent digital certificates from a specified set of certificate authorities. BEA WebLogic Server accepts only digitalcertificates that have root certificates from the specified trusted certificate authorities.4.2.2. BEA WebLogic Server configuration of one-way and two-way SSLBy default, BEA WebLogic Server is configured for one-way SSL authentication; however, the SSL port is dis-abled. You can enable an SSL port using the BEA WebLogic Server Administration Console.To use two-way SSL between a client and a server:" Enable the SSL port on the server." Configure identity for the server and trust for the client.Figure 4.1.3LAN set-up.In t e r n e tI n t e r n a l L A NF ir e w a llP u b licS e r v e rF ir e w a llUntitled DocumentBEA White Paper BEA AquaLogic Service Bus behind the Firewall in Service-Oriented Architecture11" Enable two-way SSL on the server." Configure trust for the server and identity for the server.The peer certificate chain needs to contain a certificate from the Certificate Authority (CA) that issued the peer sidentity certificate. This CA certificate does not need to be the root CA certificate.To acquire a digital certificate for your server, you generate a public key, a private key, and a CertificateSignature Request (CSR), which contains your public key. You send the CSR to a Certificate Authority and fol-low their procedures for obtaining a signed digital certificate.When you have your private keys, digital certificates, and the additional trusted CA certificates that you need,you must store them so that BEA WebLogic Server can use them to verify identity. Store private keys and cer-tificates in keystores.Note: For purposes of backwards compatibility, you may also store your private keys and certificates in files.For more information about private key, public key, and certificate requirements and procedures, see theConfiguring SSL and BEA Securing WebLogic Server section in Security for BEA WebLogic Server 9.1, Chapter 2.3: References and related documents.To use SSL when connecting to a BEA WebLogic Server application with your browser, you simply specifyHTTPS and the secure port (say, port number 7002) in the URL. For example:https://:7002/examplesWebApp/SnoopServlet.jsp where is the name of the system hosting the Web application.4.2.3. About PKI credential mappersA PKI credential mapper maps key pairs (a public key and a private key) to an alias. The BEA WebLogic ServerPKICredentialMapper stores the key alias and key password (for key pairs) in the embedded LDAP. Key pass-words are encrypted before they are stored on LDAP. The PKICredentialMapper does not store the keys; theyare stored in a keystore. The PKICredentialMapper is configured with the location of the keystore and the key-store password.Note: The target BEA WebLogic Server not only requires a trusted and valid certificate, but allows the SSLconnection only if it can authenticate a user ID stored somewhere in the x500 Distinguished Name in the client certificate.For additional information see:" Securing BEA WebLogic Server by Configuring SSL:http://e-docs.bea.com/wls/docs91/secmanage/ssl.html#configureSSL" Administration Console Online Help: Configure Two-Way SSLhttp://e-docs.bea.com/wls/docs91/ConsoleHelp/taskhelp/security/ConfigureTwowaySSL.html" Configure Keystoreshttp://e-docs.bea.com/wls/docs91/ConsoleHelp/taskhelp/security/ConfigureKeystoresAndSSL.html" Configuring Identity and Trusthttp://e-docs.bea.com/wls/docs91/secmanage/identity_trust.htmlUntitled DocumentBEA White Paper BEA AquaLogic Service Bus behind the Firewall in Service-Oriented Architecture124.2.4. Configuration stepsComplete the following steps to configure your system:1. Install BEA WebLogic Server on each of the participating machines. Optionally, configure server domains inproduction mode connected to an Oracle database.2. Configure keystores for all participating domains using the BEA WebLogic Server Administration Console.3. Populate the keystores with server keys and certificates using command line tools.4. Import each server s certificate as a trusted certificate into the other server s keystore using command line tools.5. Configure the BEA WebLogic Server that hosts the BEA AquaLogic Service Bus proxy service to supporttwo-way SSL using the BEA WebLogic Server Administration Console.6. Configure the BEA WebLogic Server that hosts business services to support two-way SSL using the BEAWebLogic Server Administration Console.7. Add the user ID from the BEA AquaLogic Service Bus server certificate to the business service server LDAPfor business service using the BEA WebLogic Server Administration Console.8. Add the user ID from the client (or client server) certificate to the BEA AquaLogic Service Bus server LDAPsystem for BEA AquaLogic Service Bus using the BEA WebLogic Server Administration Console.9. Configure a PKI credential mapper for BEA AquaLogic Service Bus using the BEA WebLogic ServerAdministration Console.10. Configure a proxy service provider using the BEA AquaLogic Service Bus Console.11. Associate PKI credentials (SSL client key-pair) with the proxy service provider using the Credentials sectionof the Security Configuration module using the BEA AquaLogic Service Bus Console.12. Register a business service definition, which uses the HTTPS transport protocol with client certificateauthentication in BEA AquaLogic Service Bus using the BEA AquaLogic Service Bus Console.13. Configure a proxy service to route a message to the business service using the BEA AquaLogic ServiceBus Console.Untitled DocumentBEA White Paper BEA AquaLogic Service Bus behind the Firewall in Service-Oriented Architecture135. Testing5.1. Business serviceA business service can be implemented as a servlet like EchoServlet.java shown in the following listing. To compile the code, the weblogic.jar and xbean.jar from the server library must be on your classpath.EchoServlet.java source:import com.bea.xbean.common.IOUtil;import javax.servlet.http.HttpServletRequest;import javax.servlet.http.HttpServlet;import javax.servlet.http.HttpServletResponse;import javax.servlet.ServletException;import javax.servlet.ServletOutputStream;import javax.servlet.ServletInputStream;import java.io.IOException;import java.io.ByteArrayOutputStream;import java.util.Enumeration;/*** Created by IntelliJ IDEA.* Author: Gregory Haardt* Date: Jun 1, 2004* Time: 4:08:06 PM* To change this template use Options | File Templates.*/public class EchoServlet extends HttpServlet{public static final long serialVersionUID = 1L;public void service(HttpServletRequest httpServletRequest, HttpServletResponsehttpServletResponse)throws IOException, ServletException{System.out.println( Entered the echo servlet );System.out.println( EchoServlet: Content-Type = +httpServletRequest.getContentType());/** optionally wait for the specified time interval */Untitled DocumentBEA White Paper BEA AquaLogic Service Bus behind the Firewall in Service-Oriented Architecture14String waitTime = httpServletRequest.getParameter( wait );if (waitTime != null && waitTime.length() > 0){try{Thread.sleep(Integer.parseInt(waitTime) * 1000);}catch (Exception e){e.printStackTrace();}}String toThrow = httpServletRequest.getParameter( throw );if (toThrow != null && toThrow.length() > 0){throw new ServletException( Throwing exception for testing purposes );}// Copy all request headers to response (although some may not be relevant!)Enumeration headers = httpServletRequest.getHeaderNames();while (headers.hasMoreElements()){String o = (String) headers.nextElement();httpServletResponse.addHeader(o, httpServletRequest.getHeader(o));}ServletInputStream inputStream = httpServletRequest.getInputStream();ServletOutputStream outputStream = httpServletResponse.getOutputStream();boolean useStreaming = true;if (useStreaming) {System.out.print( EchoServlet: message = );byte[] buf = new byte[1024];int totalCount = 0;while (true){int byteCount = inputStream.read(buf, 0, buf.length);if (byteCount == -1) break;System.out.print(new String(buf, 0, byteCount));Untitled DocumentBEA White Paper BEA AquaLogic Service Bus behind the Firewall in Service-Oriented Architecture15outputStream.write(buf, 0, byteCount);totalCount += byteCount;}httpServletResponse.setContentLength(totalCount);System.out.println();} else {// Read entire InputStream into byte arrayByteArrayOutputStream out = new ByteArrayOutputStream(1024);IOUtil.copyCompletely(inputStream, out);// Dump message to be echoed to consoleSystem.out.println( EchoServlet: message = + out);// Set content-length and dump responsehttpServletResponse.setContentLength(out.size());out.writeTo(outputStream);}String toThrow2 = httpServletRequest.getParameter( throw2 );if (toThrow2 != null && toThrow2.length() > 0){throw new ServletException( Throwing exception for testing purposes );}httpServletResponse.setStatus(HttpServletResponse.SC_OK);}}Code developed by senior software engineer Gregory HaardtTo deploy EchoServlet on BEA WebLogic Server, you must have a Web deployment descriptor web.xml and aBEA WebLogic deployment descriptor weblogic.xml.Web.xml source code: http://java.sun.com/dtd/web-app_2_3.dtd > EchoServlet Untitled DocumentBEA White Paper BEA AquaLogic Service Bus behind the Firewall in Service-Oriented Architecture16 EchoServlet EchoServlet EchoServlet/echoAllEndPoints/*These are the roles who have access to inbound HTTPs endpointsAdminSSL requiredCONFIDENTIALCLIENT-CERTAn administratorAdminUntitled DocumentBEA White Paper BEA AquaLogic Service Bus behind the Firewall in Service-Oriented Architecture17weblogic.xml source code : http://www.bea.com/servers/wls810/dtd/weblogic810-web-jar.dtd >AdminCreate a WAR file ExternalServiceClientCert.war using the JAR tool, using the following command:jar c[v0M]f jarfile [-C dir] inputfiles [-Joption]For example:jar cvf ExternalServiceClientCert.war *After starting BEA WebLogic Server, choose the Deployments option from the main menu and deploy theExternalServiceClientCert.war.5.2. Proxy serviceConfigure the proxy and business services using BEA AquaLogic Service Bus Console. The proxy service defi-nition relies on configuration of a proxy service provider. You must associate PKI credentials (SSL client key-pair) with the proxy service provider using the Credentials section of the Security Configuration module.After you registered a business service definition, which uses the HTTPS transport protocol with client certifi-cate authentication, configure a proxy service to route a message to the business service.5.3. ClientFor testing this scenario, the Grinder open-source development test framework was used. It is available fordownload at the following URL: http://sourceforge.net/projects/grinder/1. Download the grinder-3.0-beta27.zip or later release.2. To run the Grinder client you need three files: grinder.properties, https-ClientCert.py, and an input XML file.Untitled DocumentBEA White Paper BEA AquaLogic Service Bus behind the Firewall in Service-Oriented Architecture18The following listing is an example of a grinder.properties file:# Example grinder.properties# grinder.jvm.arguments=-Dpython.home=d:/jython/jython-2.1grinder.processes=1grinder.threads=1grinder.runs=1grinder.useConsole=falsegrinder.logDirectory=loggrinder.numberOfOldLogs=1#grinder.initialSleepTime=500#grinder.sleepTimeFactor=0.01#grinder.sleepTimeVariation=0.005grinder.script=https-ClientCert.pyThe following listing is an example of an https-ClientCert.py file:# A simple example using the HTTP plug-in that shows the retrieval of a# single page via HTTP. The resulting page is written to a file.# More complex HTTP scripts are best created with the TCPProxy.from net.grinder.script.Grinder import grinderfrom net.grinder.script import Testfrom net.grinder.plugin.http import HTTPRequestfrom HTTPClient import HTTPResponsefrom HTTPClient import HTTPConnectionfrom HTTPClient import NVPairfrom net.grinder.plugin.http import HTTPPluginControlimport jarraytest1 = Test(1, Request resource )request1 = test1.wrap(HTTPRequest())class TestRunner:def __call__(self):Untitled DocumentBEA White Paper BEA AquaLogic Service Bus behind the Firewall in Service-Oriented Architecture19#Set the client cert to be sendgrinder.SSLControl.setKeyStoreFile( TestClientKeystore.jks , password )file = open( ./INPUTS/sslInputString.xml , r )contents = file.read()print ---------request--------------- print contentsprint ------------------------ file.close()request1.addHeader( Content-type , text/xml )result = request1.POST( https://172.16.1.225:7002/ClientCertPS ,contents)print ---------response--------------- print result.getText()print ------------------------ The third file is an input XML file. It must be located in the INPUTS directory. The following listing is an exampleof an input XML file in the INPUTS directory (/INPUTS/sslInputString.xml):xmlns:xsi= http://www.w3.org/2001/XMLSchema-instance > J DoeJ Q Public Untitled DocumentBEA White Paper BEA AquaLogic Service Bus behind the Firewall in Service-Oriented Architecture20Set up the classpath in a process environment by executing a script like setEnvBEA.cmd in the cmd shell:@echo offset BEA_HOME=D:\wlw\src_15004jr\beaset DOMAIN_HOME=D:\wlw\src_15004jr\domains\alsb_client_domainset WEBLOGIC_HOME=%BEA_HOME%\weblogic90set BEA_JDK=D:\wlw\dev\src\build\jrockit-jdk1.5.0_04set OLDPATH=%PATH%set PATH=%WEBLOGIC_HOME%\server\binset PATH=%PATH%;%BEA_JDK%\binset PATH=%PATH%;%OLDPATH%set CLASSPATH=.;%WEBLOGIC_HOME%\server\lib\weblogic.jarset WL_HOME=set ANT_HOME=set JAVA_HOME=set ANT_ARGS=3. Start the Grinder client from the directory hosting your scripts:C:\bea\user_projects\domains\alsb_services_domain\ClientCert>java net.grinder.GrinderThe output is displayed in the shell window. It is similar to the following listing:12/16/05 2:51:22 PM (agent): The Grinder 3.0-beta2712/16/05 2:51:22 PM (agent): Worker process command line: java -classpath E:\Grinder3\grinder-3.0-beta27\lib\grinder.jar;.;E:\Grinder3\grinder-3.0-beta27\lib\jython.jar;C:\bea\jrockit90_150_04\lib\tools.jar;C:\bea\jrockit90_150_04\jre\lib\rt.jar; net.grinder.engine.process.GrinderProcess12/16/05 2:51:23 PM (agent): process fw-b-0 startedUntitled DocumentBEA White Paper BEA AquaLogic Service Bus behind the Firewall in Service-Oriented Architecture2112/16/05 2:51:26 PM (process fw-b-0): starting threads---------request---------------xmlns:xsi= http://www.w3.org/2001/XMLSchema-instance >J DoeJ Q Public---------------------------------response---------------xmlns:soap= http://schemas.xmlsoap.org/soap/envelope/ >J DoeJ Q Public------------------------12/16/05 2:51:27 PM (process fw-b-0): finished12/16/05 2:51:28 PM (agent): finishedUntitled DocumentBEA White Paper BEA AquaLogic Service Bus behind the Firewall in Service-Oriented Architecture224. Include the following setting in the setDomainEnv.cmd (or setDomainEnv.sh) to receive the full SSL debug stack:set EXTRA_JAVA_PROPERTIES=%EXTRA_JAVA_PROPERTIES%-Dssl.debug=true-Dweblogic.StdoutDebugEnabled=true-Dweblogic.security.SSL.verbose=trueThe inbound request is sent through the firewall using the reverse proxy service from the DMZ to the LAN/WANbehind the firewall. Specifically, the Grinder HTTPS client sends the request from the outside the firewall to theBEA AquaLogic Service Bus proxy service behind the firewall. The BEA AquaLogic Service Bus proxy serviceroutes the request to the business service located outside the firewall.The conversation between BEA AquaLogic Service Bus and a server hosting the business services shouldcomplete successfully. Recall that we use inbound and outbound two-way SSL transport security.To validate the SSL handshake, examine the console windows of both the BEA AquaLogic Service Bus serverand the BEA WebLogic Server that hosts the business services. Look for entriesto see how the SSL handshake was executed.Note that the BEA AquaLogic Service Bus server console window shows the business-services server certifi-cate when it is received, and the business services console shows the client s certificate.In both console windows you will see alerts and exceptions that indicate the SSL connection was closed.These can be ignored if they are of Type: 0.The certificate record in the business services console log is similar to the following listing: 116908534863041204781210221131467927454Issuer:C=US, L=San Jose, O=BEA Systems, Inc., OU=DEV, CN=QuickSilver-TEST-CASubject:C=US, L=San Jose, O=BEA Systems, Inc., OU=DEV, CN=QS-SERVER-TESTNot Valid Before:Sun Jul 18 00:00:00 PDT 2004Not Valid After:Thu Oct 18 00:00:00 PDT 2007Signature Algorithm:SHA1withRSA> Untitled DocumentBEA White Paper BEA AquaLogic Service Bus behind the Firewall in Service-Oriented Architecture23Issuer:C=US, L=San Jose, O=BEA Systems, Inc., OU=DEV, CN=QuickSilver-TEST-CASubject:C=US, L=San Jose, O=BEA Systems, Inc., OU=DEV, CN=QuickSilver-TEST-CANot Valid Before:Sat Jul 17 00:00:00 PDT 2004Not Valid After:Tue Oct 17 00:00:00 PDT 2006Signature Algorithm:SHA1withRSA> validation status 0>The certificate record in the BEA AquaLogic Service Bus Console log looks similar to this: HANDSHAKE> validateErr = 0> number: 116908534863041204781210221131467927454Issuer:C=US, L=San Jose, O=BEA Systems, Inc., OU=DEV, CN=QuickSilver-TEST-CASubject:C=US, L=San Jose, O=BEA Systems, Inc., OU=DEV, CN=QS-SERVER-TESTNot Valid Before:Sun Jul 18 00:00:00 PDT 2004Not Valid After:Thu Oct 18 00:00:00 PDT 2007Signature Algorithm:SHA1withRSA> number: 0Issuer:C=US, L=San Jose, O=BEA Systems, Inc., OU=DEV, CN=QuickSilver-TEST-CASubject:C=US, L=San Jose, O=BEA Systems, Inc., OU=DEV, CN=QuickSilver-TEST-CANot Valid Before:Sat Jul 17 00:00:00 PDT 2004Not Valid After:Tue Oct 17 00:00:00 PDT 2006Signature Algorithm:SHA1withRSA> trustmanager validation status 0>Untitled DocumentBEA White Paper BEA AquaLogic Service Bus behind the Firewall in Service-Oriented Architecture246. ConclusionThis white paper describes an example of the configuration of a client, a proxy service, and a business servicecommunicating over firewalls and a DMZ, using inbound and outbound two-way SSL authentication.Specifically, a client generates inbound traffic to a BEA AquaLogic Service Bus proxy service over a securetransport-level connection using two-way SSL. The BEA AquaLogic Service Bus proxy service generates out-bound traffic to business services over a secure transport-level connection using two-way SSL. It is presumedthat the proxy and business services are hosted on BEA WebLogic Server 9.1 or 9.2.This is an example of how to configure such a system. The author would appreciate it if field engineers cansend their descriptions of real-life use cases so that they can be reproduced and contribute to further under-standing of these types of scenarios. If those configurations are significantly different from the one described inthis paper, additional information can be appended to the paper.Please send your comments to alsb-wp@bea.com.7. About BEABEA Systems, Inc. (NASDAQ: BEAS) is a world leader in enterprise infrastructure software, delivering unifiedSOA platforms for business transformation and optimization. Customers depend on BEA Tuxedo , WebLogic ,and AquaLogic"product lines to help reduce IT complexity and leverage existing resources-for achieving astate of Business LiquidITy"where enterprise assets are freed up to deliver maximum business value and grownew revenue streams. Find out more at bea.com.8. Join the BEA communityAt BEA, we understand that developers need different kinds of resources than IT managers. And that architectsface different challenges than executives. That s why we ve created four unique communities that give youexclusive access to a formidable group of your peers, to a world of shared thinking, and to the kind of mean-ingful information that can make you more effective and more competitive. To join one or more of the BEAcommunities, simply register online at bea.com/register.Untitled DocumentCWP1441E0906-1ABEA Systems, Inc.2315 North First Street San Jose, CA 95131+1.800.817.4232+1.408.570.8000bea.com
