Chapter 2 Working With Gateway

This chapter describes Gateway related concepts. For information on managing the gateway, see Chapter 16, Managing the Gateway. For information about configuring the Gateway, see Chapter 8, Configuring the Secure Remote Access Gateway.

This chapter covers the following topics:

• Introduction to Gateway

• Understanding the platform.conf File

• Using Web Proxies

• Using Automatic Proxy Configuration

• Using a Netlet Proxy

• Using a Rewriter Proxy

• Using a Reverse Proxy with the Gateway

• Obtaining Client Information

• Using Authentication Chaining

• Using Wild Card Certificates

• Disabling Browser Caching

• Customizing the Gateway Service User Interface

Introduction to Gateway

The Gateway provides the interface and security barrier between remote user sessions originating from the Internet and your corporate intranet. The Gateway presents content securely from internal web servers and application servers through a single interface to a remote user.

For each Gateway instance you must complete the following tasks:

• Creating a Gateway Profile

• Creating Multiple Instances of a Gateway

• Chapter 8, Configuring the Secure Remote Access Gateway.

Other gateway related topics include the following:

• Restarting the Gateway

• Configuring the Gateway Watchdog

• Specifying a Virtual Host

• Specifying a Proxy to Contact Access Manager

Creating a Gateway Profile

A gateway profile contains all the information related to gateway configuration, such as the port on which the Gateway listens, SSL options, and proxy options. When you install a Gateway, if you choose the default values, a default gateway profile called "default" is created. A configuration file corresponding to the default profile exists at: /etc/opt/SUNWportal/platform.conf.default.

Where /etc/opt/SUNWportal is the default location for all the platform.conf.* files. For more information on the platform.conf file, see Understanding the platform.conf File.

When working with profiles, you can perform the following tasks:

• Create multiple profiles, define attributes for each profile, and assign these profiles to different Gateways as required.

• Assign a single profile to Gateway installations on different machines.

• Assign different profiles to instances of a single Gateway running on the same machine.

Do not assign the same profile to different instances of the Gateway running on the same machine. This setup causes a conflict because the port numbers are the same.

Do not specify the same port numbers in the different profiles created for the same Gateway. Running multiple instances of the same Gateway with the same port causes a conflict.

Creating Multiple Instances of a Gateway

To create multiple instances of a gateway, see Chapter 4, Installing and Configuring a Gateway With Portal Server, in Sun Java System Portal Server 7.2 Installation and Configuration Guide

Creating Multi-homed Gateway Instances

Multi-homed gateway instances are multiple gateways on one Portal Server. To create these instances, modify the platform.conf file as follows:

gatewaybindipaddress = 0.0.0.0

Creating Gateway Instances Using the Same LDAP

If you are creating multiple gateway instances that use the same LDAP, after creating the first Gateway on all subsequent Gateways:

In /etc/opt/SUNWam/config/, modify the following areas in AMConfig-instance-name.properties to be consistent with the first installed instance of the Gateway.

See To Create Gateway Instances Using the Same LDAP

Restarting the Gateway

Normally, you do not need to restart the Gateway. You need to restart only if any of the following events occur:

• You have created a new profile and need to assign the new profile to the Gateway.

• You have modified some attributes in the existing profile and need the changes to take effect.

• Gateway crashes due errors such as OutOfMemory error.

• Gateway stops responding and does not service any requests.

Configuring the Gateway Watchdog

You can configure the time interval at which the watchdog monitors the status of the Gateway. To start or to stop the watchdog, run the command;./psadmin sra-watchdog -u amadmin -f <password-file> -t <type> on|off. This time interval is set to 60 seconds by default. To change this value, edit the following line in the crontab utility:

0-59 * * * * gateway-install-root/SUNWportal/bin/
/var/opt/SUNWportal/.gw. 5 > /dev/null 2>&1

See the crontab man page to configure the crontab entries.

Specifying a Virtual Host

A virtual host is an additional host name that points to the same machine IP and a host name. For example, if a host name abc points to the host IP address 192.155.205.133, you can add another host name cde which points to the same IP address.

Specifying a Proxy to Contact Access Manager

