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:
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.
Will the application be available from the Internet? Will the application be available only from the Intranet? Use the Locate Reverse Proxy Process 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.
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 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.
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 Next, follow the New Reverse Proxy Configuration Process 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.
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:
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. app1.company.com, app2.company.com, 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:
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. www.domain.com/app1, www.domain.com/app2, etc. Path-based multi-homing has the following characteristics:
Once the proxy service is created, further configure the service by clicking on the service name and selecting one of the tabs.
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.
Use web_server.pdf as a guide to create/modify the web server parameters.
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.
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:
You can select from the following types of protection:
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:
!ProtectedResourceTabs.jpg!
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:
The two most common settings to use are:
The URL listing specifies what entity, or path, on the origin web server to protect; either a directory or a specific file. For example:
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 and Form Fill are Single Sign-on policies that allow a WAM authenticated to be signed into the protected resource, or application.
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 | |
| X-Forwarded-For |
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:
For additional information, see the Identity Injection Process page.
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:
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.