Sun Java System Portal Server Secure Remote Access 7.1 Administration Guide

Chapter 2 Working with Gateway

This chapter describes Gateway related concepts and information to manage the Gateway. For information on configuring the Gateway, see Chapter 9, Configuring the Gateway.

This chapter covers the following topics:

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

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.

You can:


Caution – Caution –

Do not assign the same profile to different instances of the Gateway running on the same machine. This causes a conflict because the port numbers would be 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.


ProcedureTo Create a Gateway Profile

  1. Log into the Portal Server administration console as administrator.

  2. Click the Secure Remote Access tab and click New Profile.

    The New Profile page is displayed.

  3. Enter the name of the new gateway profile.

  4. Select the profile to use for creating the new profile from the drop-down list.

    By default, any new profile that you create is based on the pre-packaged Default profile. If you have created a custom profile, you can select that profile from the drop-down list. The new profile inherits all the attributes of the selected profile.

    The existing profile that is copied for the new one, copies the same port. Change the port for the new profile so that it does not conflict with the existing one.

  5. Click OK.

    The new profile is created and listed in the Profiles page.


    Caution – Caution –

    Ensure that you change the port of the instance so that it does not clash with any existing port in use.


  6. Telnet to the machine where the instance needs to be created. The default gateway instance is up and running at this machine.

  7. Copy the /opt/SUNWportal/template/sra/GWConfig.properties.template file to a temporary location . For example, /tmp.

  8. Modify the values as required.


    Note –

    The values should match the port numbers in the gateway instance for the new profile.


  9. Once complete, run the following command:

    ./psadmin create-sra-instance -u amadmin -f <passwordfile> -S <template file location>.template -t gateway

  10. Restart the Gateway with this gateway profile name to ensure the changes to take effect:

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

    For more information on starting and stopping the Gateway, see Starting and Stopping the Gateway Instance. To configure the Gateway, see Chapter 9, Configuring the Gateway

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.

Here is a sample:


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

Understanding the platform.conf File lists and describes all the fields in the platform.conf file.

Table 2–1 platform.conf File Properties

Entry 

Default Value 

Description 

gateway.user

noaccess 

The Gateway runs as this user. 

The Gateway must be started as root and after initialization, it loses its root privileges to become this user. 

gateway.jdk.dir

 

This is the location of the JDK directory that the Gateway uses. 

gateway.dsame.agent

 

This is the URL of the Access Manager that the Gateway contacts while starting up to get its profile. 

portal.server.protocol

portal.server.host

portal.server.port

 

This is the protocol, host and port that the default Portal Server installation is using. 

gateway.protocolgateway. hostgateway.port

 

This is the Gateway protocol, host and port. These values are the same as the mode and port that you specified during installation. These values are used to construct the notification URL. 

gateway. trust_all_server_certs

true 

This indicates whether the Gateway has to trust all server certificates, or only those that are in the Gateway certificate database. 

gateway. trust_all_server_cert_domains

false 

When an SSL communication is between the Gateway and a server, a server certificate is presented to the Gateway. By default, the Gateway checks if the server host name is the same as the server certificate CN. 

If this attribute value is set to true, the Gateway disables the domain check for the server certificate that it receives. 

gateway.virtualhost

 

If the Gateway machines has multiple hostnames configured, you can specify a different name and identity provider address in this field. 

gateway.virtualhost. defaultOrg=org

 

This specifies the default Org to which the user logs into. 

For example, suppose the virtual host field entries are the following: 

gateway.virtualhost=test.com employee.test.com

Managers.test.com

with the default org entries as: 

test.com.defaultOrg = o=root,dc=test,dc=com

employee.test.com.defaultOrg = o=employee,dc=test,dc=com

Manager.test.com.defaultOrg = o=Manager,dc=test,dc=com

The user can use https://manager.test.com to log into the manager's org instead of https://test.com/o=Manager,dc=test,dc=com


Note –

virtualhost and defaultOrg are case sensitive in the platform.conf file, but not when using it in the URL.


gateway.notification.url

 

A combination of the Gateway host, protocol and port is used to construct the notification URL. This is used to receive session notification from the Access Manager. 

Ensure that the notification URL is not the same as any organization name. If the notification URL matches an organization name, a user trying to connect to that organization gets a blank page instead of the login page. 

gateway.retries

 

This is the number of times that the Gateway tries to contact the Portal Server while starting up. 

gateway.debug

error

