3.6 Configuring the Access Gateway

3.6.1 Configuring a Reverse Proxy

You can protect your Web services by creating a reverse proxy. A reverse proxy acts as the front end to your Web servers in your DMZ or on your intranet. It off-loads frequent requests, thereby freeing up bandwidth and Web server connections. It also increases security because the IP addresses and DNS names of your Web servers are hidden from the Internet. A reverse proxy can be configured to protect one or more proxy services.

To create a reverse proxy, you must create at least one proxy service with a protected resource. You must supply a name for each of these components. Reverse proxy names and proxy service names must be unique to the Access Gateway because they are configured for global services such as IP addresses and TCP ports. For example, if you have a reverse proxy named products and another reverse proxy named library, only one of these reverse proxies can have a proxy service named corporate.

Protected resource names need to be unique to the proxy service, but they don’t need to be unique to the Access Gateway because they are always accessed through their proxy service. For example, if you have a proxy service named account and a proxy service named sales, they both can have a protected resource named public.

What You Need To Know

Example

Your Value

Name of the Identity Server cluster

idp-corporate

_______________________

DNS name of the Access Gateway

mytest.com

______________________

Web server information

 

 

 

IP address

10.15.70.21

______________________

 

DNS name

mywebserver.com

______________________

Names you need to create

 

 

 

Reverse proxy name

mycompany

________________________

 

Proxy service name

company

________________________

 

Protected resource name

public

________________________

This first reverse proxy is used for authentication. You need to configure the proxy service to use the DNS name of the Access Gateway as its Published DNS Name, and the Web server and the resource on that Web server need to point to the page you want displayed to the users when they first access your Web site. You can use Access Gateway configuration options to allow this first page to be a public site with no authentication required until the users access the links on the page, or you can require authentication on this first page. Complete the following configuration steps to first configure a protected resource as a public resource and then to modify the configuration to require authentication.

  1. In the Administration Console, click Devices > Access Gateways, Edit > Reverse Proxy / Authentication.

  2. In the Identity Server Cluster option, select the configuration you have assigned to the Identity Server.

    This sets up the trust relationship between the Access Gateway and the Identity Server that is used for authentication.

  3. In Reverse Proxy List, click New, specify a display name for the reverse proxy, then click OK.

  4. Enable a listening address.

    Listening Address(es): A list of available IP addresses. If the server has only one IP address, only one is displayed and it is automatically selected. If the server has multiple addresses, you can select one or more IP addresses to enable. You must enable at least one address.

    TCP Listen Options: Options for configuring how requests are handled. You cannot set up listening options until you create a proxy service.

  5. Ignore the SSL configuration options.

    This basic configuration does not set up SSL. For SSL information, see Section 14.0, Enabling SSL Communication.

  6. Configure a listening port.

    Non-Secure Port: Select 80 that is the default port for HTTP.

    Secure Port: This is the HTTPS listening port. This port is unused and cannot be configured until you enable SSL.

  7. In Proxy Service List, click New.

  8. Specify the following details:

    Field

    Description

    Proxy Service Name

    A display name for the proxy service.

    Published DNS Name

    The DNS name you want the public to use to access your site. For this first proxy server, the DNS name must resolve to the Access Gateway IP address that you selected as the listening address. For the example in Figure 3-2, this name would be www.mytest.com.

    Web Server IP Address

    The IP address of your Web server. This is the Web server with content that you want to share with authorized users and protect from others. In Figure 3-2, this is Server 4, whose IP address is 10.15.70.21.

    Host Header

    The name you want to send in the HTTP header to the Web server. This can either be the published DNS Name (the Forward Received Host Name option) or the DNS name of the Web Server (the Web Server Host Name option).

    Web Server Host Name

    The DNS name that the Access Gateway should forward to the Web server. This option is not available if you select Forward Received Host Name for the Host Header option. The name you use depends upon how you have set up the Web server. If your Web server has been configured to verify that the host name in the header matches its name, you need to specify that name here. In Figure 3-2, the Web Server Host Name is mywebserver.com.

  9. Click OK.

  10. Continue with Section 3.6.2, Configuring a Public Protected Resource.