You can specify a proxy host to be used by the Gateway to contact SRA Core (RemoteConfigServlet) that is deployed over the Portal Server. This proxy is used by the Gateway to reach the Portal Server and Access Manager. See, To Specify a Proxy.

Understanding the platform.conf File

The platform.conf file is located by default at: /etc/opt/SUNWportal.

The platform.conf file contains the details that the Gateway needs. This section provides a sample platform.conf file and describes all the entries.

The advantage of including all the machine-specific details in the configuration file is that a common profile can be shared by Gateways running on multiple machines.

The following is a sample of the platform.conf file.

Tue May 30 11:51:23 IST 2006
debug.com.sun.portal.rewriter.original.level=INFO
gateway.favicon=
gateway.bindipaddress=10.12.154.236
debug.com.sun.portal.sra.rproxy.toFromServer.handler.java.util.logging.FileHandler.pattern=
/var/opt/SUNWportal/logs/sra/default/Gateway.toFromServer.%u.%g.log
gateway.port=443
rewriterproxy.jvm.flags=-ms64m -mx128m
portal.server.instance=default
debug.com.sun.portal.handler.java.util.logging.FileHandler.filter=
gateway.jdk.dir=/usr/jdk/entsys-j2se
gateway.ignoreURIList=/MSOffice/cltreq.asp,/_vti_bin/owssvr.dll
debug.com.sun.portal.rewriter.rest.level=INFO
gateway.trust_all_server_certs=true
debug.com.sun.portal.handler.java.util.logging.FileHandler.append=true
gateway.cdm.cacheCleanupTime=300000
gateway.httpurl=
debug.com.sun.portal.handler.java.util.logging.FileHandler.count=1
gateway.jvm.classpath=
debug.com.sun.portal.setserverlogs=false
gateway.protocol=https
debug.com.sun.portal.sra.rproxy.toFromServer=java.util.logging.FileHandler
rewriterproxy.jvm.classpath=
gateway.enable.customurl=false
debug.com.sun.portal.sra.rproxy.toFromBrowser=java.util.logging.FileHandler
debug.com.sun.portal.handler.java.util.logging.FileHandler.formatter=com.sun.portal.
log.common.PortalLogFormatter
debug.com.sun.portal.sra.rproxy.toFromBrowser.handler.java.util.logging.FileHandler.pattern=
/var/opt/SUNWportal/logs/sra/default/Gateway.toFromBrowser.%u.%g.log
debug.com.sun.portal.level=INFO
debug.com.sun.portal.rewriter.unaffected.separatefile=true
gateway.enable.accelerator=false
debug.com.sun.portal.rewriter.original.separatefile=true
gateway.virtualhost=nicp236.india.sun.com 10.12.154.236
debug.com.sun.portal.stacktrace=true 
gateway.host=nicp236.india.sun.com
debug.com.sun.portal.handler.java.util.logging.FileHandler.pattern=
/var/opt/SUNWportal/logs/sra/default/%logger.%sraComponentType.%u.%g.log
gateway.certdir=/etc/opt/SUNWportal/cert/default
gateway.sockretries=3
gateway.allow.client.caching=true
debug.com.sun.portal.rewriter.unaffected.level=INFO
debug.com.sun.portal.rewriter.uriinfo.separatefile=true
log.config.check.period=2000
debug.com.sun.portal.rewriter.rewritten.level=INFO
gateway.userProfile.cacheSize=1024
debug.com.sun.portal.rewriter.rulesetinfo.level=INFO
netletproxy.jvm.classpath=
gateway.userProfile.cacheSleepTime=60000
debug.com.sun.portal.rewriter.uriinfo.level=INFO
debug.com.sun.portal.rewriter.rest.separatefile=true
gateway.notification.url=notification
debug.com.sun.portal.rewriter.rulesetinfo.separatefile=true
gateway.logdelimiter=&&
gateway.ignoreServerList=false
gateway.jvm.flags=-ms64m -mx128m
debug.com.sun.portal.handler.java.util.logging.FileHandler.limit=5000000
gateway.dsame.agent=http\://sunone216.india.sun.com\:8080/portal/RemoteConfigServlet
gateway.httpsurl=
gateway.retries=6
gateway.userProfile.cacheCleanupTime=300000
gateway.logging.password=X03MO1qnZdYdgyfeuILPmQ\=\= UX9x0jIua3hx1YOVRG/TLg\=\=
netletproxy.jvm.flags=-ms64m -mx128m
debug.com.sun.portal.rewriter.rewritten.separatefile=true
gateway.user=noaccess
gateway.external.ip=10.12.154.236
debug.com.sun.portal.handler=java.util.logging.FileHandler
gateway.cdm.cacheSleepTime=60000
rewriterproxy.accept.from.gateways=
rewriterproxy.checkacl=false

