Chapter 7 Implementation Module 4: Secure Remote Access Gateway
This chapter provides an overview of the Secure Remote Access (SRA) Gateway module in Figure 2–2 and documents the tasks required to implement it. The chapter includes the following sections:
Overview of the SRA Gateway Module
The SRA Gateway module of the reference configuration deployment architecture illustrated in Figure 2–2consists of two Sun Java System Portal Server Secure Remote Access (SRA) Gateway instances running on two different computers, with additional, optional Rewriter Proxy and Netlet Proxy components residing on the computers hosting Portal Server instances. The module makes use of a hardware load balancer that is configured to provide SRA Gateway service failover capability between the two Gateway instances. All external Internet requests for portal services are addressed to the virtual service name and IP address of the Gateway service load balancer. The load balancer directs each request to one of the Gateway instances.
The Access Manager SDK library is required for each Gateway instance because the Gateway service and Gateway profile are stored as Access Manager services in Directory Server. The Netlet Proxy and Rewriter Proxy instances are accessed directly by the Gateway instances by using a round-robin scheduling algorithm.
The architecture of the SRA Gateway module is shown in the following illustration.
Figure 7–1 SRA Gateway Module
The general approach to implementing this module is to first set up a Gateway profile for the SRA layer. Each Portal Server instance is then configured for SRA operation, after which the Gateway instances themselves are set up. Following these procedures, load balancing is implemented to provide Gateway service failover.
This module can be scaled horizontally by adding an additional computer like sra2 and its respective components, and following the instructions in this chapter that apply to sra2.
When you install and configure the SRA Gateway module, you configure it to interoperate with the other modules in the reference configuration. This chapter describes the procedures for implementing the SRA Gateway module in the following sections.
Note –
The procedures in this chapter use the host names, domain name, and IP addresses shown in Figure 3–1 and Figure 7–1. However, you must map these host names, domain name, and IP addresses to equivalent names and addresses in your environment. For this reason, the procedures in this chapter show host names, domain name, and IP addresses as variables.
Setting Up a Gateway Profile
This task consist of the following procedures:
To Verify the Default Gateway Profile
A default Gateway profile is created at installation time. To verify that this profile exists, use the following procedure on ps1.
-
List all instances of Gateway.
# /opt/SUNWportal/bin/psadmin list-sra-instances -u amadmin -t gateway
When prompted, type the access-manager-admin-password.
The output shows the profile name, but no instances are yet listed:
default:
To Enable the portal service for SRA
The following procedure is performed on ps1, though it affects the portal service provided by both Portal Server instances..
-
Check whether the portal service is enabled for secure remote access.
# /opt/SUNWportal/bin/psadmin get-sra-status -u amadmin
When prompted, type the access-manager-admin-password.
The following output shows that secure remote access is not enabled:
off
-
Enable the portal service for secure remote access.
# /opt/SUNWportal/bin/psadmin switch-sra-status -u amadmin on
When prompted, type the access-manager-admin-password.
This command toggles the SRA status of the portal service between disabled and enabled mode.
To Provision the Gateway Profile
This procedure updates the Gateway profile with information such as the non-authenticated URL list.
-
Run the following command:
/opt/SUNWportal/bin/psadmin provision-sra -u amadmin -p pstestPortal --console --console-url http://ps.pstest.com/psconsole --gateway-profile default --enable
When prompted, type the access-manager-admin-password.
To Verify the Updated Gateway Profile
This procedure is performed using the Portal Server Console (psconsole).
-
Go to the following URL in a browser window:
http://ps.pstest.com/psconsole
-
Log in to the Portal Server Console by typing the following values and clicking Login.
Input Field
Value
User ID
amadmin
Password
access-manager-admin-password
The Portal Server Console opens.
-
Verify the URL path to portal in the Gateway profile.
-
Edit the list of URLs to Which User Session Cookie Is Forwarded.
The list should contain the following values:
http://ps.pstest.com http://ps1.pstest.com http://ps2.pstest.com http://am.pstest.com http://am1.pstest.com http://am2.pstest.com
-
Check that Enable Cookie Management is on.
-
If you made changes, click Save at the bottom of the screen.
-
Click the Security tab.
-
Edit the list of URL's in the Non-authenticated URL box:
The list should contain the following values:
http://am.pstest.com:80/amserver/UI/Login http://am.pstest.com:80/amserver/UI/Logout http://am.pstest.com:80/amconsole/console/css http://am.pstest.com:80/amconsole/console/images http://am.pstest.com:80/amconsole/console/js http://am.pstest.com:80/amserver/css http://am.pstest.com:80/amserver/images http://am.pstest.com:80/amserver/js http://am.pstest.com:80/amserver/login_images http://ps.pstest.com:80/portal/images http://ps.pstest.com:80/portal/desktop/images http://ps.pstest.com:80/portal/desktop/tabs/images http://ps.pstest.com:80/portal/desktop/css http://ps.pstest.com:80/portal/console/images http://ps.pstest.com:80/portal/netlet/jnlpclient.jar http://ps.pstest.com:80/portal/netlet/netletjsse.jar http://ps.pstest.com:80/portal/proxylet/jnlpclient.jar http://ps.pstest.com:80/portal/proxylet/regx-win32-native.jar
Configuring ps1 for SRA Operation
This task involves enabling the Portal Server instance for SRA operations.
It also involves setting up the optional Netlet Proxy and Rewriter Proxy instances, which enable you to make full use of the functionality of the Gateway service. These components were installed on the computers running Portal Server when you implemented the Portal service module (see To Install Portal Server on ps1). You now need only to create instances of these components and configure Portal Server to interoperate with them.
The task consists of the following procedures:
To Set Up a Netlet Proxy Instance on ps1
In this procedure you create and start a Netlet Proxy Instance on ps1.
-
Create a working copy of the Netlet Proxy configuration file.
# cp /opt/SUNWportal/samples/psconfig/example11.xml /tmp/nlp-ps1.xml
-
Edit your working copy of the configuration file in a text editor.
Locate the configuration parameters that are listed in the following table, and change their values to the values shown in the table.
Parameter
Value
@HOST.DOMAIN@
ps1.pstest.com
@LBHOST.DOMAIN@
ps.pstest.com
@PSHOST.DOMAIN@
pstest.com
@PORT@
80
@AMADMIN.PASSWORD@
access-manager-admin-password
@AMLDAPUSER.PASSWORD@
access-manager-LDAP-password
@DIRMGR.PASSWORD@
directory-manager-password
@NETLET.PROXY.PORT@
10555
@IPADDRESS@
10.0.2.3
@SRA.LOGUSER.PASSWORD@
loguser-password
Organization
your-organization
Division
your-division
StateProvince
your-state
CountryCode
your-country
CertificateDatabasePassword
cert-DB-password
@SRA.CERTDB.PASSWORD@
cert-DB-password
-
Create a Netlet Proxy instance.
# /opt/SUNWportal/bin/psconfig --config ./tmp/nlp-ps1.xml
-
Start the Netlet Proxy Instance.
# /opt/SUNWpoartal/bin/psadmin start-sra-instance -u amadmin -N default -t nlproxy
When prompted, type the access-manager-admin-password.
To Set Up a Rewriter Proxy Instance on ps1
-
Create a working copy of the Rewriter Proxy configuration file.
# cp /opt/SUNWportal/samples/psconfig/example12.xml /tmp/rwp-ps1.xml
-
Edit your working copy of the configuration file in a text editor.
Locate the configuration parameters that are listed in the following table, and change their values to the values shown in the table.
Parameter
Value
@HOST.DOMAIN@
ps1.pstest.com
@LBHOST.DOMAIN@
ps.pstest.com
@PSHOST.DOMAIN@
pstest.com
@PORT@
80
@AMADMIN.PASSWORD@
access-manager-admin-password
@AMLDAPUSER.PASSWORD@
access-manager-LDAP-password
@DIRMGR.PASSWORD@
directory-manager-password
@REWRITER.PROXY.PORT@
10443
@IPADDRESS@
10.0.2.3
@SRA.LOGUSER.PASSWORD@
loguser-password
Organization
your-organization
Division
your-division
StateProvince
your-state
CountryCode
your-country
@SRA.CERTDB.PASSWORD@
cert-DB-password
-
Create a Rewriter Proxy instance.
# /opt/SUNWportal/bin/psconfig --config ./tmp/rwp-ps1.xml
-
Start the Rewriter Proxy instance.
# /opt/SUNWpoartal/bin/psadmin start-sra-instance -u amadmin -N default -t rwproxy
When prompted, type the access-manager-admin-password.
To Configure Gateway Instances to Interoperate With
the Netlet Proxy and Rewriter Proxy Instances on ps1
This procedure changes the Gateway profile to use the Netlet and Rewriter proxies on ps1.
-
Start a browser.
-
Go to the following URL:
http://ps.pstest.com/psconsole
The Portal Server Console (psconsole) opens.
-
Log in to the Portal Server Console by typing the following values and click Log in.
Input Field
Value
User ID
amadmin
Password
access-manager-admin-password
The Portal Server Console opens.
-
Click the Secure Remote Access tab.
-
Modify the Gateway profile.
In the Secure Remote Access tab, do the following:
-
In the Profile section, click default.
-
Click the Deployment tab.
-
Locate the section for Rewriter Proxy and Netlet Proxy.
-
Click the checkbox that enables Rewriter Proxy.
-
Locate the Rewriter Proxy list.
-
Add https://ps1.pstest.com:10443 to the list.
-
Click the checkbox that enables Netlet Proxy.
-
Locate the Netlet Proxy List.
-
Add ps1.pstest.com:10555 to the list.
-
Click Save.
-
Configuring ps2 for SRA Operation
This task is the same as Configuring ps1 for SRA Operation. It consists of the following procedures:
To Set Up a Netlet Proxy Instance on ps2
-
Repeat the procedure that appears in To Set Up a Netlet Proxy Instance on ps2, except for the following:
-
Replace all occurrences of ps1 with ps2.
-
Replace 10.0.2.3 with 10.0.2.4.
-
To Set Up a Rewriter Proxy Instance on ps2
-
Repeat the procedure that appears in To Set Up a Rewriter Proxy Instance on ps1, except for the following:
-
Replace all occurrences of ps1 with ps2.
-
Replace 10.0.2.3 with 10.0.2.4.
-
To Configure Gateway Instances to Interoperate With
the Netlet Proxy and Rewriter Proxy Instances on ps2
-
Repeat the procedure that appears in To Configure Gateway Instances to Interoperate With the Netlet Proxy and Rewriter Proxy Instances on ps1, except for the following:
Replace all occurrences of ps1 with ps2. In particular, replace ps1.pstest.com with ps2.pstest.com.
Setting Up the Gateway Service on sra1
This task consists of the following procedures:
To Install SRA Gateway on sra1
This procedure assumes that you are installing Portal Server SRA Gateway on Solaris 10 8/07 OS or later version. Hence, no operating system patches need to be installed. The Java ES installer evaluates the state of the operating system and indicates if you need to install a patch. If you are using versions of the operating system older than Solaris 10 8/07 OS, it is better to install any required patches before you begin the actual SRA Gateway installation procedure.
This procedure runs the installer in Configure Later mode. After installation is complete, you manually configure a Gateway instance.
The following procedure runs the Java ES installer without saving a state file. You can choose to run the installer and capture your input in a state file (-saveState state-filename). You could then use the state file to re-create the installation if, for example, you needed to reinstall SRA Gateway.
-
Download the Java ES software distribution to sra1.
The procedure is documented in To Download the Software Distribution.
-
Log in as root or become superuser.
# su -
-
Start the Java ES installer.
# cd /portdist_71u2/Solaris_sparc
# ./installer
This procedure uses the GUI installer. The installer can also be run in text mode by using the - nodisplay option.
The Welcome panel opens.
-
In the Welcome panel, click Next.
The Software License Agreement panel opens.
-
In the Software License Agreement Panel, review the license terms and click Yes, Accept License.
The Choose Software Components panel opens.
-
In the Choose Software Components panel, select the following components:
-
Click Next.
The Dependency Warning panel opens.
-
In the Dependency Warning panel, choose Use Directory Server Installed on a Remote Machine and click OK.
The installer evaluates the Java SE Software Development Kit on the computer and determines if an upgrade is required. On a fresh copy of Solaris 10 8/07 OS, an upgrade is needed, and the Java SE Software Development Kit Upgrade Required panel opens.
-
In the Java SE Software Development Kit Upgrade Required panel, select Automatic Upgrade to the Version Included with the Installer and click Next.
The installer evaluates the Java ES shared components on the computer and determines if any upgrades are required. On a fresh copy of the Solaris 10 8/07 OS, shared component upgrades are needed, and the Shared Components Upgrades Required panel opens.
-
In the Shared Components Upgrades Required panel, click Next.
The installer upgrades the shared components. The Specify Installation Directories panel opens.
-
In the Specify Installation Directories panel, type the following values and click Next.
Input Field
Value
Portal Server Secure Remote Access
/opt
Access Manager
/opt
The System Check panel opens.
-
In the System Check panel, evaluate the results of the system check.
If the system check is favorable, click Next.
The Choose a Configuration Type panel opens.
-
In the Choose a Configuration Type panel, select Configure Later and click Next.
The Ready to Install panel opens.
-
In the Ready to Install panel, indicate whether you want to open the software registration window during installation.
This panel enables you to register the components that you have selected for installation with Sun Connection. Sun Connection is a Sun-hosted service that helps you track, organize, and maintain Sun hardware and software. For example, Sun Connection can inform you of the latest available security fixes, recommended updates, and feature enhancements.
If you choose to register, information about the installation is sent to the Sun Connection database. You can also register at a later date, after installation has been completed.
-
Click Install.
The installer copies files to the computer.
-
When the installation is complete, review the installation in the Summary field.
-
Click Exit to exit the installer.
-
Check the installation log files for any installation errors.
# cd /var/sadm/install/logs
# egrep -i 'fail|error' Java*
-
Apply the patch to Portal Server 7.1 Update 2.
The following patch to Portal Server 7.1 Update 2 is needed for the Gateway service to interact with Portal Server through a firewall:
-
Solaris SPARC: 124301–10
-
Solaris x86: 124302–10
-
Linux: 124303–10
The patch revision number (10) is the minimum required for this upgrade. If newer revisions become available, use the newer revisions instead of the preceding patch revisions.
-
Access the SunSolveSM web site:
http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
-
Search for the patch ID.
-
Download the patch to /working-directory.
-
Apply the patch.
# patchadd /working-directory/patch-ID
The patchadd command will instruct you to run psupdate -a, but you can safely skip this step.
-
Confirm that the patch upgrade was successful.
# showrev —p | grep patch-ID
The output should return the version of the patch ID that was applied in Step 18d.
-
To Configure Access Manager SDK on sra1
Because Access Manager SDK was installed using the Configure Later option, you need to configure Access Manager SDK by modifying Access Manager configuration files. The standard approach for making these modifications is to run the amconfig command with an input file.
-
Change to the directory that contains the amconfig input file template, amsamplesilent.
# cd /opt/SUNWam/bin
-
Copy the template to a new file.
# cp amsamplesilent amconfigsra
-
In a text editor, edit the amconfigsra file to set the Access Manager SDK configuration parameters.
Locate the configuration parameters that are listed in the following table, and change their values to the values shown in the table.
Parameter
Value
DEPLOY_LEVEL
3
SERVER_HOST
am.pstest.com
SERVER_PORT
80
DS_HOST
ds.pstest.com
DS_DIRMGRPASSWD
directory-manager-password
ROOT_SUFFIX
"dc=pstest,dc=com"
SM_CONFIG_BASEDN
$ROOT_SUFFIX
ADMINPASSWD
access-manager-admin-password
AMLDAPUSERPASSWD
access-manager-LDAP-password
COOKIE_DOMAIN
pstest.com
AM_ENC_PWD
password-enc-key
-
Run the amconfig command with the input file you modified in Step 3.
# /opt/SUNWam/bin/amconfig -s amconfigsra
-
Verify that the Access Manager SDK is properly configured.
# /opt/SUNWam/bin/amadmin —u amadmin —m http://am.pstest.com:80
The output should show current session information.
To Create a Gateway Instance on sra1
This procedure uses the psconfig command and a configuration file to create a Gateway instance. You begin with the appropriate configuration file as a template and edit the file to specify parameter values that are needed for the reference configuration.
-
Create a config-sra1 configuration file.
Use the example10.xml file as a template.
# cd /opt/SUNWportal/samples/psconfig
# cp example10.xml config-sra1.xml
-
Open the config-sra1.xml file in a text editor.
-
Modify config-sra1.xml to use the values in the following table.
Parameter
Value
ConfigurationHostName
sra1.pstest.com
AdministratorUID
amadmin
AdministratorUserPassword
access-manager-admin-password
LDAPUserId
amldapuser
LDAPUserIdPassword
access-manager-LDAP-password
DirectoryManagerDn
cn=Directory Manager
directory-manager-password
directory-manager-password
PortalAccessURL
http://ps.pstest.com:80/portal
PrimaryPortalHost
ps1.pstest.com
Protocol
https
Host
sra1.pstest.com
Port
443
IPAddress
10.0.4.1
LogUserPassword
log-user-password
RestrictiveMode
true
Organization
your-organization
Division
your-division
CityOrLocality
your-city
StateProvince
your-state
CountryCode
your-country
CertificateDatabasePassword
cert-DB-password
The modified config-sra1.xml file is reproduced in Example Configuration File: Gateway Instance on sra1.
-
Run the psconfig command with the configuration file input.
# cd /opt/SUNWportal/bin
# ./psconfig --config /opt/SUNWportal/samples/psconfig/config-sra1.xml
The output should resemble the following:
Creating directory: /etc/opt/SUNWportal Copying config templates from: /opt/SUNWportal/template/config Successfully created PortalDomainConfig.properties file Validating the Input Config XML File Configuring Cacao Agent for Portal Software Connecting to Cacao MBean Server ... Closing MBean Server connection Resetting log level Configuration successful
To Start and Verify the Gateway Service on sra1
-
Start the Gateway instance.
# /opt/SUNWportal/bin/psadmin start-sra-instance -u amadmin -N default -t gateway --restrictive
When prompted, type the access-manager-admin-password.
-
Start a browser.
-
Go to the following URL:
https://sra1.pstest.com
You are prompted to accept the Gateway's self-signed certificate.
-
Accept the certificate.
The Access Manager login page opens.
-
Log in to the Portal desktop by typing the following values and clicking Login.
Input Field
Value
User ID
developer
Password
developer
If you successfully login, the Gateway is operating correctly.
Setting Up the Gateway Service on sra2
This task consists of the following procedures:
To Install Portal Server SRA Gateway on sra2
-
Repeat the procedure that appears in To Install SRA Gateway on sra1.
The installer's Configure Later option does not prompt you for configuration information.
To Configure Access Manager SDK on sra2
-
Repeat the procedure that appears in To Configure Access Manager SDK on sra1.
To Create a Gateway Instance on sra2
-
Repeat the procedure in To Create a Gateway Instance on sra1, except for the following:
-
Replace all occurrences of sra1 with sra2.
-
Replace 10.0.4.1 with 10.0.4.2.
-
To Start and Verify the Gateway Service on sra2
-
Repeat the procedure in To Start and Verify the Gateway Service on sra1, except for the following:
Replace all occurrences of sra1 with sra2.
Implementing Load Balancing for the Gateway Service
This task consists of the following procedures:
To Configure the Load Balancer for the Gateway Service
This procedure describes how to configure the Gateway service load balancer (sra.pstest.com at IP address 10.0.5.10). The steps are relatively generic; the details depend on the load balancer you are using.
-
Populate the load balancer's Hosts Table.
Add the IP address for sra1.pstest.com and sra2.pstest.com to the load balancer's hosts table.
-
Populate the load balancer's Real Service Table.
Add the real services for sra1.pstest.com and sra2.pstest.com. A real service is identified by its IP address and port. Add 10.0.4.1:443 and 10.0.4.2:443.
-
Populate the load balancer's Service Group Table.
Add the service group for Gateway services. The service groups are sets of the real services that you defined in Step 2. The real services in the group must be capable of fulfilling the same type of request. The load balancer will distribute requests among the real services in the service group. When you define the service group for the sra.pstest.com, you add the real services that specify the Gateway instances, 10.0.4.1:443 and 10.0.4.2.443.
-
Set the load balancer to perform certificate authentication.
-
Generate an SSL key and certificate request.
Use the certificate and key manager (CKM) on the load balancer.
-
Obtain a valid X.509 certificate.
Submit the certificate signing request (CSR) to an authorized certificate authority (CA). Alternatively, the load balancer might have a utility for generating a test certificate.
-
Install the X.509 certificate.
The method for installing the certificate depends on the load balancer.
-
-
Populate the load balancer's Virtual IP Table.
A virtual service definition includes the outward-facing IP address and the port at which the load balancer accepts requests for a service, as well as the service group that you specified in Step 3, which actually handles the requests. The load balancer will accept requests at the virtual service address and distribute them among the service group. The virtual service definition for the Gateway service should be sra.pstest.com, with the virtual IP address of 10.0.5.10:443, and with the service group consisting of the computers sra1.pstest.com and sra2.pstest.com.
-
Configure the load balancer to use Layer-7 (HTTP layer) load balancing.
-
Configure the load balancer with a scheduling type of either least connections or round robin.
Both scheduling types initially distribute the connections evenly between the Portal Server instances. Both scheduling types keep the connections evenly distributed if the connections are restarted.
-
Configure the load balancer for sticky routing.
Although not mandatory, it is good practice to maintain a binding between the user's session and the Gateway instance that processed the user's initial request. Gateway instances keep, in cache, the Access Manager sessions that are associated with user requests. If there is no session persistence on the Gateway instances, user requests are routed randomly to the Gateway instances, and every instance caches every user session. This duplication creates additional network traffic whenever a Gateway instance needs to refresh a session. It also leads to unnecessary memory use by the Gateway instances.
Configuring the Gateway service load balancer to maintain session persistence with the Gateway instances will prevent these problems.
In the reference configuration, Internet users access the portal service over HTTPS connections to the Gateway service. When users connect over HTTPS, the requests, including any session persistence cookies that help a load balancer route the traffic to the correct instance, are encrypted. The information in the cookies is not available to the load balancer for routing purposes. The following are two ways of handling this situation in the Gateway service load balancer:
-
SSL termination
If the load balancer supports SSL termination, then the load balancer can perform all the encryption and decryption work that is needed to terminate SSL at the load balancer. Terminating SSL at the load balancer reduces the load on the Gateway instances and improves performance. When the load balancer decrypts an HTTPS request, the session cookie is available to the load balancer. If the load balancer supports passive cookies, it can be configured to maintain session persistence. This approach is the preferred way to configure a load balancer for sticky routing.
If the load balancer does not support passive cookies, session persistence can be maintained by using the client IP address. However, if multiple users are using a web proxy to reach the Gateway service load balancer, the IP address that the load balancer will see is the IP address of the web proxy. In this case, all users who are using the same web proxy will be routed to the same Gateway instance, possibly resulting in an uneven load on the Gateway instances.
-
SSL session ID
If the load balancer does not support SSL termination, then it cannot read the session cookie. In this case, you can configure the load balancer to read the SSL session ID and make routing decisions based on the value of the session ID.
-
-
Configure the health-check settings for the load balancer.
The recommended settings are specified in Table 3–5.
To Configure the Gateway Service on sra1 for Load Balancing
If SSL sessions are terminated at the Gateway service load balancer, the traffic between the load balancer and the Gateway instances are plain HTTP. In that case, it is necessary to configure the Gateway instances to use the load balancer's virtual name (sra.pstest.com) and protocol (HTTPS) in all content that is rewritten.
You do so by configuring the attributes on the platform.conf file that is associated with the profile that the Gateway instance is using.
-
Open the platform.conf file on sra1 in a text editor.
The file is located at:
/etc/opt/SUNWportal/platform.conf.default
-
Modify the following properties as follows:
gateway.enable.customurl=true gateway.enable.accelerator=true gateway.httpurl=https://sra.pstest.com:443 gateway.httpsurl=https://sra.pstest.com:443 gateway.virtualhost=sra.pstest.com 10.0.5.10
-
Restart the Gateway instance on sra1.
-
Stop the Gateway instance on sra1.
# /opt/SUNWportal/bin/psadmin stop-sra-instance -u amadmin -N default -t gateway
When prompted, type the access-manager-admin-password.
-
Start the Gateway instance on sra1.
# /opt/SUNWportal/bin/psadmin start-sra-instance -u amadmin -N default -t gateway --restrictive
When prompted, type the access-manager-admin-password.
-
-
Verify that the Gateway instance is running in non-SSL mode.
# telnet 10.0.4.1 443
GET / HTTP/1.1 <carriage return>
HOST:sra.pstest.com <carriage return>
Connection:Close <carriage return>
<carriage return>
The response should resemble the following:
HTTP/1.0 302 Moved Temporarily Date: Fri. 08 Feb 2008 21:27:00 GMT Server: Redirector Location: https://sra.pstest.com/http://am.pstest.com/amserver/UI/Login?qw=&...
To Configure the Gateway Service on sra2 for Load Balancing
-
Repeat the procedure in except for the following:
-
Replace all occurrences of sra1 with sra2.
-
Replace 10.0.4.1 with 10.0.4.2.
-
To Verify Load Balancing for the Gateway Service
This procedure verifies that you can interact with Gateway instances through the load balancer and that the load balancer provides service failover when a Gateway instance fails.
-
Start the Gateway instances on sra1 and sra2, if they are not already running.
# /opt/SUNWportal/bin/psadmin start-sra-instance -u amadmin -N default -t gateway --restrictive
When prompted, type the access-manager-admin-password.
-
Start a browser.
-
Go to the Access Manager login page by using the load balancer URL
http://sra.pstest.com
The Access Manager login page opens.
-
Log in to the portal by typing the following values and clicking Login.
Input Field
Value
User ID
developer
Password
developer
The Developer Sample desktop opens, which confirms that the load balancer has routed the login request to one of the Gateway instances.
-
Determine the Gateway instance handling the login request in Step 4.
-
Open the log file on sra1.
# cd /var/opt/SUNWportal/logs/sra/default
# tail —f portal.gateway.0.0.log
-
Open the log file on sra2.
# cd /var/opt/SUNWportal/logs/sra/default
# tail —f portal.gateway.0.0.log
-
Note which log file displays more output.
Whichever Gateway instance is servicing the request will cause more output to be generated.
-
-
Simulate a failure of the Gateway instance that was noted in Step 5.
In the configuration interface for your load balancer (sra.pstest.com), disable the Gateway instance that you identified in Step 5 (or otherwise remove it from the service group).
-
Refresh the browser page.
If service failover is working correctly, the Access Manager login page opens, confirming that the load balancer has routed the request to the remaining online Gateway instance.
-
Recover the simulated failure of your original Portal Server instance.
Return to the configuration interface for your load balancer, and replace the real server instance that you removed in Step 6 to the load balancer service group.
- © 2010, Oracle Corporation and/or its affiliates