This sets the debug level of the Gateway. The debug log file is located at debug-directory/files. The debug file location is specified in the gateway.debug.dir entry.

The debug levels are: 

  • error - Only serious errors are logged in the debug file. The Gateway usually stops functioning when such errors occur.

  • warning - Warning messages are logged.

  • message - All debug messages are logged.

  • on - All debug messages are displayed on the console.

The debug files are: 

srapGateway.gateway-profile-name - Contains the Gateway debug messages.

Gateway_to_from_server.gateway-profile-name - In message mode, this file contains all the requests and response headers between the Gateway and internal servers.

To generate this file, change the write permission on /var/opt/SUNWportal/debug directory.

Gateway_to_from_browser.gateway-profile-name - In message mode, this file contains all the requests and response headers between the Gateway and the client browser.

To generate this file, change the write permission on /var/opt/SUNWportal/debug directory.

gateway.debug.dir

 

This is the directory where all the debug files are generated. 

This directory should have sufficient permissions for the user mentioned in gateway.user to write to files.

gateway.logdelimiter

 

Not used currently. 

gateway.external.ip

 

In case of a multi-homed Gateway machine (one with multiple IP addresses), you need to specify the external IP address here. This IP is used for Netlet to run FTP. 

gateway.certdir

 

This specifies the location of the certificate database. 

gateway.allow.client.caching

true 

Allow or disallow client caching. 

If allowed, client browsers can cache static pages and images for better performance (by reduced network traffic). 

If disallowed, nothing is cached and security is higher but performance drops with the higher network load. 

gateway.userProfile.cacheSize

 

This is the number of user profile entries that get cached at the Gateway. If the number of entries exceeds this value, frequent retries occur to cleanup the cache. 

gateway.userProfile. cacheSleepTime

 

Sets the sleep time, in seconds, for the cache cleanup. 

gateway.userProfile. cacheCleanupTime

 

The maximum time in seconds after which a profile entry can get removed. 

gateway.bindipaddress

 

On a multihomed machine, this is the IP address to which the Gateway binds its serversocket. To configure the Gateway to listen to all interfaces, replace the IP address so that the gateway.bindipaddress=0.0.0.0

gateway.sockretries

Not used currently. 

gateway.enable.accelerator

false 

If set to true external accelerator support is allowed. 

gateway.enable.customurl

false 

If set to true the administrator is allowed to specify a custom URL for the Gateway to rewrite pages to. 

gateway.httpurl

 

The HTTP reverse proxy URL for a custom URL for the Gateway to rewrite pages to. When Proxylet is enabled use this entry. 

gateway.httpsurl

 

The HTTPS reverse proxy URL for a custom URL for the Gateway to rewrite pages to. Do not use this entry if Proxylet is enabled. 

gateway.favicon

 

The URL to which the Gateway redirects requests for the favicon.icon file.

This is used for the "favorite icon" in Internet Explore and Netscape 7.0 and higher. 

If left empty, the Gateway sends a 404 not found message back to browser. 

gateway.logging.password

 

The LDAP password of the user amService-srapGateway that gateway uses for creating its application session.

This can be either encrypted or in plain text. 

http.proxyHost

 

This proxy host is used to contact the Portal Server. 

http.proxyPort

 

This is the port for the host used to contact Portal Server. 

http.proxySet

 

This property is set to true if a proxy host is required. If the property is set to false, http.proxyHost and http.proxyPort are ignored.

portal.server.instance

 

The value of this property is the corresponding /etc/opt/SUNWam/config/AMConfig-instance-name.properties file. If the value is default, then it points to AMConfig.properties.

gateway.cdm.cacheSleepTime

60000 

The time out value for cache Client Detection Module responses sent to the Gateway from the Access Manager. 

gateway.cdm.cacheCleanupTime

300000 

The time out value for cache Client Detection Module responses sent to the Gateway from the Access Manager. 

netletproxy.port

10555 

The Netlet Proxy deamon listens for requests on this port. 

rewriterproxy.port

10555 

The Rewriter Proxy deamon listens for requests on this port. 

gateway.ignoreServerList

false 

If set to true, the Access Manager server URL is constructed using the values specified in the AMConfig.properties file. Set this property to true when the Access Manager server is behind a load balancer.

rewriterproxy.accept.from.gateways

 