The following table lists and describes all the fields in the platform.conf file.

Using Web Proxies

You can configure the Gateway to contact HTTP resources using third party web proxies. Web proxies reside between the client and the Internet.

Web Proxy Configuration

Different proxies may be used for different domains and subdomains. These entries tell the Gateway which proxy to use to contact specific subdomains in specific domains. The proxy configuration specified in the Gateway works as follows:

• Creates a list of domains and subdomains along with the required proxies in the Proxies for Domains and Subdomains field in the Gateway service.

• With the Use Proxy option enabled:

  • The proxies specified in the Proxies for Domains and Subdomains field are used for the specified hosts.

  • To enable direct connections for certain URLs within the domains and subdomains specified in the Proxies for Domains and Subdomains list, specify these URLs in the Do Not Use Web Proxy URLS field.

  With the Use Proxy option disabled:

  • To ensure that proxies are used for certain URLs within the domains and subdomains specified in the Proxies for Domains and Subdomains field, specify these URLs in the Use Webproxy URLs list.

    Although the Use Proxy option is disabled, a proxy is used to connect to the URLs listed under Use Webproxy URLs. The proxies for these URLs are obtained from the Proxies for Domains and Subdomains list.

    The following illustration shows how the web proxy information is resolved based on the proxy configuration in the Gateway service.

    

    In Web Proxy Configuration, if Use Proxy is enabled, and the requested URL is listed in the Do Not Use Webproxy URLs list, the Gateway connects to the destination host directly.

    If Use Proxy is enabled, and the requested URL is not listed in the Do Not Use Webproxy URLs list, the Gateway connects to the destination host through the specified proxy. The proxy, if specified, is looked up in the Proxies for Domains and Subdomains list.

    If Use Proxy is disabled, and the requested URL is listed in the Use Webproxy URLs list, the Gateway connects to the destination host using the proxy information in the Proxies for Domains and Subdomains list.

    If Use Proxy is disabled, and the requested URL is not listed in the Use Webproxy URLs list, the Gateway connects to the destination host directly.

    If none of the above conditions are met, and a direct connection is not possible, the Gateway displays an error saying that connection is not possible.

If you are accessing the URL through the Bookmark channel of the standard Portal Desktop, and none of the above conditions are met, the Gateway sends a redirect to the browser. The browser accesses the URL using its own proxy settings.

Syntax

domainname [web_proxy1:port1]|subdomain1 [web_proxy2:port2]|

Example

sesta.com wp1:8080|red wp2:8080|yellow|* wp3:8080

* is a wild card that matches everything

where,

sesta.com is the domain name and wp1 is the proxy to contact on port 8080.

red is a subdomain and wp2 is the proxy to contact on port 8080.

yellow is a subdomain. Since no proxy is specified, the proxy specified for the domain is used, that is, wp1 on port 8080.

* indicates that for all other subdomains wp3 needs to be used on port 8080.

Port 8080 is used by default if you do not specify a port.

Processing the Web Proxy Information

When a client tries to access a particular URL, the host name in the URL is matched with the entries in the Proxies for Domains and Subdomains list. The entry that matches the longest suffix of the requested host name is considered. For example, suppose that the requested host name is host1.sesta.com. The following searches occur in order until a match is found.

• The Proxies for Domains and Subdomains is scanned for host1.sesta.com. If a matching entry is found, the proxy specified against this entry is used to connect to this host.

