Application Considerations for NAM#

Some items to keep in mind about setting up applications.  Each application will have a set of rules and policies that will make up a proxy service for that application.  The proxy service is configured within a reverse proxy list.  A reverse proxy list can contain one, or more proxy services.  A LAG cluster can contain one or more reverse proxies.

In order to create a proxy service for a new new application, a set of decisions needs to be made and a process followed to maintain a consistent WAM configuration.  The basic process is as follows:

  1. Gather information about the application
  2. Decide where to locate the reverse proxy configuration
  3. Decide if the new application will be part of an existing reverse proxy, or a stand-alone reverse proxy
  4. Either create the new reverse proxy service, or edit an existing reverse proxy service
  5. Create the proxy service list for the application
  6. Create the protected resource list for the application
  7. Create any policies around access control, redirection, SSO, etc.
  8. Modify the appropriate DNS servers
  9. Configure the L4 switches to allow access to the reverse proxy

This process assumes this is carried out within a test environment and the application's business owners are satisfied with the configuration.  Once the tested configuration is completed, the configuration will need to be moved to production. 

Locate the proxy service#

Will the application be available from the Internet?  Will the application be available only from the Intranet?  Use the Locate Reverse Proxy Process(info) to properly decide on which LAG cluster to create the proxy service.  As input into this process, you'll need to have detailed information about the application.  What information is required can be found in the NAM Application Request Information template.

Proxy Decision#

After determining what LAG cluster will be used for the application, decide if a new reverse proxy service is required.  Use the New or Existing Reverse Proxy Process(info) to help determine what proxy service to use.  If you don't need a new reverse proxy service, the next step will be to create a new reverse proxy service for the application.

  1. Select the appropriate LAG cluster and under Configuration, choose Edit to start the the proxy service configuration process
  2. Based upon the application requirements, decide if a new or existing domain name is appropriate
    • If the application will use an existing domain, then it is a good candidate to use an existing proxy configuration
    • If the application will use a new domain not created on the LAG cluster, then you will create a NEW proxy configuration
  3. If the domain will be reused, can the SSL certificate tied to that domain be used as well?  If so, then the application is a good candidate to use an existing proxy configuration.
  4. Does the application require a different IP address?  This would be the case if separation was required from other applications based upon security requirements, access levels, or other reasons.  If not, then this application is a good candidate to use an existing proxy configuration.
The process diagram includes a screen shot of the proxy configuration dialog.

New Reverse Proxy#

If you need to create a service, it will require a unique IP address.  It is easiest to create this new IP address before entering the proxy configuration process as the IP address is a selection criteria for the proxy configuration.  Define a new IP address using the Network Settings area of the LAG cluster configuration as shown here(info) Next, follow the New Reverse Proxy Configuration Process(info) diagram to create the new service.  Give the reverse proxy service a short name, descriptive of the domain name it will be servicing.  Once the reverse proxy service is created, complete the configuration using the Define Listening Address process. After this configuration, the proxy service list can be created.

Create the Proxy Service List#

Once the reverse proxy is created (or selected) and the IP communications is configured, create a proxy service for the application.  The proxy service defines:

  • what web server to proxy
  • what port to use to communicate to both the client and the web server
  • what encryption certificate to use - if required
  • what public DNS name will be used for the application - what the user will require to know (the URL)
  • what set of protected resources will be required
  • and any other special requirements of the application

This is the heart of the configuration for the application.  The New Proxy Service Process; shows how to create the service. 

As shown in the process, after creating a name for the proxy service, the first thing to decide is whether to use domain-based or path-based multi-homing.  *Note:* If this is the first proxy service for the reverse proxy, these options are not available.  Multi-homing allows the LAG to conserve public IP addresses and use one IP address to protect many web servers.  Or in other words, it makes the LAG a multi-homing device because it becomes a single endpoint supporting multiple back-end resources.  For most applications, domain-based multi-homing is the preferred configuration.
{quote} Domain-based multi-homing allows the use of a single domain for many applications, i.e.,, etc.  Since the domain-name is the same for all resources, a single SSL wild-card certificate can be used to encrypt communications between the LAG and the client.  This is the main advantage to using domain-based multi-homing:

  • If you are using SSL, the back-end servers can all listen on the same SSL port (default for HTTPS is 443)
  • If you are using SSL, the back-end servers can share the same SSL certificate.  Instead of using a specific host name in the SSL certificate, the certificate can use a wildcard name such as \*, which matches all the resources.