This is a list of IP addresses from which the Rewriter Proxy can be made to accept requests from. This works in HTTP and HTTPS modes both. This is for added security, only requests coming from this set is accepted and all other requests are not handled. This can be comma separated IP addresses. Default value is empty which is treated as legacy mode, i.e all requests coming to Rewriter Proxy are honored. 

rewriterproxy.checkacl=

false 

With this property enabled Rewriter Proxy can be made to check ACL values just like the Gateway. The legacy mode value is "false". When set to true, the Rewriter Proxy will check the URL against the values specified in the gateway access service, at the given DN and will allow/deny requests as per the list set there. This value is useful both in HTTP and HTTPS modes. 

Creating Multiple Instances of a Gateway

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

Creating Multi-homed Gateway Instances

If you are creating multi-homed gateway instances, that is multiple gateways on one Portal Server, you must 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:

ProcedureTo Create Gateway Instances Using the Same LDAP

  1. Replace the key that is used to encrypt and decrypt passwords with the same string used for the first Gateway.

    am.encryption.pwd= string_key_specified_in gateway-install

  2. Replace the key that is the shared secret for application authentication module:

    com.iplanet.am.service.secret= string_key_specified_in gateway-install

  3. In /etc/opt/SUNWam/config/ums modify the following areas in serverconfig.xml to be consistent with the first installed instance of Portal Server:

    <DirDN> cn=puser,ou=DSAME Users,dc=sun,dc=net</DirDN>

    <DirPassword>string_key_specified_in gateway-install</DirPassword>

    <DirDN>cn=dsameuser,ou=DSAME Users,dc=sun,dc=net</DirDN>

    <DirPassword>string_key_specified_in gateway-install </DirPassword>

  4. Restart Access Manager services.

Starting and Stopping the Gateway Instance

By default, the Gateway starts as user noaccess.

ProcedureTo Start the Gateway Instances

  1. After installing the Gateway and creating the required profile, run the following command to start the Gateway:

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

    default — is the default gateway profile that is created during installation. You can create your own profiles later, and restart the Gateway with the new profile. See Creating a Gateway Profile.


    Note –

    Replace the <profile name> with an appropriate profile name to start other instances of the Gateway.

    Restarting the server (the machine on which the Gateway instances are configured) restarts all instances of the Gateway.

    Ensure that no backed up profiles are present in the /etc/opt/SUNWportal directory.


  2. Run the following command to check if the Gateway is running on the specified port:

    netstat -an | grep port-number

    The default Gateway port is 443.

ProcedureTo Stop the Gateway

  1. Use the following command to stop the Gateway:

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


    Note –

    Replace the <profile name> with an appropriate profile name to start other instances of the Gateway.


  2. Run the following command to verify if any of the Gateway processes are still running:

    /usr/bin/ps -ef | grep entsys

ProcedureTo Start and Stop Gateway Using Management Console

  1. Log In to the Portal Server management console

  2. Select the Secure Remote Access tab.

  3. Click the Manage Instances submenu.

  4. Under SRA Proxy instances, select an instance.

    • Click Start to start an instance.

    • Click Stop to stop an instance.

Restarting the Gateway

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

ProcedureTo Restart the Gateway with a Different Profile

  1. Restart the Gateway:

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

ProcedureTo Restart the Gateway

  1. In a terminal window, connect as root and do one of the following:

    • Start the watchdog process:


      ./psadmin sra-watchdog -u uid -f password-filename -t instance-type on

      [--adminuser | -u] uid

      Specifies the administrator's distinguished name (DN) or user ID. 

      [-passwordfile | -f] password-filename

      Specifies the administrator's password in the password file. 

      [--type | -t] instance-type

      Specifies the type of the Secure Remote Access instance. Enter: gateway, nlproxy, or rwproxy. 

      For information on watchdog command, see the Sun Java System Portal Server Command Line Reference Guide.

      This creates an entry in the crontab utility and the watchdog process is now active. The watchdog monitors all running instances of a Gateway on a particular machine and Gateway port and restarts the Gateway if it goes down.

To Configure the Gateway Watchdog

You can configure the time interval at which the watchdog monitors the status of the Gateway. This time interval is set to 60 seconds by default. To change this, 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 hostname that points to the same machine IP and a host name. For example, if a host name a.b.c points to the host IP address 192.155.205.133, you can add another host name c.d.e which points to the same IP address.