• Else, the list is scanned for *.sesta.com. If an entry is found, the corresponding proxy is used.

• Else, the list is searched for sesta.com. If an entry is found, the corresponding proxy is used.

• Else, the list is searched for *.com. If an entry is found, the corresponding proxy is used.

• Else the list is searched for com. If an entry is found, the corresponding proxy is used.

• Else the list is searched for *. If an entry is found, the corresponding proxy is used.

• If no matching centers are found, a direct connection is attempted.

Consider the following entries in the Proxies for Domains and Subdomains list:

com p1| host1 p2 | host2 | * p3
sesta.com p4 | host5 p5 | * p6
florizon.com | host6
abc.sesta.com p8 | host7 p7 | host8 p8 | * p9
host6.florizon.com p10
host9.sesta.com p11
siroe.com | host12 p12 | host13 p13 | host14 | * p14
siroe.com | host15 p15 | host16 | * p16
* p17

The Gateway internally maps these entries into a table as shown in the following table.

Instead of separating the proxy entries in the Proxies for Domains and Subdomains list with the | symbol, you can place individual entries on separate lines in the list. For example, instead of an entry such as:

sesta.com p1 | red p2 | * p3

you can specify this information as:

sesta.com p1
red.sesta.com p2
*.sesta.com p3

This list format makes it easier to track repeated entries or any other ambiguities.

Rewriting Based on the Proxies for Domains and Subdomains List

The entries in the Proxies for Domains and Subdomains list are also used by Rewriter. Rewriter rewrites all URLs whose domains match the domains listed in the Proxies for Domains and Subdomains list.

The * entry in the Proxies for Domains and Subdomains list is not considered for rewriting. For example, entry 24 is not considered.

For information on Rewriter, see Chapter 4, Working with Rewriter .

Default Domain and Subdomain

When the destination host in the URL is not a fully qualified host name, the default domain and subdomain are used to arrive at the fully qualified name.

Assume that the entry in the Default Domains field of the administration console is:

red.sesta.com

You need to have the corresponding entry in the Proxies for Domains and Subdomains list.

In the example above, sesta.com is the default domain and the default subdomain is red.

If the requested URL is host1, this entry is resolved to host1.red.sesta.com using the default domain and subdomain. The Proxies for Domains and Subdomains list is then checked for host1.red.sesta.com.

Using Automatic Proxy Configuration

To ignore the information in the Proxies for Domains and Subdomains list, enable the Automatic Proxy Configuration feature.

When using a Proxy Auto Configuration (PAC) file:

• Portal Server, Gateway, Netlet, and Proxylet use Rhino software to parse the PAC file. You can install the SUNWrhino package from the Java Enterprise System Accessory CD.

  This package contains the js.jar file which must be present in the /usr/share/lib directory. Add this directory to the webserver/appserver class path on the Gateway and Portal Server machine, otherwise the Portal Server, Gateway, Netlet, and Proxylet cannot parse the PAC file.

• The js.jar must be present in the $JRE_HOME/lib/ext directory on the Gateway machine, otherwise the Gateway cannot parse the PAC file.

• The Gateway fetches the PAC file at bootup from the location specified in the gateway profile Automatic Proxy Configuration File location field.

• The Gateway uses the URLConnection API to reach this location. If the proxy needs to be configured to reach the Gateway, the proxy needs to be configured in the following way:

  1. From the command-line, edit the following file:

     /etc/opt/SUNWportal/platform.conf.gateway-profile-name

  2. Add the following entries:

     http.proxyHost=web-proxy-hostname

     http.proxyPort=web-proxy-port

     http.proxySet=true

  3. Restart the Gateway to use the specified proxy:

     ./psadmin start-sra-instance –u amadmin – f <password file> –N <profile name>– t <gateway>

• If PAC file initialization fails, then the Gateway uses the information in the Proxies for Domains and Subdomains list.

• If "" (empty string) or "null" is returned from the PAC file, then the Gateway assumes that the host does not belong to the intranet. This is similar to the host not being in the Proxies for Domains and Subdomains list.

  If you want the Gateway to use a direct connection to the host, return "DIRECT". See Example with Either DIRECT or NULL Return.

