AppWrap in UAG – what’s new

AppWrap (Application Wrapper) is an IAG and UAG XML configuration file that enables manipulating HTTP responses on their way back from the backend web server to the client.

In IAG 2007, approximately 30 such files existed, since each AppWrap file was used for a different type of single-application trunk (for example, one AppWrap file was used for a trunk publishing Outlook Web Access 2003, and another AppWrap file for a trunk publishing Outlook Web Access 2007), as well as for portal trunks.

Since single-application trunks are not used in UAG (with the exception of publishing an Active Directory Federation Server), we are left with one main AppWrap file, which is the one used for portal trunks (two versions of this file exist – for HTTP and HTTPS trunks – but they are very similar).

After removing a large amount of manipulation configurations, the files became much clearer and maintainable, as their size was reduced to about 1/3 of their size on IAG 2007.

Manipulation per application

The AppWrap structure was changed to support manipulation per application:

Each group of <DATA_CHANGE> tags is enclosed within <APPLICATION_TYPE> [APP_TYPE] </APPLICATION_TYPE> tags, where APP_TYPE represents the application ID defined in the top part of WizardDefaultParam.ini and then inside []. For example, [ExchangePub2007].

It is still possible to define an empty APPLICATION_TYPE as follows: <APPLICATION_TYPE></APPLICATION_TYPE>, for any other manipulation for a non-defined application.

This change greatly improved the “search & replace” manipulation mechanism and thus enhanced performance.

Backward compatibility

In order to port IAG-style AppWrap files to the UAG format, some manual changes of the original file are needed: after the <MANIPULATION> tag, add a <MANIPULATION_PER_APPLICATION> tag, immediately followed by an <APPLICATION_TYPE> [APP_TYPE] </APPLICATION_TYPE> tag.

Remember to add a closing </MANIPULATION_PER_APPLICATION> tag after all the <DATA_CHANGE> sections, right before the <HEADER_CHANGE> section begins.

The changes are highlighted below.

<APP_WRAP ver="3.0" id="RemoteAccess_HTTPS.xml">

          <MANIPULATION>

                  <MANIPULATION_PER_APPLICATION>

                          <APPLICATION_TYPE>InternalSite</APPLICATION_TYPE>

                          <DATA_CHANGE>

                                  <URL case_sensitive="false">…</URL>

                                  <SAR>

                                          <SEARCH encoding="base64">…</SEARCH>

                                          <REPLACE encoding="base64" using_variables="true">…</REPLACE>

                                  </SAR>

                        </DATA_CHANGE>

                       …

                       …

                       …

                 </MANIPULATION_PER_APPLICATION>

                 <HEADER_CHANGE>

                 …

                 …

                 …

                </HEADER_CHANGE>

        </MANIPULATION>

</APP_WRAP>

Important: Once you’re done modifying the AppWrap file, save it and then double-click it in order for it to open in Internet Explorer. If it opens without any errors, you can be sure that you did not break the XML file syntax while editing the file, and thus the file can be used by UAG. Otherwise, if the syntax is incorrect, IE will indicate that a problem exists and will usually give you a pretty good tip as to what is broken.

Conditional SAR

Conditional SAR (Search and Replace) is a new capability which enables performing manipulations only when certain conditions related to a UAG session parameter are met.

For example, we may want to remove the ‘Log off’ link from an application, but only when this application is published within the portal frame (where the portal ‘Log off’ button exists and should be used). We use the following SAR tag:
<SAR conditional_variable="UsePortalFrame" conditional_var_value="False"> .

For example, hiding the ‘Log off’ button on SharePoint 2007:

<URL case_sensitive="false">.*\.aspx.*</URL>

         <SAR conditional_variable="UsePortalFrame" conditional_var_value="True">

                    <SEARCH encoding="base64">SignOut.aspx';" </SEARCH>

                    <REPLACE encoding="base64">SignOut.aspx';" style='visibility:hidden;'</REPLACE>

        </SAR>

</URL>

This option is also available for HTTP header manipulation.

Session parameters and their respective values can be obtained through the Session Details screen on the UAG Web Monitor.

Out of the box AppWrap main manipulations

Here is a list of the main kinds of manipulations performed by the AppWrap feature:

• Blocking uploads and downloads, according to endpoint policy definitions.
• Adding session timeout and logoff functionality to applications.
• Removing logoff functionality from applications published within portal.
• Fixing application publishing bugs (mismatch of HTTP & HTTPS, accessing wrong frames due to portal structure, etc.)
• Sending the Exchange CAS server the right HTTP request headers to support private/public access, as well as access to OWA Light.

Ron Gilad

Comments

• Anonymous
  March 08, 2016
  Pingback from AppWrap and SRA | Ben Ari's UAG and IAG Blog
• Anonymous
  March 08, 2016
  Pingback from AppWrap and SRA | Ben Ari's UAG and IAG Blog