Path-based multi-homing uses the same DNS name for all resources, but each resource, or resource group, must have a unique path appended to the DNS namei.e.,, etc.  Path-based multi-homing has the following characteristics:

  • It is considered to be more secure than domain-based multi-homing, because some security experts consider wildcard certificates less secure than a certificate with a specific hostname.
  • Each resource or group of resources must have a unique starting path.
  • JavaScript applications might not work as designed if they obscure the URL path. The LAG needs access to the URL path, and if it is obscured, the path cannot be resolved to the correct back-end resource.
  • The protected resources for each path-based child come from the parent proxy service.
The next part of the process is to define the origin web server running the application.  Enter the IP address of the origin server.  (After the configuration is defined, you can add additional server addresses if there are multiple servers running the application, as in a web server farm.)  You can change this to a DNS name later, but for this part, you will need to enter an IP address.  

Finally, define the host header.  Specify whether the HTTP header should contain the name of the back-end Web server (the Web Server Host Name option) or whether the HTTP header should contain the published DNS name (the Forward Received Host Name option).

Once the proxy service is created, further configure the service by clicking on the service name and selecting one of the tabs.

Proxy Service#

This tab shows the Published DNS name defined when the proxy service was created.  You can modify the value here as needed and/or add a description.  The HTTP Options are seldom used.  Open the link and read the help file associated with this option for further info.

Web Server #

Use web_server.pdf(info) as a guide to create/modify the web server parameters.

HTML Rewriting#

In all cases where a proxy service is configured with a published DNS name that is different from the application's DNS name, the LAG will be rewriting the URL.  LAG configurations require HTML rewriting because the origin web servers are not aware that the LAG is obfuscating their DNS names.  Any reference URLs contained in their pages must be checked to ensure that these references contain the DNS names that the client browser expects.  On the other end, the client browsers are not aware that the LAG is obfuscating the DNS names of the resources they are accessing.  The URL requests coming from the client browsers that use published DNS names must be rewritten to the DNS names that the Web servers expect.

In most cases, the default re-writer is enough for your application.  However, if your Web server uses absolute links instead of relative links, you must further configure HTML rewriting.  Depending upon where the links are found on the HTML pages, you might also need to create a rewriter profile.  Use this tab to create those configurations.  The help file associated with this page is quite useful.

Protected Resources#

A proxy service defines the basic communications for the LAG device to use on behalf of the application.  In order to control user access to the application, the LAG device must know where the application's files reside and what policies to enforce for each location.  This configuration set is called a protected resource.  The type of protections an application requires depends upon the application, the Web server, and the conditions, or security requirements defined by A&F.  A protected resource configuration specifies the following:

  • directory (or directories) on the Web server that are to be protected
  • the authorization contract that should be used to enforce protection
  • the policies that should be used to enforce protection

You can select from the following types of protection:

  • Authentication Contract: Specifies the type of credentials the user must use to log in (such as name and password or secure name and password).  It is acceptable to select None for the contract, which allows the resource to be a public resource, with no login required.
  • Authorization Policy: Specifies the conditions a user must meet to be allowed access to a protected resource.  As an example, a role can be defined and assigned to a list of users and access to the application granted (or denied) according to this role
  • Identity Injection Policy: Specifies the information that must be injected into the HTTP header. If the Web application has been configured to look for certain fields in the header and the information cannot be found, the Web application determines whether the user is denied access or redirected.  The Web application defines the requirements for Identity Injection. The Identity Injection policies allow you to inject the required information into the header.
  • Form Fill Policy: Allows you to manage forms that Web servers return in response to client requests. Form fill allows you to prepopulate fields in a form on first login and then securely save the information in the completed form to a secret store for subsequent logins. The user is prompted to reenter the information only when something changes, such as a password.

Combining these four types of protection in different ways allows the design of custom policies for each protected resource and enables a single sign-on environment for the user.  Resources that share the same protection requirements can be configured as a group.  A resource that has specialized protection requirements can be set up as a single protected resource.  For example, a page that uses Form Fill is usually set up as a single protected resource.

