About publishing SharePoint Products and Technologies with IAG SP2 or SP1 Update 2
Applies To: Intelligent Application Gateway (IAG)
Using Whale Communication Intelligent Application Gateway (IAG) 2007 you can publish SharePoint products and technologies. This topic contains the following sections:
About alternate access mappings
Benefits of using IAG as a gateway to SharePoint sites
Typical scenarios for using IAG as a gateway to SharePoint sites
Planning for application authentication
Planning to use public host names
Planning to use server certificates
For more information about publishing internal resources via IAG, see Planning for access to internal resources published by IAG.
About alternate access mappings
You can use alternate access mappings in order to publish Microsoft SharePoint Products and Technologies (Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0) through the IAG portal.
Note
IAG supports alternate access mappings in Office SharePoint Server 2007 and higher. This document does not refer to earlier versions such as SharePoint Portal Server (Office 2003 version). A backward-compatibility IAG application is provided for cases where alternate access mappings cannot be used.
Alternate access mappings enable Office SharePoint Server 2007 to map Web requests to the correct Web applications and sites, and they enable Office SharePoint Server 2007 to serve the correct content back to the user. For example, in a setup where internal users access a SharePoint site at https://hr from within the organization and remote users access the same SharePoint site at https://HRportal.contoso.com through IAG, Office SharePoint Server 2007 replies to both internal and remote users with identical content, despite the fact that external users submit a different protocol (HTTPS) and a different host header (HRportal.contoso.com) than those that internal users submit. For additional information about alternate access mappings, see Plan alternate access mappings (Office SharePoint Server) (https://go.microsoft.com/fwlink/?LinkId=122489).
Users are also able to access SharePoint sites directly, without having to pass through the IAG portal, by using the public host name that you assign when you add the application to the portal.
Benefits of using IAG as a gateway to SharePoint sites
Both the organization and the end users benefit from using IAG as a gateway to SharePoint sites, including the following benefits:
Anywhere access—Users are able to access SharePoint sites and edit their documents from virtually anywhere: managed laptops, home computers, kiosks, and mobile devices.
Information leakage prevention—When users open or edit a document from a SharePoint library via IAG, no residue is left on the client computer; IAG deletes all cached files, temporary files, and cookies.
Endpoint health-based authorization—IAG allows administrators to define an access policy that is based not only on the identity of the user and the information that is exposed, but also on the condition of the client computer, for example, basing the policy on the computer's operating system, on the browser that is used to access the site, or on whether or not an up-to-date antivirus is running on the computer. Typical implementations of this type of authorization prevent users that don’t run an antivirus from uploading files to the SharePoint site, and they also prevent access to sensitive information from public computers.
Advanced authentication schemes—IAG implements many authentication schemes, ranging from simple username and password forms to smartcard-only authentication, one-time passwords, and partner integration via Active Directory Federation Services (ADFS).
Enabling access to SharePoint sites from Microsoft Office Outlook Web Access—When Outlook Web Access is also published via the IAG portal, IAG makes sure that if an e-mail message contains a link to a published SharePoint site (for example, https://intranet.contoso.com/), the link will work properly even if it contains Intranet domain names (for example, https://intranet/).
Single sign on—Users have to sign on only once during a session. Once they do, IAG saves their credentials, and they are automatically signed on to any system they wish to access during the session. This is extremely useful when publishing several SharePoint sites or additional applications.
Unified portal—After a user logs on, IAG presents the user with a list of SharePoint sites and other applications that are available and for which the user is authorized. The list is dynamic and reflects the current client health and IAG server configuration.
Automatic timeout—IAG detects whether or not users are active and automatically logs off users that are not active for a predefined amount of time. This is extremely important in remote-access scenarios, where users might leave their computer unattended in a public location.
Internet-ready appliances—IAG was developed and designed as an Internet and perimeter network (also known as DMZ, demilitarized zone, and screened subnet) appliance, and it is hardened and secured according to industry standards.
Secure Sockets Layer (SSL) termination—IAG can terminate SSL connections and mitigate the load off Office SharePoint Server, while providing a single point of management for certificates.
Application protection—Not only does IAG act as an HTTP proxy and buffer the internal servers from the Internet, it also incorporates several application-level technologies in order to protect computers running Office SharePoint Server from malicious attacks.
Typical scenarios for using IAG as a gateway to SharePoint sites
Typical scenarios for using IAG as a gateway to SharePoint sites include the following:
Extranet—IAG provides partners, customers, and suppliers with access to dedicated, internal SharePoint sites.
Roaming employees—IAG is deployed to provide employees with access to internal SharePoint sites when they are outside of the corporate network.
Mobile devices—IAG allows the publishing of internal mobile applications to mobile devices, which are typically used outside of the corporate network.
Planning for application authentication
One of the steps you need to take during the deployment of SharePoint Products and Technologies through IAG is to configure how remote users authenticate against the SharePoint Web application from within the IAG portal.
For more information about IAG authentication options, see Planning for IAG authentication and authorization.
Planning to use public host names
When you publish SharePoint Products and Technologies via IAG, each SharePoint Web application is associated with a unique public-facing host name; this public host name is used to access the application remotely.
This also applies to Web applications that are co-hosted on the same Office SharePoint Server 2007 server or server farm and are configured on different ports. For example, in order to publish the applications HRportal:80 and Mysite:81, which are co-hosted on the same server running SharePoint Products and Technologies, you need to assign two individual public host names, one for each SharePoint Web application.
A SharePoint Web application that is published through the IAG trunk shares the trunk's definitions as well as some of the trunk's functionality, such as the logon and logoff pages. Therefore, the application's public host name must reside under the same parent domain as the trunk's public host name; that is, the application and the trunk are subdomains of the same parent domain.
The following table shows sample public host names of IAG trunks and the public host names you can and cannot use for the SharePoint Web applications that you publish through each sample trunk.
| IAG trunk's public host name | Trunk's parent domain | Examples of valid public host names for SharePoint Web application | Examples of invalid public host names for SharePoint Web application |
|---|---|---|---|
iag.contoso.com |
contoso.com |
hrportal.contoso.com hrportal.a.b.contoso.com hrportal.iag.contoso.com |
hrportal.com |
iag.ext.example.com |
ext.example.com |
hrportal.ext.example.com hrportal.a.b.ext.example.com hrportal.iag.ext.example.com |
hrportal.com hrportal.example.com |
When you select an application's public host name, you also need to consider the limitations that are associated with the trunk's server certificate. For information about server certificates, see Planning to use server certificates.
Planning to use server certificates
During the initial configuration of an HTTPS trunk in IAG, you select the trunk's server certificate; all the public host names that are used in the trunk should be covered by this certificate, including the trunk's public host name and the public host names of all the applications that are accessed via the trunk.
The following types of certificates support multiple host names:
Wildcard certificate—Covers all host names that are in a given domain level; it does not cover names that are in any of the domain's superdomains or subdomains. For example, the certificate *.contoso.com covers the host names iag.contoso.com and HRportal.contoso.com, since they are both on the same domain level; it does not cover, however, the host name HRportal.iag.contoso.com, since it is a subdomain in the domain *.contoso.com.
Subject Alternative Name certificate—Includes a primary domain and a list of other domains that are covered by the certificate. There is no difference between the primary and the secondary domains, and there is no limitation on the number of host names you can use. Note, however, that if host names are added to or removed from the trunk, you need to issue and select a new certificate for the trunk.
For information about how to import a certificate into IAG, see HOW TO: Install Imported Certificates on a Web Server in Windows Server 2003 (https://go.microsoft.com/fwlink/?LinkId=126614), and then follow these procedures:
Install the Certificates
Import the Certificate into the Local Computer Store
Note
Do not follow the procedure "Assign the Imported Certificate to a Web Site"; you assign the certificate to the IAG Web site when you create or edit the IAG trunk through which you publish the SharePoint Web application.
While you plan your deployment of SharePoint Products and Technologies through IAG, use the following documentation in order to help design the ideal solution for meeting your business needs:
Understanding Office SharePoint Server 2007 deployment topologies with IAG
Requirements for IAG client endpoints when publishing SharePoint Products and Technologies via IAG
For deployment instructions, see Publishing SharePoint Products and Technologies via IAG SP2 or SP1 Update 2.