Federated Reverse Proxy Setup

How-to Guide

SAP NetWeaver 2004s

How To… Configure Reverse Proxies in Federated Portal Network Scenarios

Version 1.00 – April, 2006

Applicable Releases: SAP NetWeaver 2004s SP Stack 07

Configuring a Reverse Proxy in Federated Portal Network Scenarios 2

© Copyright 2006 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBM Corporation in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

MaxDB is a trademark of MySQL AB, Sweden.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data

contained in this document serves informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

These materials are provided “as is” without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement.

SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials.

SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these materials. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third party web pages nor provide any warranty whatsoever relating to third party web pages.

SAP NetWeaver “How-to” Guides are intended to simplify the product implementation. While specific product features and procedures typically are explained in a practical business context, it is not implied that those features and procedures are the only approach in solving a specific business problem using SAP NetWeaver. Should you wish to receive additional information, clarification or support, please refer to SAP Consulting.

Any software coding and/or code lines / strings (“Code”) included in this documentation are only examples and are not intended to be used in a productive system environment. The Code is only intended better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, except if such damages were caused by SAP intentionally or grossly negligent.


Icons in Body Text

Icon Meaning

Caution

Example

Note

Recommendation


Contents

Reverse Proxy Scenarios with Federated Portal Network Implementations............................. 5 1.1. The Environment......................................................................................................... 6 1.2. Scenario 1: simple reverse proxy network .................................................................. 8 1.3. Scenario 2: two or more than reverse proxies ............................................................ 9 1.4. Scenario 3: internal network users............................................................................ 10 1.5. Scenario 4: internal network reverse proxies............................................................ 11 1.6. General rule/limitation ............................................................................................... 12

Document History

Version Description

1.00 First release


Configuration for Reverse Proxy Scenarios with Federated Portal Network Implementations

Important Note: Read before continuing.

Although the information in this document is written in accordance with known IT best practices, and has been tested in a development environment, it has not been fully qualified according to SAP quality assurance standards. Qualification is expected to take place prior to an upcoming release.

For a detailed limitation statement, see SAP Note 853509, the central limitation note for NetWeaver 2004s.

Use For reasons of security, load distribution and the caching of static content, reverse proxies are a common and generally necessary part of the network scenario in large organizations. The configuration of proxy parameters in a standard NetWeaver portal scenario is straightforward and is described in the portal administration documentation at: help.sap.com/nw2004s → English/German → SAP Library → SAP NetWeaver Library → SAP NetWeaver by Key Capability → People Integration by Key Capability → Portal → Portal Administration Guide → System Administration → System Configuration → Service Configuration → System Properties for Proxy Server.

However, the IT environments at customer sites that would be implementing the SAP federated portal network are varied and complex network scenarios, likely to consist of multiple domains, networks and even sub-networks. Adding the implementation of portal federation, therefore, makes configuration for the use of reverse proxy more complicated, involving several network components.

For more information about the implementation of a federated portal network, including concepts and related business scenarios, go to help.sap.com/nw2004s → English/German → SAP Library → SAP NetWeaver Library → SAP NetWeaver by Key Capability → People Integration by Key Capability → Portal → Portal Scenarios (Running an Enterprise Portal) → Implementing a Federated Portal Network.

Purpose This document provides configuration information about four different network scenarios, realizing that, though none of the scenarios individually defines the real-life network environment, the real-life environment would encompass a combination of all or some of these scenarios. The aim is that the following scenarios will aid IT personnel analyze the configuration requirements of their systems more easily.


1.1. The Environment Figure 1 illustrates a basic scenario, starting with the end user in domain A, through the DMZ in domain B where the firewalls and reverse proxy are located, and on to the federated portal consumer and producer portals, communication with each other in domain C.

Figure 1

This basic environment serves also as the model for Scenario 1 below.

The Basic Flow stallation on the target machine ... nstallation on the target machine

1. The end-user request is directed via the reverse proxy to the consumer portal.

2. The consumer portal returns HTML content.

However, if some of the requested content is not be available from the consumer portal:

The HTML content returned by the consumer portal will be redirected (either as HTML or, possibly, some JavaScript activated from the browser) to the producer portal to complete the content.

What to Configure The common deployment scenario of NetWeaver portals consists of a consumer portal, a producer portal, a DMZ between them, and the client browsers (end users). Often, in real-world scenarios, a consumer portal communicates with a number of producer portals. For the sake of simplicity, we will look at a single consumer-producer scenario.

The general configuration requirements are: ... Installation on the target machine

1. Adding names to the DNS on domain A

2. Setting rules on the reverse proxy

3. Configuring firewalls to support reverse proxy rules

4. Configuring the consumer portal

The consumer and producer machines do not have to be on the same domain or in the same network.

The following sections contain descriptions of the procedures involved for the above-mentioned configuration requirements (1-4) for four different scenarios.


Because of the vast diversity in firewall technologies on the market, and in use at different organizations, it is assumed here that the reader has the knowledge, or access to the knowledge, required to configure the firewalls onsite.

Hostnames We will refer to the “internal” area of the network where the consumer portal and producer servers are located as the internal network; the user side of the DMZ is referred to as the external network. The hostnames used for the portal machines (consumer and producer) on the internal network will be different from the hostnames used externally for these machines. The external hostnames may be dictated by branding or other issues and will generally be names recognizable and meaningful to the end user. On the other hand, it is the IT department that would be likely to dictate the internal names—recognizable to other servers on the network.