• Gateway only uses the first proxy returned when multiple proxies are specified. It does not try to failover or loadbalance among the various proxies specified for a host.

• Gateway ignores SOCKS proxies and attempts a direct connection and assumes that the host is part of the intranet.

• To specify a proxy to be used to reach any host not part of the intranet, use the proxy type STARPROXY. This proxy type is an extension of the PAC file format and is similar to the entry * proxyHost:port in Proxies for Domains and Subdomains section of the gateway profile. See Example with STARPROXY Return

Sample PAC File Usage

The following examples show the URLs listed in the Proxies for Domains and Subdomains list and the corresponding PAC file.

Example with Either DIRECT or NULL Return

If these proxies are used for domains and subdomains:

*intranet1.com proxy.intranet.com:8080

intranet2.com proxy.intranet1.com:8080

the corresponding PAC file is:

// Start of the PAC File
function FindProxyForURL(url, host) {
         if (dnsDomainIs(host, ".intranet1.com")) {
             return "DIRECT";
         }
          if (dnsDomainIs(host, ".intranet2.com")) {
              return "PROXY proxy.intranet1.com:8080";
          }
          return "NULL";
}
//End of the PAC File

Example with STARPROXY Return

If these proxies are used for domains and subdomains:

intranet1.com

intranet2.com.proxy.intranet1.com:8080

internetproxy.intranet1.com:80

the corresponding PAC file is:

// Start of the PAC File
function FindProxyForURL(url, host) {
          if (dnsDomainIs(host, ".intranet1.com")) {
              return "DIRECT";
          }
          if (dnsDomainIs(host, ".intranet2.com")) {
              return "PROXY proxy.intranet1.com:8080;" +
                  "PROXY proxy1.intranet1.com:8080";
          }
          return "STARPROXY internetproxy.intranet1.com:80";
}
//End of the PAC File

In this case, if the request is for a host in .intranet2.com domain, the Gateway contacts proxy.intranet1.com:8080. If proxy.intranet1.com:8080 is down, the request fails. The Gateway does not failover and contacts proxy1.intranet1.com:8080.

Specifying PAC File Location

The format for specifying the location of the PAC file depends upon it’s location as follows:

• If the PAC file resides on a Web server, the PAC URL is:

  http://hostname/pacfile_name.pac

• If the pacfile is a local file (for example, c:\\pacfile\\sample.pac), for Java 1.4.1_x, enter the PAC URL as:

  file://c:/pacfile/sample.pac

• If the PAC file is a local file (for example, c:\\pacfile\\sample.pac), for Java 1.4.2_x, enter the PAC URL as:

  file:///c:/pacfile/sample.pac

Adding Services in Separate Sessions

When you add Portal Server services in separate sessions:

• List Portal Servers under Gateway > Core in the Portal Server administration console.

• List Portal Server URLs in the Non-authenticated URLs under Gateway > Security.

Using a Netlet Proxy

Netlet packets are decrypted at the Gateway and sent to the destination servers. However, the Gateway needs to access all Netlet destination hosts through the firewall between the demilitarized zone (DMZ) and the intranet. This setup requires opening a large number of ports in the firewall. The Netlet proxy can be used to minimize the number of open ports in the firewall.

The Netlet proxy enhances the security between the Gateway and the intranet by extending the secure tunnel from the client, through the Gateway to the Netlet proxy that resides in the intranet. With the proxy, Netlet packets are decrypted by the proxy and then sent to the destination.

The advantages of using Netlet proxy are:

• Adds an additional layer of security.

• Minimizes the use of extra IP addresses and ports from the Gateway through an internal firewall in a significantly sized deployment environment.

• Restricts the number of open ports between the Gateway and the Portal Server to 1. This port number can be configured during installation.

• Extends the secure channel between the client and the Gateway, up to the Portal Server as shown in the "With a Netlet Proxy Configured" section of Using a Netlet Proxy. The Netlet proxy offers improved security benefits through data encryption but may increase the use of system resources. See the Sun Java System Installation Guide for information on installing the Netlet proxy.

