CA API Gateway 9.1

9.4 9.1

Publish Reverse Web Proxy Wizard

The Publish Reverse Web Proxy Wizard is used to publish a policy that enables the to behave as a reverse web proxy, allowing you to manipulate the request and/or response headers, cookies, and content.
gateway91
The Publish Reverse Web Proxy Wizard is used to publish a policy that enables the
API Gateway
 to behave as a reverse web proxy, allowing you to manipulate the request and/or response headers, cookies, and content.
Running the Publish Reverse Web Proxy Wizard does the following:
  1. Adds the reverse proxy web service to the list on the Policy Manager interface.
  2. Opens the policy for editing in the policy development window.
As with all -published services, you can publish multiple instances of the reverse proxy service—simply ensure that each contains a unique resolution URI.
This wizard can create a generic reverse-proxy policy, or one specifically for SharePoint 2013.
Ensure that you have the correct security permissions to:
  • Publish or modify a reverse proxy service
  • Create services and policies
  • Access to all assertions in the generated policy
Once a service is published, the Manage [serviceName] Service role can be used to give users Administrator-like powers for that specific service only. For more information, see Predefined Roles and Permissions.
It is possible to manually create a reverse web proxy policy without this wizard, however it will require significantly more effort.
The Publish Reverse Web Proxy Wizard is not designed to proxy multiple web applications at once, but you can do so by executing the wizard multiple times. For more information, see Configure a Reverse Web Proxy. The SharePoint 2013 examples shown in this topic are based on a simple configuration of SharePoint that uses default settings. These examples may not apply if your configuration is more advanced.
To access the Publish Reverse Web Proxy Wizard, do either of the following
:
  • Click
    Publish Reverse Web Proxy
     on the Home Page
  • Select [
    Tasks
    ] >
    Services and APIs > Publish Reverse Web Proxy
     from the Main Menu.
  • Right-click a within the list and then select
    Publish Reverse Web Proxy
    .
Complete the wizard as described below. Once the wizard is complete, a new service is published containing a policy for the
API Gateway
 to behave as a reverse web proxy.
Recommended Wizard Configurations
The following settings are recommended if SharePoint is the web app being proxied:
  • If the SharePoint server is unaware of the
    API Gateway
     proxy, it is recommended that you accept all the default values in the wizard (with the exception of Name and Target Host, which must be completed).
  • If the SharePoint server expects all traffic on port 80 and all
    API Gateway
     traffic on port 80 has been configured to redirect to the default HTTP port (via Managing Listen Ports, [Manage Firewall Rules]), it is recommended that you deselect the
    Include request port
     check box.
  • If the SharePoint server is configured with an alternate access mapping for the proxy, it is recommended that you do not configure any URL rewriting except for the Host header.
  • When proxying for SharePoint, you need to add the following advanced property to the HTTP listen port: 
trimContentType=false
  • When proxying for SharePoint, it is recommended that you set the
    mtom.decodeSecuredMessages
     cluster property to 'false'. 
