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

 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.

Configuring a Reverse Proxy in Federated Portal Network Scenarios

Icons in Body Text

Icon

Meaning
Caution
Example
Note
Recommendation

Configuring a Reverse Proxy in Federated Portal Network Scenarios

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

Configuring a Reverse Proxy in Federated Portal Network Scenarios

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.

Configuring a Reverse Proxy in Federated Portal Network Scenarios

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 realworld 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 abovementioned configuration requirements (1-4) for four different scenarios.

Configuring a Reverse Proxy in Federated Portal Network 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 namesrecognizable to other servers on the network.

Configuring a Reverse Proxy in Federated Portal Network Scenarios

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.

Configuring a Reverse Proxy in Federated Portal Network Scenarios

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.

Configuring a Reverse Proxy in Federated Portal Network Scenarios

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.

Configuring a Reverse Proxy in Federated Portal Network Scenarios

10

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.

Configuring a Reverse Proxy in Federated Portal Network Scenarios

11

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.

Configuring a Reverse Proxy in Federated Portal Network Scenarios

12