The following four tabs are available for a protected resource:

  • Overview
  • Authorization
  • Identity Injection
  • Form Fill


The Authorization, Identity Injection and Form Fill tabs list the specific policies for each type.  Each of these tabs represent a subset of the entire policy list.  The complete policy list can be viewed and managed from the iManager interface under the link, Policies.  This part of the interface can be a bit confusing because of the duality of managing policies.  Remember in order to protect a resource, WAM uses both file location restrictions as well as policy based restrictions.  The file based protection is handled within the Overview tab, the policy based restrictions are handled within the remaining three tabs.


Within the Overview tab are two important items to a protected resource.  The specified *contract* and the *URL* list.

The contract determines the information a user must supply for authentication.  Included in the default LAG configuration are the following contracts:

  • _None:_ If you want to allow public access to the resource and not require an authentication contract, select None.
  • _Any Contract:_ If the user has authenticated, allows any contract defined for the Identity Server to be valid, or if the user has not authenticated, prompts the user to authenticate using the default contract assigned to the Identity Server configuration.
  • _Name/Password - Basic:_ Specifies basic authentication over HTTP, using a standard login pop-up provided by the Web browser.
  • _Name/Password - Form:_ Specifies a form-based authentication over HTTP, using a LAG login form.
  • _Secure Name/Password - Basic:_ Specifies basic authentication over HTTPS, using a standard login pop-up provided by the Web browser.
  • _Secure Name/Password - Form:_ Specifies a form-based authentication over HTTPS, using a LAG login form.

The two most common settings to use are:

  • Any Contract (primarily used with Identity Injection policies)
  • Secure Name/Password - Form (primarily used with Form Fill policies)

The URL listing specifies what entity, or path, on the origin web server to protect; either a directory or a specific file.  For example:

  • /public/\* allows access to all the pages in the public directory on the Web server, such as images, etc.
  • /\* allows access to everything on the Web server *(understand this setting and use with caution)*
  • /? allows access to the root directory, but not the subdirectories
  • /public/? allows access to the files in the public directory, but not the subdirectories
  • /login/login.html allows access to a single page, login.html

It is important to understand for a particular page where all the information contained in the page is coming from.  Browser add-on tools, such as Page Info and HTTP Watch can help with gathering this information.  For instance, images may be standardized across the organization and exist on a separate directory or server from the application.  If you initially get a page that has several items, images or links missing, chances are you have not created the URL listing to include everything that the application needs.

The single page access is the type of URL path you want to specify when you create a Form Fill policy for a protected resource.  The URL Path Listnormally contains only this one entry.  If you have multiple pages that the Form Fill policy applies to, list each one separately in the list.  For optimum speed, you want the LAG to be able to quickly identify the page and not search other pages to see if the policy applies to them.

When creating a path for a path-based multi-homing proxy, specify the path used in creating the proxy. If you do not remove the path on fill, you can specify the path with subdirectories to create a protected resource for a subdirectory.


The Authorization tab shows those policies that are enabled and others that are available that pertain to Authorization policies for the protected resource.  Once an Authorization policy is defined, you can Enable or Disable it within this tab.

Identity Injection#

The Identity Injection tab shows those policies that are enabled and others that are available that pertain to Identity Injection policies for the protected resource.  Once an Identity Injection policy is defined, you can Enable or Disable it within this tab.

Form Fill#

The Form Fill tab shows those policies that are enabled and others that are available that pertain to Form Fill policies for the protected resource.  Once an Form Fill policy is defined, you can Enable or Disable it within this tab.


This section details the policies currently in use by A&F and the processes required to properly determine how to create each policy.  A policy consists of rules and actions.  A policy can be reused within the LAG for different protected resources and different proxy services.  The three typical policies in use at A&F are:
  • Authorization - controlling access to a resource
  • Identity Injection - injecting information on behalf of the user and passing it to the web server
  • Form Fill - remembering user input within a form and submitting the form for the user

Identity Injection and Form Fill are Single Sign-on policies that allow a WAM authenticated to be signed into the protected resource, or application.

Authorization Policy#

An Authorization policy specifies conditions that a user must meet in order to gain access to a resource.  These conditions are enforced by the LAG.  The Authorization policy can also be used to redirect the user based upon specific criteria, such as a URL.  As an example, if you create a role and assign it to the users, the role can be used to allow access or deny access to a resource.  The conditions allowed for defining an Authorization policy can be any combination from the following table:

