Applies To:

Show Versions Show Versions

Manual Chapter: Configuring Web Applications
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Introducing web applications
Web applications access enables end users to access internal web applications, like iNotes or Outlook Web Access, with a web browser from outside the network. With web applications, the BIG-IP® Access Policy Manager communicates with back-end servers, and rewrites the links in the web page so that further requests from the client browser come back to the Access Policy Manager. The advantage is that the client computer requires no client software other than a browser application.
Web applications access provides clients with secure access to internal web servers, such as Microsoft® Outlook® Web Access (OWA), Microsoft SharePoint®, and IBM® Domino® Web Access (also known as Lotus® iNotes®). Using Web applications functionality, you can also provide access to most web-based applications and internal web servers. The rewriting engine also supports rewriting complex JavaScript. You can use features such as the web cache, minimal content rewriting mode, and others, to help refine compatibility and tune performance.
This method of access differs from connections configured for network access, which provide direct access from the client to the internal network. Network Access does not manipulate or analyze the content being passed between the client and the internal network. The web applications configuration gives the administrator both refined control over the applications that a user can access through Access Policy Manager, and content inspection for the application data.
The other advantage of web applications access is security. Even if a workstation might not meet requirements for security for full Network Access, such a workstation can be passed by the access policy to certain required web applications, without allowing full network access.
In a web applications access policy, the client computer itself never communicates directly with the end-point application. That means that all communication is inspected at a very high level, and any attacks originating on the client computer fail because the attack cannot navigate through the links that have been rewritten by the web applications engine.
Introducing web applications features and operation
Web applications access policies provide secure access to intranet web applications. The application being accessed and the protocol being supported (HTTP and HTTPS) dictate how web applications features operate. Figure 3.1 shows the process that a web applications connection follows.
You can use web applications to provide unified, secure access for one or more LAN internal web applications. The Access Policy Manager provides additional functionality to secure connections from client machines, such as public kiosks or PDAs, to ensure the security necessary to allow access to these web applications with a web browser.
In full patching mode, Access Policy Manager primarily retrieves content from backend servers and rewrites content so it can be presented to a web browser, as if the content originated from the Access Policy Manager. The Access Policy Manager portal rewrites content for two reasons:
To make intranet targets resolvable, no matter what the intranet host is, the request must go through the Access Policy Manager.
To make all requests resolvable by the Access Policy Manager, Access Policy Manager unambiguously decides where to proxy the request.
In the web applications rewriting implementation, the string /f5-w-<mangled scheme://host:port> is prefixed to every HTML link or dynamic URL. This provides the required multiplexing behavior on a single Access Policy Manager.
Access Policy Manager rewrites the code as:
In addition to URLs, the Access Policy Manager handles cookies on the server to provide client features, but they are not passed to the client.
The web application must reside on a single server. The Access Policy Manager cannot process URLs for multiple servers when minimal patching is enabled.
You must configure the scheme any, not http or https.
Note: In minimal patching mode, if your web application sets cookies, the cookie domain must match the virtual server domain.
Scheme Patching
Specifies a method of patching that replaces all HTTP scheme addresses with HTTPS scheme addresses.
Host Patching
Specifies a method of patching where a host or multiple hosts, typically the actual application server host name, is replaced with another host, the Access Policy Manager virtual server. You can specify multiple hosts separated with spaces for host search strings. The host replace string must be the Access Policy Manager virtual server IP address or fully qualified domain name (FQDN).
You can use the Access Policy Manager web applications feature for the following operations:
The Access Policy Manager uses a high-performance, full-content rewrite engine to handle complex HTML, JavaScript, and CSS. You can also enable a built in dynamic cache, so that the Access Policy Manager does not have to repeatedly rewrite content for static objects such as HTML, JavaScript, and style sheets.
Web application resource items are actual web applications that you add to a web applications configuration. The web application resource list allows you to specify several web applications using IP addresses, host names, or networks, and then to group these resources under a common web application name. It is also possible to configure every web application individually, with only one item on the web application resource list. Each web application resource item specifies the web application location information, and properties for the web application. While the web application configuration specifies the overall patching method for a web application access policy, for each separate web application resource item you can specify a web location, and properties for compression, caching, SSO (single sign-on), session timeout, Home tab usage, and logging.
In a web application resource item in Advanced view, you can configure headers to send to the application server. Headers are sent as name-value pairs. To add a header, type the header name and value in the boxes next to the Header section, and click the Add button.
You can define compression functionality for a web applications resource item on the Web Applications Resource Item Properties screen.
No Compression
Web application generated content is not compressed. This requires increased bandwidth, and one result is slower load times for some application types. However, it also results in less usage of system resources.
GZIP Compression
Uses the gzip compression utility to substantially reduce the size of generated content. The most noticeable improvement in speed occurs when accessing pages that contain large Java classes or other large elements (images, scripts, and so on), but not when accessing pages that reference Java packages (.jar files), class archives (.zip files), or compressed images (.jpg, .png, and Compressed TIFF files).
For iNotes and other Java-based web mail packages, enabling compression vastly improves the speed in which pages are loaded.
You can define client-side caching functionality for a web applications resource item on the Web Applications Resource Item Properties screen. To access the screen, in the navigation pane, expand Access Policy, click Web Applications, and click a resource item.
Note: In any caching scenario, Access Policy Manager caches only those objects that the remote server designates can be cached.
Default - Takes the client cache settings from the rewrite profile. In the rewrite profile, you can specify a client caching option - CSS and JavaScript, CSS, Images and JavaScript, No Cache or Cache All. If you configure a client cache setting other than Default in the web application resource item, that setting overrides the cache setting in the rewrite profile.
Cache All - Caches everything that can be cached, including CSS, images, JavaScript, and XML. Provides the fastest client performance and the lowest security.
To allow your clients to download and save attachments, use the Cache All setting.
For example, to make sure Outlook Web Access 2007 attachments can be downloaded, configure the web application resource URI /owa/attachment* with the Cache All setting.
No Cache - Caches nothing. This provides the slowest client performance and is the most secure.
To allow sessions to time out based on the timeout settings in the access profile, use this option. To enable the session timeout for a web application resource, select the Session Timeout check box in the advanced resource item properties. To disable the session timeout for a web application resource item, clear the check box.
The Access Policy Manager inserts a small amount of JavaScript into HTML pages that generates the hometab. The hometab displays the Home and Logout navigation links, and the Address bar, where a user can enter a URI to access the web application. To enable the Home tab on a web application page, select the Home Tab check box in the advanced resource item properties. Pages generated without the Home Tab JavaScript contain no Home or Logout links. The Home tab can be fully customized. See Reviewing web applications hometab settings.
You can configure the Access Policy Manager to provide access to web applications without requiring client configuration changes or software downloads. Typically, you use web applications access when your users only require access to specific internal web portal-based applications, and do not require full Network Access. The Access Policy Manager provides security by rewriting URLs and other links in the original HTML document, CSS, and JavaScript content.
F5 Networks has tested the following web applications to ensure that the Access Policy Manager handles them without requiring andy reconfiguration.
Microsoft® Outlook Web Access 2003 and 2007
Microsoft® SharePoint 2003, 2007
Some of your custom web applications will work with web applications without you having to make changes to the applications.
If you have a specific web application that requires additional configuration to work through web applications, you can generally use Network Access. Network Access provides a direct connection to the internal network, and does not require proxy-based changes or modification of web application content. If you cannot use web applications or Network Access to solve access issues, you can try the minimal patching feature. For more information about this feature, see Understanding minimal patching mode.
1.
From the navigation pane, expand Access Policy and click Web Applications.
The Web Applications Resource List screen opens.
2.
Click Create.
The New Resource screen opens.
3.
In the Name box, type a name for the web application.
5.
From the Patching Type list, select the patching type for the web application.
For full and minimal patching types, you can select or clear specific patching methods.
6.
If you selected host patching with the minimal patching method, type a host search string, or multiple host search strings separated with spaces, and the host replace string, which must be the Access Policy Manager virtual server IP address or FQDN.
7.
If your application is behind a proxy server, to specify a proxy host and port, select Advanced for the configuration, and type the proxy host and proxy port.
8.
Click the Create button to create the web application.
The Web Applications Properties screen opens.
1.
From the navigation pane, expand Access Policy and click Web Applications.
The Web Applications Resource List screen opens.
2.
Click the name of the web application to which you want to add a resource item.
The Web Applications Properties screen opens.
3.
In the Resource Items area, click Add.
The New Resource Item screen opens.
4.
In the New Resource Item section, select Basic or Advanced.
Advanced allows you to add Headers.
5.
For the Destination setting, select the type of destination (Host Name, IP Address, or Network).
Important: The type of destination must match the destination address your users will specify to connect to the web application. For example, users cannot connect using a host name if you specify an IP address for the web application.
7.
In the Port box, type the port number. To allow all ports, type 0, or select Any from the Scheme list.
8.
From the Scheme list, select the scheme (HTTP or HTTPS), or select any for both.
9.
In the Paths box, type the path to the application.
This is the URI, including the leading slash. For example, /webapp/webapp.aspx.
You can specify multiple paths by separating them with spaces, and use * and ? wildcard characters.
10.
If you select Advanced, you can add headers. In the Name and Value boxes in the Headers section, type the name and value pair for each header, and click Add.
11.
In the Resource Item Properties section, select Basic or Advanced.
Advanced allows you to enable or disable Session Timeout and the Home Tab.
12.
From the Compression list, select the compression option.
13.
From the Client Cache list, select the client caching option.
See Understanding web application caching, for more information.
14.
If you are using an SSO configuration for Single Sign On, from the SSO Configuration list, select the SSO configuration.
15.
Select whether to enable the Session Update and Home Tab options with the associated check boxes.
16.
From the Log list, select the logging level.
17.
When you are finished, click Update.
The Web Application Properties screen opens.
A rewrite profile defines client caching settings for a virtual server. You can configure a rewrite profile and select the rewrite profile when you configure the virtual server for a web applications access policy. Alternatively, you can use the default rewrite profile, rewrite.
The rewrite profile provides four options for client caching. When a web application resource items Client Cache setting is set to Default, the caching option configured in the rewrite profile is used. If the Client Cache option is configured for any other setting, the web application resource item configuration overwrites the setting in the rewrite profile.
CSS and JavaScript - caches CSS and JavaScript. This is the default rewrite caching configuration, and provides a balance between performance and security.
CSS, Images and JavaScript - Caches CSS, images, and JavaScript. This provides faster client performance but is slightly less secure because of cached images in the client browser cache.
No Cache - Caches nothing. This provides the slowest client performance and is the most secure.
Cache All - Caches everything that can be cached, including CSS, images, JavaScript, and XML. Provides the fastest client performance and the lowest security.
1.
From the main navigation pane, expand Access Policy, and click Rewrite Profiles.
The Rewrite Profile List screen opens.
2.
Click Create.
The New Profile screen opens.
3.
In the Name box, type a name for the rewrite profile.
4.
(Optional) From the Parent Profile list, select a parent profile. The new rewrite profile inherits the Client Caching Type setting from the parent profile.
5.
(Optional) Next to Settings select the Custom check box to change the Client Caching Type.
6.
From the Client Caching Type list, select the caching option.
7.
Click Finished.
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)