You can perform the following tasks:

• Install the Netlet proxy on the Portal Server node or on a separate node.

• Install multiple Netlet proxies and configure them for a single Gateway using the administration console. This is useful in load balancing.

• Configure multiple instances of the Netlet proxy on a single machine.

• Point multiple instances of the Gateway to a single installation of the Netlet proxy.

• Tunnel Netlet through a web proxy.

Shows three sample implementations of the Gateway and the Portal Server with and without a Netlet proxy installed. The components include a client, two firewalls, the Gateway that resides between the two firewalls, Portal Server, and Netlet destination servers.

The first scenario shows the Gateway and Portal Server without a Netlet proxy installed. The data encryption extends only from the client to the Gateway. A port is opened in the second firewall for each Netlet connection request.

The second scenario shows the Gateway and Portal Server with a Netlet proxy installed on Portal Server. The data encryption extends from the client all the way to the Portal Server. Since all Netlet connections are routed through a Netlet proxy, only one port needs to be opened in the second firewall for Netlet requests.

The third scenario shows the Gateway and the Portal Server with a Netlet proxy installed on a separate node. Installing a Netlet proxy on a separate node reduces the load on the Portal Server node. Again, only two ports need to be opened in the second firewall. One port services requests to the Portal Server, and the other port routes Netlet requests to the Netlet proxy server.

Figure 2–1 Implementation of Netlet Proxy

Enabling a Netlet Proxy

You enable a Netlet proxy through the Gateway service using the Portal Server administration console.

Restarting a Netlet Proxy

You can configure a Netlet proxy to restart whenever the proxy is killed accidentally. You can schedule a watchdog process to monitor a Netlet proxy and restart it if it goes down.

You can also restart a Netlet proxy manually. See To Restart a Netlet Proxy for steps.

To Configure a Netlet Proxy Watchdog

You can configure the time interval at which the watchdog monitors the status of a Netlet proxy. This time interval is set to 60 seconds by default. To change this interval, add the following line to the crontab file:

0-59 * * * * netlet-install-dir/bin/checkgw /var/opt/SUNWportal/.gw 5 > /dev/null 2>&1

To start or to stop the watchdog, run the command;./psadmin sra-watchdog -u amadmin -f <password-file> -t <type> on|off.

Using a Rewriter Proxy

The Rewriter proxy is installed in the intranet. Instead of trying to retrieve the contents directly, the Gateway forwards all requests to the Rewriter proxy which fetches and returns the contents to the Gateway.

The advantages of using a Rewriter proxy are:

• If a firewall exists between the Gateway and server, the firewall needs to open only two ports - one between the Gateway and Rewriter proxy, and another between the Gateway and the Portal Server.

• HTTP traffic is secure between the Gateway and the intranet even if the destination server only supports the HTTP protocol and not HTTPS.

If you do not specify a Rewriter proxy, the Gateway component makes a direct connection to intranet computers when a user tries to access one.

If you are using the Rewriter proxy as a load balancer, be sure that the platform.conf.instance_name for Rewriter points to the load balancer URL. Also specify the load balancer host in the Portal Servers list.

If you have multiple instances of Rewriter proxies for each Gateway instance, which are not necessarily on the portal node, provide the details for each Rewriter proxy in the form of host-name:port in the platform.conf file, rather than a single port entry for the Rewrite proxy.

Creating Instances of a Rewriter Proxy

Use the rwpmultiinstance script to create a new instance of a Rewriter proxy on the Portal Server node. Run this script after the gateway profile has been created.

See To Create a Rewriter Proxy Instance.

Enabling a Rewriter Proxy

Enable a Rewriter proxy through the Gateway service under SRA Configuration in the Access Manager administration console.

Restarting a Rewriter Proxy

You can configure to restart Rewriter proxy whenever the proxy is killed accidentally. You can schedule a watchdog process to monitor and restart it if this happens.

You can also restart a Rewriter proxy manually.

See To Restart a Rewriter Proxy.

Configuring a Rewriter Proxy Watchdog