ProcedureTo Specify a Virtual Host

  1. Login as root and edit the platform.conffile of the required Gateway instance:


    /etc/opt/SUNWportal/platform.conf.gateway-profile-name
    
  2. Add the following entries:

    gateway.virtualhost=fully-qualified-gateway-host gateway-ip-address fully- qualified-reverse-proxyhost

    gateway.enable.customurl=true (This value is set to false by default.)

  3. Restart the Gateway:

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

    If these values are not specified, the Gateway defaults to normal behavior.

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.

ProcedureTo Specify a Proxy

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


    /etc/opt/SUNWportal/platform.conf.gateway-profile-name
    
  2. Add the following entries:


    http.proxyHost=proxy-host
    http.proxyPort=proxy-port
    http.proxySet=true
  3. Restart the Gateway to use the specified proxy for requests made to the server:

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

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:


Note –

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.


Note –

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, consider that the requested host name is host1.sesta.com

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 Processing the Web Proxy Information.

Table 2–2 Mapping of Entries in the Proxies for Domains and Subdomains List

Number 

Entry in Proxies for Domains and Subdomains List 

Proxy 

Description 

com 

p1 

As specified in the list. 

host1.com 

p2 

As specified in the list. 

host2.com 

p1 

The proxy for the domain is used as no proxy is specified against host2. 

*.com 

p3 

As specified in the list. 

sesta.com 

p4 

As specified in the list. 

host5.sesta.com 

p5 

As specified in the list. 

*.sesta.com 

p6 

As specified in the list. 

florizon.com 

Direct 

See the description for entry 14 for details. 

host6.florizon.com 

– 

See the description for entry 14 for details. 

10 

abc.sesta.com 

p8 

As specified in the list. 

11 

host7.abc.sesta.com 

p7 

As specified in the list. 

12 

host8.abc.sesta.com 

p8 

As specified in the list. 

13 

*.abc.sesta.com 

p9 

As specified in the list. For all hosts other than host7 and host8 under the abc.sesta.com domain, p9 is used as the proxy.

14 

host6.florizon.com 

p10 

This entry is the same as entry 9. Entry 9 indicates a direct connection, whereas this entry indicates that proxy p10 should be used. In a case with two entries such as this, the entry with the proxy information is considered as the valid entry. The other entry is ignored. 

15 

host9.sesta.com 

p11 

As specified in the list. 

16 

siroe.com 

Direct 

A direct connection is attempted because no proxy is specified for siroe.com, .

17 

host12.siroe.com 

p12 

As specified in the list. 

18 

host13.siroe.com 

p13 

As specified in the list. 

19 

host14.siroe.com 

Direct 

A direct connection is attempted because no proxy is specified for host14.

20 

*.siroe.com 

p14 

See the description for entry 23. 

21 

host15.siroe.com 

p15 

As specified in the list. 

22 

host16.siroe.com 

Direct 

A direct connection is attempted because no proxy is specified for host16 or siroe.com.

23 

*.siroe.com 

p16 

Similar to entry 20. But the proxies specified are different. In such a case, the exact behavior of the Gateway is not known. Either of the two proxies may be used. 

24 

p17 

If no other entry matches the requested URL, p17 is used as the proxy.


Note –

Instead of separating the proxy entries in the Proxies for Domains and Subdomains list with the | symbol, it may be simpler to have individual entries in the list. For example, instead of an entry such as:


sesta.com p1 | red p2 | * p3

you can specify it as:


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

This makes it easier to trap 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.


Caution – Caution –

The * entry in the Proxies for Domains and Subdomains list is not considered for rewriting. For example, in the sample provided in Processing the Web Proxy Information, entry 24 is not considered.


For information on Rewriter, see Chapter 3, Working with Proxylet and 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

Note –

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 is resolved to host1.red.sesta.com using the default domain and subdomain. The Proxies for Domains and Subdomains list is then looked up 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.

Please note the following when using a Proxy Auto Configuration (PAC) file:

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

Using these proxies 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

Using these proxies 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:

Adding Services in Separate Sessions

When you add Portal Server services in separate sessions, ensure that:

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 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:

You can:

Using a Netlet 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. Here 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. In this case, 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. Here 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

Implementation of Netlet Proxy

Creating Instances of a Netlet Proxy

ProcedureTo create a Netlet Proxy instance

  1. Telnet to the machine where the instance needs to be created. The default gateway instance is up and running at this machine.

  2. Copy the /opt/SUNWportal/template/sra/NLPConfig.properties.template file to a temporary location . For example, /tmp.

  3. Modify the values as required in the file for the new profile.

  4. Once complete, run the following command:

    ./psadmin create-sra-instance -u amadmin -f <passwordfile> -S <template file location>.template -t nlproxy

  5. Start the new instance of the Netlet proxy with the required gateway profile name to ensure that the changes take effect:

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

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.