3.6.2 Configuring a Public Protected Resource

The first protected resource in discussed in this configuration is configured to be a public resource. For information on how to set up authentication for a protected resource, see Section 3.6.3, Configuring the Access Gateway for Authentication.

  1. In Proxy Service List, click [Name of Proxy Service] > Protected Resources.

  2. In Protected Resource List, click New, specify a name for the resource, and click OK.

  3. In the Contract field, select None.

    The Contract field must be set to None. This is makes this resource a public resource.

  4. Configure URL Path List.

    The default path is /*, which allows access to everything on the Web server. Modify this if you need to restrict access to a specific directory on your Web server.

    • To delete the default path, select the check box next to the path, then click Delete.

    • To edit a path in the list, click the path, modify it, then click OK.

    • To add a path, click New, specify the path, then click OK. For example, to allow access to the pages in the public directory on the Web server, specify the following path:

      /public/*
      
  5. Click OK.

  6. In the Protected Resource List, verify that the protected resource you created is enabled, then click OK.

  7. Click Devices > Access Gateways.

  8. Click Update > OK.

    The system sends configuration changes to the server and writes the configuration to the configuration data store. When the update has completed successfully, the server returns the status of Current.

    To save the changes to the configuration store without applying them, do not click Update. Instead, click Edit. If you have pending configuration settings, the OK button is active, and the configuration page indicates which services will be updated. Click OK to save these changes to the configuration store. The changes are not applied until you Update on the Access Gateways page.

  9. To update the Identity Server to establish the trust relationship with the Access Gateway, click Devices > Identity Servers > Update > OK.

    Wait until the Command status is Complete and the Health status is green.

  10. (Optional). To test this configuration from a client browser, specify the published DNS name as the URL in the browser. In the example illustrated in Figure 3-2, specify the following URL:

    http://www.mytest.com
    

    This should resolve to the published DNS name you specified in Step 8, and the user should be connected to the Web server through the Access Gateway.

  11. Continue with Section 3.6.3, Configuring the Access Gateway for Authentication.

3.6.3 Configuring the Access Gateway for Authentication

The procedures in Section 3.6.1, Configuring a Reverse Proxy and Section 3.6.2, Configuring a Public Protected Resourceset up the Access Gateway to protect your Web server by hiding its IP address and DNS name from Internet users. The procedure does not require the user to log in before accessing resources on the Web server. This section explains how to configure the Access Gateway so that the users are required to provide login credentials before they access to a protected resource. This configuration consists of two parts:

Verifying Time Synchronization

The time must be synchronized between the Identity Server and the Access Gateway or set so the time difference is within one minute of each other for trusted authentication to work.

For the Identity Server or a Linux Access Gateway Service, use YaST to verify the time settings. For a Windows Access Gateway Service, use the Date and Time option in the Control Panel. If you have a Network Time Protocol server, configure the Access Manager machines to use it.

For an Access Gateway Appliance, complete the following steps:

  1. In the Administration Console, click Devices > Access Gateways> Edit > Date & Time.

  2. Select a method you want to use for time:

    Set Date & Time Manually: Allows you to select the current time. Click this option to select year, month, day, hour, and minute in your current time zone, then click OK.

    Set Up NTP: Allows you to specify the IP address of an NTP server. Click Set Up NTP. Use the public pool.ntp.org server or click New, then specify the IP address of an NTP server. To accept the configuration, click OK.

    If the time on the machine is wrong by more than an hour, use both methods to set the time. Set it manually first, and then configure it to use NTP.

  3. In the Time Zone section, select your time zone, then click OK.

    Regardless of the method you used to set the time, you must select a time zone.

  4. Click OK.

  5. Click Devices > Access Gateways > Update > OK.

    Continue with Enabling Trusted Authentication.

Enabling Trusted Authentication

Trusted authentication requires an authentication contract that specifies the type of authentication credentials. The Identity Server and the Access Gateway control these authentication requirements. You do not need to configure your Web server to require authentication. Access Manager enforces the requirements for you.

In this example, you set up an authentication contract that requires a username and a password to access a directory on a Web server.

  1. In the Administration Console, click Devices > Access Gateways, then click Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > Protected Resources > New.

  2. Specify a display name for the protected resource, then click OK.

  3. Select one of the following in Authentication Procedure:

    Name/Password - Basic: Basic authentication over HTTP using a standard login page provided by the Web browser.

    Name/Password - Form: Form-based authentication over HTTP.

    Others are available, but for this basic setup, which does not enable SSL, select one of the above contracts. The contract needs to match the protocol.

    If these default authentication contracts are not available, you have not configured a relationship between the Access Gateway and the Identity Server. See Section 3.6.1, Configuring a Reverse Proxy and select a value for the Identity Server Cluster field.

  4. In URL Path List, configure the URL path to the page that this authentication contract will protect. For the Web server configuration described in Prerequisites for Setup, click the /* path and modify it to specify the following path:

    /protected/*
    
  5. Click OK > OK.

  6. Click Devices > Access Gateways > Update > OK.

  7. (Optional) To test this configuration from a client browser, log in to the Access Gateway:

    1. Specify the published DNS name to this resource in the browser. For the example illustrated in Figure 3-2, you would specify the following URL:

      http://www.mytest.com
      
    2. Click the link to the protected page. This should be a link to the same page you configured in Step 4.

      Your browser should prompt you with a login page. If you selected Name/Password - Basic as the contract, the standard login page issued by your browser is displayed. If you selected Name/Password - Form, the default Access Manager login page is displayed.

    3. Log in to the Identity Server with a username and password that is stored in your LDAP directory (Server 3 in Figure 3-2).

      You should have access to the information you have placed in the protected directory on your Web server.

      If you have set up your Web server to require basic authentication to access this directory, you are prompted again for login credentials.

      If you receive an error, see Common Authentication Problems.

  8. Continue with Setting Up Policies.

3.6.4 Setting Up Policies

The Access Gateway lets you retrieve information from your LDAP directory and inject the information into HTML headers, query strings, or basic authentication headers. The Access Gateway can then send this information to the back-end Web servers. Access Manager calls this technology Identity Injection.

This is one of the features within Access Manager that enables single sign-on. Users are prompted for the login credentials for one time, and Access Manager then supplies them for the resources you have configured for Identity Injection.

This section explains how to set up an Identity Injection policy for basic authentication. This policy is assigned to the third directory on your Web server, which is the basic directory that your Web server has been configured to require basic authentication before allowing access.

  1. In the Administration Console, click Devices > Access Gateways > Edit > [Reverse Proxy Name] > [Proxy Service Name] > Protected Resources > New.

  2. Configure the resource for the basic directory as described in Section 3.2, Prerequisites for Setup:

    1. For the contract, select Name/Password - Basic or Name/Password - Form.

    2. For the URL path, specify the path to the basic directory (/basic/*).

    3. Click OK.

  3. Click [Protected Resource Name] > Identity Injection.

    On a new installation, the list is empty because no policies have been created.

  4. In the Identity Injection Policy List section, click Manage Policies.

  5. In the Policy List section, click New, then specify values for the following fields:

    Name: Specify a name for the Identity Injection policy.

    Type: Select Access Gateway: Identity Injection.

  6. Click OK.

  7. (Optional) Specify a description for the policy.

  8. In the Actions section, click New > Inject into Authentication Header.

  9. Set up the policy for User Name and Password:

    • For User Name, select Credential Profile and LDAP Credentials: LDAP User Name.

      This injects the value of the cn attribute into the header.

    • For Password, select Credential Profile and LDAP Credentials: LDAP Password.

    The policy should look similar to the following:

  10. Click OK > OK > Apply Changes > Close.

  11. Select the new Identity Injection policy, then click Enable > OK.

  12. Click Devices > Access Gateways > Update > OK.

  13. To test this configuration from a client browser, specify the published DNS name as the URL in the browser. Click the link to the page that uses basic authentication.

    You are prompted to log in. If you have set up Web applications on your Web server that require login, any additional login prompts are hidden from the user and are handled by the identity injection system.

For an example of how Identity Injection policies can be used for single sign-on to the Identity Manager User Application, see “Configuring Access Manager for UserApp and SAML”.