1.2. Scenario 1: Simple Reverse Proxy Network The simple scenario in figure 2 is based on the generic illustration in figure 1, with specific hostnames and IP address as examples.

Figure 2

Configuration of the Network Devices Installation on the target machine

1. On the DNS server accessible to the end user, configure the world DNS of the "external network" hostnames both for the consumer and the producer portals to point to the IP address of the reverse proxy.

For example: consumer.myBusiness.com 21.0.0.4

producer.myBusiness.com 21.0.0.4

2. Configure the reverse proxy with rules to direct calls to the correct portal addresses.

consumer.myBusiness.com* => p11.our.net*

producer.myBusiness.com* => p12.our.net*

3. Configure the firewalls to support the reverse proxy rules.

4. Configure the consumer.

a. On the consumer machine, navigate as follows: System Administrator → Federated Portal → Myself as Content Producer → Manage My Producers.

b. Double-click and deregister the producer portal so that it can be edited. (When it is registered its permission changes to read-only.)

c. In the Property Editor, under the "Remote Content Provider" category, change the properties:

com.sap.portal.remotePortal.<External_Network_Hostname> to producer.myBusiness.com (for example)

and

<ExternalNetworkPort> to the respective port

d. Save and reregister the producer portal.

5. If there are multiple producer portals, repeat step 4 for each one.


1.3. Scenario 2: Two or More Reverse Proxies Sometimes two or more reverse proxies are directed to the same internal network. In the scenario illustrated in figure 3, there are two user groups. The scenario is as follows:

• Group A is represented here by user A.

• Group B is represented by user B.

• User A and B are in different locations in the IT landscape of the organization.

• Both user A and user B access the same consumer portal, on ufn30.net, but through different reverse proxies.

• The consumer portal consumes content from the producer portal ufn20.net.

Figure 3

Configuration for Scenario 2 The configuration for this scenario is very similar to that of scenario 1 and the same network elements need to be configured for each user group: ... Installation on the target machine

1. Add names to the DNS on the user group domains.

The main point in this scenario is that two separate reverse proxies are protecting the same consumer portal and two separate DNS servers must be used, one for each user group.

2. Set rules on the reverse proxy.

This is the same as described for scenario 1, for each reverse proxy.

Since the DNS configuration has the same names for some portals, some of the rules will be the same as well.

3. Configure the firewalls to support the reverse proxy rules.

Same as scenario 1. Configuration to support the reverse proxy rules.

4. Configure the consumer portals.

Same as scenario 1.


1.4. Scenario 3: Internal Network Users Scenario 3 describes a situation in which some users reside within the internal network. Typically, these users are administrators.

Figure 4

Configuration for Scenario 3 The configuration issues in this scenario are as follows:

• The internal user must also access the portals in the internal network through the reverse proxy and therefore also requires DNS mapping to the reverse proxy, the same as in scenario 1.

If the internal user accesses the portals directly, the portals will still generate URLs with the external network hostname, which would not be recognized by servers in the internal network.

In a closed organization, the internal user may use the same DNS name from the same DNS server. This depends on the local landscape.

• This scenario requires configuration of the firewall to allow internal users access to the reverse proxy from the internal network.


1.5. Scenario 4: Internal Network Reverse Proxies Many IT landscapes have deployment schemes that are much more complex than those presented in the previous scenarios, but the basic rules of configuration do not change much. As figure 5 illustrates:

• Scenario 4 has another DMZ network inside the internal network of the organization.

• The end user working opposite the consumer portal, ufn30.net, may be directed to content on both producer portals, ufn20.net and ufn10.net2.

We will refer to the reverse proxy accessed by the end user as reverse proxy 1 and to the "internal" reverse proxy as reverse proxy 2. In this scenario, only the reverse proxy1 and DNS server that are closest to the end user need special attention, as described in scenario 1. The configuration of reverse proxy 2 is not affect in any special way due to the implementation of a federated portal network.

Figure 5

Accessing data from producer portals The flow from the end user to the producer portal in internal network 1, and the configuration for ufn30.net and ufn20.net are already described at scenario 1.

However, requests from the end user for content from the producer portal on ufn10.net2 need to pass dual routing via both reverse proxies 1 and 2.

Configuring for access to ufn10.net2: ... Installation on the target machine

1. Add names to the DNS on the user group domains.

The ufn10.net2 should have an external network hostname such as finance.mycompany.com mapped to the IP address of reverse proxy 1.

This name should be configured only on the end-user accessible DNS.

External network hostname/port property values should be configured on ufn30.net for ufn10.net2.

2. From this point and on there are many possible configurations to achieve the dual routing. Here is one:

a. On the DNS server of the internal network, which is accessible by reverse proxy 1, configure an external network hostname, such as internalproxy.mycompany.org, that points to the IP address of reverse proxy 2.


b. Create a rule on reverse proxy 1 to map finance.mycompany.com* => internalproxy.mycompany.org

c. Create a rule on reverse proxy 2 to map internalproxy.mycompany.org* => * ufn10.net2

d. Configure firewalls to support all the above.

1.6. General rule/limitation No scenario works with mixed http/https protocols. If access to one portal uses HTTP and access to another portal uses HTTPS, the federated portal network implementation may not work.

Documents

Federated Reverse Proxy Setup