ProcedureTo Restart a Netlet Proxy

  1. In a terminal window, connect as root and do one of the following:

    • Start the watchdog process:

      psadmin sra-watchdog -u uid -f password-filename -t instance-type on

      Enter nlproxy in place of the instance-type. For more information on this command, see the Sun Java Portal Server Command Line Reference Guide.

      This creates an entry in the crontab utility and the watchdog process is now active. The watchdog monitors the Netlet proxy port and brings up the proxy if it goes down.

    • Start a Netlet proxy manually:

      psadmin start-sra-instance -u uid -f password-filename -N sra-instance-name -t instance-type

      Enter nlproxy in place of the instance-type. This the profile name corresponding to the required Netlet Proxy instance. For more information on this command, see the Sun Java Portal Server Command Line Reference Guide.

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 do this, edit the following line in the crontab utility:

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

Using a Rewriter Proxy

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

The advantages of using a Rewriter proxy are:

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 of those intranet computers.

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 ensure that the load balancer host is specified in the Portal Servers list.

If you have multiple instances of Rewriter proxies for each Gateway instance (not necessarily on the portal node), enter 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.

ProcedureTo Create a Rewriter Proxy Instance

  1. Telnet to the machine where the instance needs to be created. The default gateway instance is up and running at this machine.

  2. Copy the /opt/SUNWportal/template/sra/GWConfig.properties.template file to a temporary location . For example, /tmp.

  3. Modify the values as required in the file for the new profile.

  4. Once complete, run the following command:

    ./psadmin create-sra-instance -u amadmin -f <passwordfile> -S <template file location>.template -t rwproxy

  5. Start the new instance of the Rewirter Proxy with the required gateway profile name to ensure that the changes take effect:

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

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.

ProcedureTo Restart a Rewriter Proxy

  1. In a terminal window, connect as root and do one of the following:

    • Start the watchdog process:

      psadmin sra-watchdog -u uid -f password-filename -t instance-type on

      Enter rwproxy in place of the instance-type. For more information on this command, see the Sun Java Portal Server Command Line Reference Guide.

      This creates an entry in the crontab utility and the watchdog process is now active. The watchdog monitors the Rewriter Proxy port and brings up the proxy if it goes down.

    • Start a Rewriter Proxy manually:

      start-sra-instance -u uid -f password-filename -N sra-instance-name -t instance-type

      Enter rwproxy in place of the instance-type. This the profile name corresponding to the required Rewritter Proxy instance. For more information on this command, see the Sun Java Portal Server Command Line Reference Guide.

To Configure 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 do this, edit the following line in the crontab utility:

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

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. Deployments of reverse proxies can be configured to serve the Internet content 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.

ProcedureTo Enable a Reverse Proxy

  1. Log in as root and edit the platform.conf file of the required Gateway instance:

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

  2. Add the following entries:

    gateway.virtualhost=fully-qualified-gateway-host gateway-ip-address fully- qualified-reverse-proxyhost

    gateway.enable.customurl=true (This value is set to false by default.)

    gateway.httpurl=http reverse-proxy-URL

    gateway.httpsurl=https reverse-proxy-URL

    gateway.httpurl is used to rewrite the response for the request received at the port which is listed as HTTP port in the gateway profile.

    gateway.httpsurl is used to rewrite the response for the request received at the port which is listed as HTTPS port in the gateway profile.

  3. Restart the Gateway:

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

    If these values are not specified, the Gateway defaults to normal behavior.

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, then use the request.getHeader() from the servlet API. The following table lists the information in the HTTP headers.

Table 2–3 Information in HTTP Headers

Header 

Syntax 

Description 

PS-GW-PDC 

X-PS-GW- PDC: true/false

Indicates whether PDC is enabled at the Gateway. 

PS-Netlet 

X-PS-Netlet:enabled=true/false

Indicates whether Netlet has been enabled or disabled at the Gateway. 

If Netlet is enabled, then the encryption option is populated, indicating whether the Gateway is running in HTTPS (encryption=ssl) or in HTTP mode (encryption=plain)