Authentication Contract Client IP Credential Profile
Current Date Current Day of Week Current Day of Month
Current Time Of Day HTTP Request Method LDAP Attribute
LDAP OU Liberty User Profile Roles for Current User
URL URL Scheme URL Host
URL Path URL File Name URL File Extension

Identity Injection Policy#

An Identity Injection policy is the process in which WAM can inject a user's identity into a HTTP header on behalf of the user.  This provides a mechanism for single sign-on with credentials or attributes of the user object, without the need for the user to enter anything more than is required by WAM.  The Web application defines the requirements for an Identity Injection policy.  If a Web application has been configured to look for certain fields in the header and the information cannot be found, the Web application determines whether the user is denied access, granted access, or redirected.  \LAG can also be instructed to redirect the user on an invalid authentication.\  You configure an Identity Injection policy to inject into the HTTP header the information that the Web application requires.  In other words, an application could be configured to look for the business unit name of the individual that is attempting access and present a page based upon that business unit.  However, the user is only required to know their name and password.  Once they have properly authenticated to WAM, the Identity Injection policy, with its set of rules, can pass the business unit associated with the user to the application.

There are many different headers and options for WAM to inject a user's identity.  They are:

  • Inject into Authentication Header
  • Inject into Custom Header
  • Inject into Custom Header with Tags
  • Inject into Cookie Header
  • Inject into Query String

For additional information, see the Identity Injection Process page.

Form Fill#

A Form Fill policy allows you to pre-populate fields in a form on first login and then save the information in the completed form to a secret store for subsequent use the next time the user accesses the application.  The user is prompted to enter the information once and then re-enter the information only when something changes, such as an expiring password. The HTML page determines the requirements for the Form Fill policy.  A form can be anything the developer wants to have filled by the user.  For example, a simple form requires a username and password.  The Form Fill policy can be configured to capture the information the user inputs into these fields, or pull attributes associated with this user and populate the fields automatically.  It depends on what type of experience the user should see, and what information the application requires. 

The terminology for inputting this information into a form is called an Action.  A Form Fill policy has a name, a description and an action, or a set of actions, depending upon the application's requirements.  To create a Form Fill policy, you would configure the following:

  • Form Selection
  • Fill Options
  • Submit Options
  • Error Handling 

For additional information, see the Form Fill Process page.

Since the information being filled into a HTML form can change over a period of time (such as a user password), you also need to specify a policy for handling login failure.  This allows the process to be interrupted and directed back to the user so they can input the proper information and re-submit the form.  A properly configured login failure process will capture this new information.  When the user access the form again, WAM will fill in the form with the new information, auto-submit the form and the user will have SSO once again.

  • If your login failure page shares the same URL as the login page, you can configure the failure process in the same policy. In the Actions section of the policy, click New and select Form Login Failure. For configuration information, see Form Login Failure.
  • If your login failure page uses a different URL than your login page, you need to create a separate Login Failure policy for this page and assign it to the protected resource for the login failure page. For policy configuration information, see Form Login Failure

More Information#

There might be more information for this subject on one of the following:

Add new attachment

Only authorized users are allowed to upload new attachments.

List of attachments

Kind Attachment Name Size Version Date Modified Author Change note
form_fill_process.pdf 226.2 kB 1 02-Feb-2009 13:47 jim
identity_injection_process.pdf 211.8 kB 1 02-Feb-2009 13:48 jim identity_injection_process.pdf
locate_reverse_proxy.pdf 188.7 kB 1 02-Feb-2009 13:47 jim locate_reverse_proxy.pdf
new_ip.pdf 86.7 kB 1 02-Feb-2009 13:49 jim new_ip.pdf
new_or_existing_proxy.pdf 132.2 kB 1 02-Feb-2009 13:49 jim new_or_existing_proxy.pdf
new_proxy.pdf 109.3 kB 1 02-Feb-2009 13:49 jim new_proxy.pdf
web_server.pdf 61.2 kB 1 02-Feb-2009 13:50 jim web_server.pdf
« This page (revision-10) was last changed on 14-Nov-2011 12:38 by jim