Step 1: Configure Reverse Web Proxy
The Configure Reverse Web Proxy step collects information required to build the correct service policy.
  1. Enter the
    Name
     of the published service that will be created. This name will be displayed in the services and policies list.
  2. Enter the resolution URI for the service. This is the endpoint that will receive the service requests. The default is *.
  3. Specify the Web Application Properties:
    • Choose the type of web app from the
      Platform
       drop-down list:
      SharePoint
       or
      Generic
      . This determines whether a web app-specific policy is created.
      Only SharePoint 2013 is currently supported. The 'Generic' option will produce a generic proxy policy that will likely need to be modified for your web application before it can be used.
    • Enter the
      Target Host
      . This is the host for which the
      API Gateway
       will be serving as a reverse proxy. Include the port number if applicable.
    • Select
      Use HTTPS
       to use a secure connection when routing to the web application.
    The remaining settings in this wizard step are used to configure URL Rewriting.
  4. Configure whether URL Rewriting should be performed on the
    Request
    .
    To reverse any of the settings below after the policy has been created, simply disable or enable the associated assertion.
    • Select the
      Body
       check box to replace all occurrences of the
      API Gateway
       host in the request body with the web application host, using the Evaluate Regular Expression Assertion in the generated service policy.
      Clear this check box to disable the above assertion in the generated service policy and not rewrite the request body.
      To enable request rewriting, simply re-enable this assertion.
    • Select the
      Query String
       check box to rewrite the request query string to reference the web application host instead of the request host, using the Evaluate Regular Expression Assertion in the generated service policy.
      Clear this check box to disable the above assertion in the generated service policy and not rewrite the query string. 
    • Select the
      Host Heade
      r check box to rewrite the request Host header to reference request host, using the Manage Transport Properties/Headers Assertion.
      Clear this check box to disable the above assertion in the generated service policy and not rewrite the Host Header.
  5. Configure whether URL Rewriting should be performed on the
    Response
    :
    • Select the
      Body
       check box to enable URL rewriting on the Response body, using the Evaluate Regular Expression Assertion in the generated service policy.
      Clear the check box to disable the assertion and not permit rewriting.
    • If rewriting is permitted, indicate whether to replace
      All
       occurrences of the web application host in the response body with the
      API Gateway
       host, or whether to replace only
      Within specified HTML tags
       in the adjacent box.
    • Select the
      Location Header
       check box to rewrite the response location headers (in other words, enable assertions that will replace specific instances of the web application host in the location header with the
      API Gateway
      host).
      Clear this check box to disable the location-rewriting assertions in the resulting service policy.
  6. Select the
    Cookie
     check box to rewrite the request Cookie and response Set-Cookie headers (in other words, reconfigure the domain and path—and name if SharePoint is selected—of the cookies).
    Clear this check box to disable the cookie-rewriting assertions in the resulting service policy.
  7. Select the
    Include
     request port check box to include the request port during URL rewriting.
  8. Clear this check box to exclude the request port during URL rewriting.
    Clear this check box if the web application expects all HTTP traffic on port 80 and there is an alternate access mapping for the proxy.
Step 2: Access Control
The Access Control step allows you to define access control and authentication rules for non-SOAP applications.
  1. Optionally select the 
    Require SSL/TLS Encryption
     check box to require that all requestors consume the reverse web proxy service through the SSL entry point.
  2. Choose an access control option:
    • Allow Anonymous Access
      : Permit requestors to access the service anonymously (without credentials).
    • Require Users to Authenticate
      : Require that requestors provide credentials to gain web service access. Define the authentication details for this option as follows:
      • Authentication Method
        : Choose an authentication method from the drop-down list. This determines what information users and groups are required to provide to gain application access.
      • Identity Provider
        : Choose an from the drop-down list that contains the authorized users and groups.
        When requiring users to authenticate, the access will be restricted to the identity providers indicated above. The policy will initially be populated with an authentication assertion for each assertion corresponding to each selected identity.
  3. Specify which users and groups are authorized to use the reverse proxy web service by moving them between the 
    No Permission
     and 
    Have Permission
     lists:
    • Grant permission by selecting entries from 
      No Permission
       and then clicking [Add]. Alternatively, click [
      Add All
      ] without selecting any entry to authorize everyone on the list.
    • Deny permission by selecting entries from 
      Have Permissio
      n and then clicking [
      Remove
      ]. Alternatively, click [
      Remove All
      ] without selecting any entry to deny permission to everyone on the list
      You can select a continuous block of rows by dragging the mouse over the rows you want; or, select the first row, hold down the [Shift] key, then select the last row. You can select individual rows by holding down the [
      Ctrl
      ] key while clicking on the rows you want.
  4. If you need to authorize users or groups from another identity provider, select the new provider name from the Identity Provider drop-down list and then repeat step 3.
  5. Optionally choose a security zone. To remove this entity from a security zone (security role permitting), choose "No security zone."
    This control is hidden if either: (a) no security zones have been defined, or (b) you do not have Read access to any security zone (regardless of whether you have Read access to entities inside the zones).
 

Content feedback and comments