For example: 

  • PS-Netlet: enabled=false

    Netlet is disabled.

  • PS-Netlet: enabled=true; encryption=ssl

    Netlet is enabled with the Gateway running in SSL mode.

    The encryption=ssl or encryption=plainis not populated when Netlet is not enabled.

PS-GW-URL 

X-PS-GW-URL: http(s)://gatewayURL(:port)

Indicates the URL that the client is connected to. 

When the port is non-standard (Gateway is in HTTP/HTTPS mode with the port not being 80/443), then the :port is also populated.

PS-GW-Rewriting-URL 

X-PS-GW-URL: http(s)://gatewayURL(:port)/[SessionInfo]

Indicates the URL that the Gateway rewrites all the pages to. 

  1. When the browser supports cookies, the value of this header is the same as the PS-GW-URL header.

  2. When the browser does not support cookies:

    • the destination host is in the "User Session to which User Session Cookie is Forwarded" field, the value is the actual URL to which the Gateway rewrites the page to (including the encoded SessionID information).

    • the destination host is not in the User Session to which User Session Cookie is Forwarded field, then the SessionInfo string is $SessionID


      Note –

      As part of the response, if the user's Access Manager sessionId changes (like response from authentication page) then the pages are rewritten with that value (and not the value that was previously indicated in the header).


      For example:

    • If the browser supports cookies:

PS-GW-Rewriting-URL: https://siroe.india.sun.com:10443/ 

  • If the browser does not support cookies and the endserver is in the User Session to which User Session Cookie is Forwarded field.

PS-GW-Rewriting-URL: https://siroe.india.sun.com:10443/SessIDValCustomEncodedValue/ 

  • If the browser does not support cookies and endserver is not in User Session to which User Session Cookie is Forwarded field.

PS-GW-Rewriting-URL: https://siroe.india.sun.com:10443/$SessionID 

PS-GW-CLientIP 

X-PS-GW-CLientIP: IP

Indicates the IP that the Gateway obtained from recievedSocket.getInetAddress().getHostAddress()

This provides the client's IP if directly connected to the Gateway. 

Using Authentication Chaining

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

The procedure described here 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.


Note –

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


ProcedureTo Add Authentication Modules to an Existing PDC Instance

  1. Login to the Access Manager administration console as administrator.

  2. Select the required organization.

  3. Select Services from the View drop-down box.

    The services are displayed.

  4. Click Authentication Configuration.

    The Service Instance List is displayed.

  5. Click Gatewaypdc.

    The Gatewaypdc properties page is displayed.

  6. Click Edit.

    The Add Module page is displayed.

  7. Select Module Name and set Flag to Required.

  8. Click OK.

  9. Click Save after adding one or more modules.

  10. Click Save in the gatewaypdc properties page.

  11. Restart the Gateway for the changes to take effect:

    gateway-install-location/SUNWportal/bin/psadmin start-sra-instance –u amadmin – f <password file> –N <profile name>– t <gateway>

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

As the Gateway component provides secure access to back end corporate data from any location using just a web browser, it may be necessary that the information 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 which may have been previously cached by the browser. However, by enabling this feature, remotely accessing secure content will not leave a cached footprint on the client site. This 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.

ProcedureTo Disable Browser Caching

  1. Login as root and edit the platform.conf file of the required Gateway instance:


    /etc/opt/SUNWportal/platform.conf.gateway-profile-name
    
  2. Edit the following line:


    gateway.allow.client.caching=true

    This value is set to true by default. Change the value to false to disable browser caching at the client side.

  3. Restart the Gateway:

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

Customizing the Gateway Service User Interface

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

Modifying the srapGateway.properties File

You can edit this file for the following purposes:

Modifying the srapgwadminmsg.properties File

You can edit this file for the following reasons:

Sharing LDAP Directories

When two instances of Portal Server and Access Manager servers share the same LDAP directories, please use this workaround for all subsequent Portal Server, Access Manager, and Gateways:

ProcedureTo Share LDAP Directories

  1. Modify the following areas in AMConfig.properties to synchronize with the first installed instance of Portal Server and Access Manager servers:

    # The key that will be used to encrypt and decrypt passwords. am.encryption.pwd=t/vnY9Uqjf12NbFywKuAaaHibwlDFNLO <== REPLACE THIS STRING WITH THE ONE FROM FIRST PORTAL INSTALL

    /* The following key is the shared secret for application auth module */ com.iplanet.am.service.secret=AQICxIPLNc0WWQRVlYZN0PnKgyvq3gTU8JA9 <== REPLACE THIS STRING WITH THE ONE FROM FIRST PORTAL INSTALL

  2. In /etc/opt/SUNWam/config/ums modify the following areas in serverconfig.xml to be insync with the first installed instance of Portal Server and Access Manager server:


    <DirDN>
        cn=puser,ou=DSAME Users,dc=sun,dc=net
    </DirDN>
        <DirPassword>
             AQICxIPLNc0WWQT22gQnGgnCp9rUf+FuaqpY 
             <==  REPLACE THIS STRING WITH THE ONE FROM FIRST PORTAL INSTALL
      </DirPassword>
    
    <DirDN>
       cn=dsameuser,ou=DSAME Users,dc=sun,dc=net
    </DirDN>
         <DirPassword>
              AQICxIPLNc0WWQT22gQnGgnCp9rUf+FuaqpY 
              <==  REPLACE THIS STRING WITH THE ONE FROM FIRST PORTAL INSTALL
         </DirPassword>
  3. Restart the Access Manager services.

Using Federation Management

Federation Management enables users to aggregate their local identities so that they have one network identity. Federation Management uses the network identity to allow users to login at one service provider’s site and access other service provider’s sites without having to re-authenticate their identity. This is referred to as single sign-on.

Federation management can be configured in open mode and secure mode on the Portal Server. The Portal Server Administration Guide describes how to configure federation management in open mode. Before configuring Federation management in secure mode, using Portal Server Secure Remote Access, ensure that it works in open mode. If you want your users to use Federation Management from the same browser in both open and secure mode, they must clear the cookies and cache from the browser.

For detailed information on Federation Management, see the Access Manager Federation Management Guide.

Federation Management Scenario

A user authenticates to an initial service provider. Service providers are commercial or not-for-profit organizations that offer web-based services. This broad category can include internet portals, retailers, transportation providers, financial institutions, entertainment companies, libraries, universities, and governmental agencies.

The service provider uses a cookie to store the user’s session information in the client browser. The cookie also includes the user’s identity provider.

Identity providers are service providers that specialize in providing authentication services. As the administrating service for authentication, they also maintain and manage identity information. Authentication accomplished by an identity provider is honored by all service providers with whom they are affiliated.

When the user attempts to access a service that is not affiliated with the identity provider, the identity provider forwards the cookie to the unaffiliated service provider. This service provider can then access the identity provider called out in the cookie.

However, cookies cannot be read across different DNS domains. Therefore a Common Domain Cookie Service is used to redirect the service provider to the correct identity provider thus enabling single sign-on for the user.

Configuring Federation Management Resources

The Federation resources, the service providers, identity providers, and the Common Domain Cookie Service (CDCS), are configured in the gateway profile based on where they reside. This section describes how to configure three scenarios:

ProcedureTo Configure Federation Management Resources

  1. When all resources are inside the corporate intranet

  2. When all resources are not inside the corporate intranet or the identity provider resides in the Internet

  3. When all resources are not inside the corporate intranet or the service provider is a third party residing in the Internet while the identity provider is protected by the Gateway.

Configuration 1

In this configuration the service providers, identity providers and the Common Domain Cookie Service are deployed in the same corporate intranet and the identity providers are not published in the Internet Domain Name Server (DNS). The CDCS is optional.

In this configuration the Gateway points to the service provider, which is the Portal Server. This configuration is valid for multiple instances of the Portal Server.

ProcedureTo Configure Gateway to a Service Provider (Portal Server)

  1. Log into the Portal Server administration console as administrator.

  2. Select the Secure Remote Access tab and select the appropriate gateway profile to modify its attributes.

    The Edit Gateway Profile page is displayed.

  3. Select the Core tab.

  4. Select the Enable Cookie Management checkbox to enable cookie management.

  5. Select the Security tab.

  6. In the Portal Servers field, enter Portal Server names to use the relative URLs such as: /amserver or /portal/dt listed in the Non-Authenticated URLs list. For example:

    http://idp-host:port/amserver/js

    http://idp-host:port/amserver/UI/Login

    http://idp-host:port/amserver/css

    http://idp-host:port/amserver/SingleSignOnService

    http://idp-host:port/amserver/UI/blank

    http://idp-host:port/amserver/postLogin

    http://idp-host:port/amserver/login_images

  7. In the Portal Servers field, enter the Portal Server name. For example, /amserver.

  8. Click Save.

  9. Select the Security tab.

  10. In the Non-Authenticated URLs list, add the federation resources. For example:

    /amserver/config/federation

    /amserver/IntersiteTransferService

    /amserver/AssertionConsumerservice

    /amserver/fed_images

    /amserver/preLogin

    /portal/dt

  11. Click Add.

  12. Click Save.

  13. If web proxies are needed to reach the URLs listed in the Non-authenticated URLs list, select the Deployment tab.

  14. In the Proxies for Domains and Subdomains field, enter the necessary web proxies.

  15. Click Add.

  16. Click Save.

  17. From a terminal window, restart the Gateway:

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