You can configure the time interval at which the watchdog monitors the status of the Rewriter proxy. This time interval is set to 60 seconds by default. To to change the time interval, add the following line in the crontab file:

0-59 * * * * rewriter-proxy-install-root/bin/checkgw /var/opt/SUNWportal/.gw 5 > /dev/null 2>&1

To start or to stop the watchdog, run the command;./psadmin sra-watchdog -u amadmin -f <password-file> -t <type> on|off.

Using a Reverse Proxy with the Gateway

A proxy server serves Internet content to the intranet, while a reverse proxy serves intranet content to the Internet. You can configure deployments of reverse proxies to achieve load balancing and caching.

If the deployment has a third-party reverse proxy in front of the Gateway, the response has to be rewritten with the reverse proxy's URL instead of the Gateway's URL. For this, the following configurations are needed.

See To Enable a Reverse Proxy.

Obtaining Client Information

When the Gateway forwards a client request to any internal server, it adds HTTP headers to the HTTP request. You can use these headers to obtain additional client information and detect the presence of the Gateway.

To view the HTTP request headers, set the entry in the platform.conf file to gateway.error=message. And, then use the request.getHeader() from the servlet API. The following table lists the information in the HTTP headers.

Using Authentication Chaining

Authentication chaining provides a higher level of security than the regular mechanism of authentication. You can enable users to be authenticated against more than one authentication mechanism.

The procedure described in this is only for enabling authentication chaining along with a Personal Digital Certificate (PDC) authentication at the Gateway. For information on authentication chaining without PDC authentication at the Gateway, see the Access Manager Administration Guide.

For example, if you chain the PDC and Radius authentication modules, the user will have to authenticate against all three modules to access the standard Portal Desktop.

See To Add Authentication Modules to an Existing PDC Instance for steps.

When enabled, PDC is always the first authentication module to be presented to the user.

Using Wild Card Certificates

A wild card certificate accepts a single certificate with a wild card character in the fully-qualified DNS name of the host.

With the certificate multiple hosts within the same domain are secured. For example, a certificate for *.domain.com can be used for abc.domain.com, and abc1.domain.com. This certificate is valid for any host in the domain.com domain.

Disabling Browser Caching

Because the Gateway component provides secure access to back end corporate data from any location using just a web browser, the information should not be cached locally by the client.

You can disable caching of pages redirected through the Gateway by modifying the attribute in the platform.conf file of the specific Gateway.

Disabling this option can have an impact on the Gateway performance. Every time the standard Portal Desktop is refreshed, the Gateway has to retrieve everything referenced by the page, such as images that might have been previously cached by the browser. However, enabling this feature, means that remotely accessing secure content will not leave a cached footprint on the client site. This factor could outweigh performance implications if the corporate network is being accessed from an Internet cafe or similar remote location that is not under corporate IT control.

See To Disable Browser Caching.

Customizing the Gateway Service User Interface

This section discusses the various Gateway property files that can be edited.

Modifying the srapGateway.properties File

You can edit this file for the following purposes:

• Customize the error messages that might appear when the Gateway is running.

  • HTML-CharSets=ISO-8859-1 specifies the character set that was used to create this file.

  • The number in braces (for example, {0}) indicates that the value displayed at run time. You can change the label associated with this number, or rearrange the labels as required. Ensure that the label corresponds to the message that to be displayed since the number and the message are associated.

  Customize the log information.

  By default the srapGateway.properties file is located under the portal-server-install-root/SUNWportal/locale directory. All messages that appear on the Gateway machine are located in this file, irrespective of the language of the messages.

  To change the language of the messages that appear on the client standard Portal Desktop, copy this file into the respective locale directory, for example portal-server-install-root/SUNWportal/locale_en_US.

Modifying the srapgwadminmsg.properties File

You can edit this file for the following reasons:

• Customize the labels that appear on buttons for the Gateway service on the administration console.

• Customize the status messages and error messages that appear when you are configuring the Gateway.

Sharing LDAP Directories

When two instances of Portal Server and Access Manager servers share the same LDAP directories, it shares the same LDAP directories for all subsequent instances of Portal Servers, Access Managers, and Gateways. See To Share LDAP Directories.