Configuration 2

In this configuration the identity providers, identity providers and the Common Domain Cookie Provider (CDCP) are not deployed in the corporate intranet or the identity provider is a third party provider residing the in Internet.

In this configuration the Gateway points to the service provider, which is the Portal Server. This configuration is valid for multiple instances of the Portal Server.

ProcedureTo Configure Gateway to a Service Provider (Portal Server)

  1. Log into the Portal Server administration console as administrator.

  2. Select the Secure Remote Access tab and select the appropriate gateway profile to modify its attributes.

  3. Select the Core tab.

  4. Select the Enable Cookie Management checkbox to enable cookie management.

  5. In the Portal Servers field, enter portal server names of the service provider to use the relative URLs such as: /amserver or /portal/dt listed in the Non-Authenticated URLs list.

    http://idp-host:port/amserver/js

    http://idp-host:port/amserver/UI/Login

    http://idp-host:port/amserver/css

    http://idp-host:port/amserver/SingleSignOnService

    http://idp-host:port/amserver/UI/blank

    http://idp-host:port/amserver/postLogin

    http://idp-host:port/amserver/login_images

  6. Click Save.

  7. Click the Security tab.

  8. In the Non-Authenticated URLs list, add the Federation resources. For example:

    /amserver/config/federation

    /amserver/IntersiteTransferService

    /amserver/AssertionConsumerservice

    /amserver/fed_images

    /amserver/preLogin

    /portal/dt

  9. Click Add.

  10. Click Save.

  11. If web proxies are needed to reach the URLs listed in the Non-authenticated URLs list, select the Deployment tab.

  12. In the Proxies for Domains and Subdomains field, enter information about the web proxies.

  13. Click Add.

  14. Click Save.

  15. From a terminal window, restart the Gateway:

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

Configuration 3

In this configuration the identity providers, identity providers and the Common Domain Cookie Provider (CDCP) are not deployed in the corporate intranet or the service provider is a third party provider residing the in Internet and the identity provider is protected by the Gateway.

In this configuration the Gateway points to the identity provider, which is the Portal Server.

This configuration is valid for multiple instances of the Portal Server. This configuration is unlikely on the Internet, however, some corporate networks may have such a configuration within their intranet, that is the identity provider may reside in a subnet this is protected by a firewall and the service providers are directly accessible from within the corporate network.

ProcedureTo Configure Gateway to an Identity Provider (Portal Server)

  1. Log into the Portal Server administration console as administrator.

  2. Select the Secure Remote Access tab and select the appropriate gateway profile to modify its attributes.

  3. Select the Core tab.

  4. Select the Enable Cookie Management checkbox to enable cookie management.

  5. In the Portal Servers field, enter the portal server name of the identity provider to use the relative URLs such as: /amserver or /portal/dt listed in the Non-Authenticated URLs list.

    http://idp-host:port/amserver/js

    http://idp-host:port/amserver/UI/Login

    http://idp-host:port/amserver/css

    http://idp-host:port/amserver/SingleSignOnService

    http://idp-host:port/amserver/UI/blank

    http://idp-host:port/amserver/postLogin

    http://idp-host:port/amserver/login_images

  6. Click Save.

  7. Select the Security tab.

  8. In the Non-authenticated URLs list, add the federation resources. For example:

    /amserver/config/federation

    /amserver/IntersiteTransferService

    /amserver/AssertionConsumerservice

    /amserver/fed_images

    /amserver/preLogin

    /portal/dt

  9. Click Add.

  10. Click Save.

  11. If web proxies are needed to reach the URLs listed in the Non-authenticated URLs list, select the Deployment tab.

  12. In the Proxies for Domains and Subdomains field, enter information about the web proxies.

  13. Click Add.

  14. Click Save.

  15. From a terminal window, restart the Gateway:

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