1.4 Configuring Protected Resources for Specific Applications

1.4.1 Configuring Protected Resource for a SharePoint Server

You can protect a SharePoint server as a domain-based or a path-based multi-homing resource on the Linux Access Gateway Appliance. When you protect a SharePoint server on Linux Access Gateway, you might see issues with rewriting if the published DNS name is not the same as the DNS name of the original server. Also, if you access SharePoint folder by using non-browser clients such as Microsoft Network Place, Nautilus in SUSE Linux Enterprise Server (SLES), or the MAC finder, you might see issues because these WebDAV clients do not support 302 redirection for authentication. You must modify the authentication procedure to prevent redirection on initial authentication or redirection to Identity Server when the user session expires.

For more information on how to configure a protected resource for a SharePoint server, see Novell Cool Solutions.

1.4.2 Configuring a Protected Resource for a SharePoint Server with an ADFS Server

If your SharePoint server is configured to use an ADFS server and you want to create a protected resource for the SharePoint server, you need to configure the following Access Manager features. The instructions assume that you have a functioning SharePoint server and a functioning Access Manager system:

Configuring a Custom Contract

ADFS requires a different format for a contract URI than the format used in the default contracts. It expects the URI to conform to the format of a URL. You need to create a custom contract.

  1. In the Administration Console, click Devices > Identity Servers > Servers > Edit > Local > Contracts

  2. Click New, then fill in the following fields:

    Display name: Specifies the name of the authentication contract.

    URI: Specifies a value that uniquely identifies the contract from all other contracts. No spaces can exist in the URI field. For SharePoint, specify the following format for the URI:

    https://<baseurl>/name/password/uri
    

    Replace <baseurl> with the base URL of your Identity Server. If the DNS name of your Identity Server is idp-50.amlab.net, the URI would have the following format:

    https://idp-50.amlab.net:8443/nidp/name/password/uri
    

    Methods and Available Methods: Move a name/password method to the Methods list. We recommend Secure Name/Password - Basic, but you can use Name/Password - Basic.

    Do not configure a password expiration servlet. This contract is going to be used with non-redirected login, which prevents all redirection, including redirection to a password expiration service.

    For more information on the other options, see Configuring Authentication Contracts in the Novell Access Manager 3.1 SP2 Identity Server Guide.

  3. Click Next.

  4. Configure a card for the contract by filling in the following:

    Text: Specify the text that is displayed on the card to the user.

    Image: Specify the image to be displayed on the card. To use an existing image, select an image from the drop-down list. To add an image to the list, click Select local image.

    Show Card: Determine whether the card is shown to the user, which allows the user to select and use the card for authentication. If this option is not selected, the card is only used when a service provider makes a request for the card.

  5. Click Finish, then OK.

  6. Update the Identity Server and the Access Gateway.

  7. Continue with Creating a Reverse Proxy Service.

Creating a Reverse Proxy Service

  1. In the Administration Console, click Devices > Access Gateways > Edit > [Name of Reverse Proxy].

  2. In the Proxy Service List section, click New.

  3. Fill in the following fields:

    Proxy Service Name: Specify a display name for the proxy service that the Administration Console uses for its interfaces.

    Multi-Homing Type: Select Domain-Based as the multi-homing method that the Access Gateway should use to identify this proxy service.

    Published DNS Name: Specify the DNS name you want the public to use to access the SharePoint server. This DNS name must resolve to the IP address you set up as the listening address.

    If the DNS name of the reverse proxy is the same as the DNS name of the SharePoint server, no rewriting configuration is required. If they are different, there is a high probability that the application will respond incorrectly to user requests.

    Web Server IP Address: Specify the IP address of the IIS Web server with the SharePoint server.

    Host Header: Select the Web Server Host Name option.

    Web Server Host Name: Specify the DNS name of the SharePoint server that the Access Gateway should forward to the Web server.

    For more information on creating a reverse proxy, see Section 1.1, Managing Reverse Proxies and Authentication

  4. Click OK.

  5. Continue with Configuring Multiple Protected Resources.

Configuring Multiple Protected Resources

If your SharePoint server has been configured for multiple domains, you need to create three protected resources to enable single sign-on. The server has two ways to access the home page. You need to create a protected resource for each of these paths, and then a protected resource for the other pages. These protected resources should have a configuration similar to the following:

SharePoint Page

URL Path

Contract

Authentication Procedure

home page

default.aspx

custom

Normal

root

/

custom

Normal

all others

/*

custom

Non-redirected login

For single sign-on, all the protected resources need to specify the same contract. When assigning the contract for the /* resource, the contract needs to be configured to use non-redirected login for its authentication procedure. When a user first accesses the SharePoint server, the users are directed either to the home page or the root of the server. From either of these locations, the users can be redirected to the Identity Server for authentication. After the users have authenticated and the SharePoint server requests authentication for access to any of the other pages, these pages need to be configured to use non-redirected login.

  1. In the Proxy Service List, click the name of the Proxy Service you created, then click Protected Resources.

  2. To create a protected resource for the home page:

    1. In the Protected Resource List, click New, specify a name such as homepage, then click OK.

    2. For the home page of the SharePoint server, specify the following values:

      Authentication Procedure: Select the custom contract you created.

      URL Path: Click /* and replace it with default.aspx, then click OK twice.

  3. To create a protected resource for the root page:

    1. In the Protected Resource List, click New, specify a name such as root, then click OK.

    2. For the root of the SharePoint server, specify the following values:

      Authentication Procedure: Select the custom contract you created.

      URL Path: Click /* and remove the asterisk, then click OK twice.

  4. To create a protected resource for all other pages:

    1. In the Protected Resource List, click New, specify a name such as allothers, then click OK.

    2. For all other pages of the SharePoint server, specify the following values:

      Authentication Procedure: Select the custom contract you created.

      URL Path: Leave the default value.

    3. Click the Edit Authentication Procedures icon on the Authentication Procedure line.

    4. Click the name of your custom contract, then fill in the following:

      Non-Redirected Login: Select this option.

      Realm: Specify a name that your users associate with the SharePoint server. This name is displayed when the user needs to reauthenticate.

      For more information about this feature, see Section 1.3.2, Configuring an Authentication Procedure for Non-Redirected Login.

  5. Click OK three times.

    In the Protected Resource List, you should have three protected resources that use the same Authentication Procedure.

    For information on configuring protected resources, see Section 1.3.1, Setting Up a Protected Resource.

  6. Click Access Gateways, then update the Access Gateway.

  7. (Conditional) If you have limited your users to one session, modify this limitation:

    1. Click Devices > Identity Servers > Edit.

    2. Increase the value of the Limit user sessions option.

    3. Click OK, then update the Identity Server.

1.4.3 Configuring a Protected Resource for Outlook Web Access

If you want to protect your Outlook Web Access server with the Access Gateway Appliance, you need to configure the following Access Manager features. The instructions assume that you have a functioning Outlook Web Access server and a functioning Access Manager system:

Configuring a Protected Resource for Outlook Web Access

The following instructions assume that you have a basic setup with at least one reverse proxy and proxy service. If you don’t have this basic setup, see Section 1.1, Managing Reverse Proxies and Authentication and complete a basic setup before continuing.

  1. In the Administration Console, click Devices > Access Gateways > Edit > [Name of Reverse Proxy].

  2. In the Proxy Service List section, click New.

  3. Specify a name for the proxy service, then click OK.

  4. Click the newly added proxy service. Fill in the fields:

    Proxy Service Name: Specify a display name for the proxy service, which the Administration Console uses for its interfaces.

    Published DNS Name: Specify the DNS name you want the public to use to access your site. This DNS name must resolve to the IP address you set up as the listening address.

    Multi-Homing Type: Select the multi-homing method that the Access Gateway should use to identify this proxy service.

    Web Server IP Address: Specify the IP address of the IIS Web server.

    Host Header: Select the Web Server Host Name option.

    Web Server Host Name: Specify the DNS name of the Outlook Web Access server that the Access Gateway should forward to the Web server.

  5. Click OK.

  6. Continue with Configuring an Authentication Procedure.

Configuring an Authentication Procedure

  1. Click Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > Protected Resources.

  2. Click New, then specify a display name for the resource.

  3. (Optional) Specify a description for the protected resource. You can use it to briefly describe the purpose for protecting this resource.

  4. Select an authentication contract. If you want to enable non-redirected login, select Name/Password - Basic as the authentication contract.

  5. (Optional) If you want to enable non-redirected login, click the Edit Authentication Procedure icon, then click the contract that you have added to specify the following information:

    Non-Redirected Login: Select the option to enable non-redirected login.

    Realm: Specify the security realm configured for the IIS server running the Outlook Web Access server.

    To check the security realm configured for the IIS server, open the IIS Administration Console, right-click the Outlook Web Access Server the Access Gateway is protecting, then select Properties. The Directory Security tab contains the Security realm field.

  6. Create protected resource:

    1. In the Protected Resource List, click New, specify a name such as root, then click OK.

    2. Specify the following values:

      Authentication Procedure: Select the contract you created.

      URL Path: Make sure that /* is selected. If you have configured Outlook Web Access as a path-based service, then click the URL path and add the path name of the service. For example, /owa/*, where owa is the path name.

      Click OK twice.

  7. Create a second protected resource:

    1. In the Protected Resource List, click New, specify a unique name, then click OK.

    2. Specify the following values:

      Authentication Procedure: Do not select any authentication procedure because the URL path is a public resource.

      URL Path: Specify /exchweb/*as the URL path. If you have configured Outlook Web Access as a path-based service, click the URL path and add the path name of the service. For example, /owa/exchweb/*, where owa is the path name.

      Click OK twice.

  8. Click OK.

  9. In the Protected Resource List, ensure that the protected resource you created is enabled.

  10. If you want to enable single sign-on, then configure Identity Injection or Form Fill policy, depending on the Outlook Web Access configuration. For more information, see Configuring Identity Injection.

  11. Continue with Configuring a Rewriter Profile.

Configuring a Rewriter Profile

  1. In the Administration Console, click Devices > Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > HTML Rewriting.

  2. Click New in the HTML Rewriter Profile List.

  3. Configure a Word profile:

    1. Specify a name for the profile, select Word as the search boundary, then click OK.

    2. Click New in the Variable or Attribute Name to Search for Is section, then specify value.

    3. Click OK.

    4. Select Rewrite Inbound Query String Data.

    5. Select Rewrite Inbound Post Data.

    6. Select Rewrite Inbound Headers.

    7. Make sure that Enable Rewrite Actions remains selected.

  4. (Optional) If you have configured the path-based multi-homing service, do the following:

    1. Add the following content types for the And Document Content-Type Header Is option in the Word profile:

      • text/x-component

      • extension/htc

    2. Configure the following options for Strings to Search for Is:

      • Specify Search as /exchange and Replace With as $path/exchange

      • Specify Search as /exchweb and Replace With as $path/exchweb

  5. To save your changes to browser cache, click OK.

  6. Use the up-arrow button to move your profile to the top of the HTML Rewriter Profile List.

  7. To apply your changes, click the Access Gateways link, then click Update > OK.

Configuring Identity Injection

You must configure an Identity Injection policy in order to enable single sign-on with the Outlook Web Access server that has basic authentication configured. This Identity Injection policy should be configured to inject an authentication header. For information on creating this policy, see Configuring an Authentication Header Policy in the Novell Access Manager 3.1 SP2 Policy Guide.

1.4.4 Configuring a Protected Resource for a Novell Teaming 2.0 Server

The following sections explain how to configure the Access Gateway with a domain-base multi-homing service. The instructions assume that you have a functioning Novell Teaming 2.0 server on Linux and a functioning Access Manager system (3.1 SP1 IR1 or higher) with a reverse proxy configured for SSL communication between the browsers and the Access Gateway.

The Teaming server needs to be configured to trust the Access Gateway to allow single sign-on with Identity Injection and to provide simultaneous logout. You also need to create an Access Gateway proxy service and configure it.

For information on other possible Access Gateway configurations, see “Teaming 2.0: Integrating with Linux Access Gateway”.

Configuring the Teaming Server to Trust the Access Gateway

To use Teaming as a protected resource of an Access Gateway and to use Identity Injection for single sign-on, the Teaming server needs a trusted relationship with the Access Gateway. With a trusted relationship, the Teaming server can process the authorization header credentials. The Teaming server accepts only a simple username (such as user1) and password in the authorization header.

This section explains how to set up the trusted relationship and how to enable simultaneous logout, so that when the user logs out of Teaming, the user is also logged out of the Access Gateway.

To configure the trusted relationship:

  1. Log in to the Teaming server.

  2. Stop the Teaming server with the following command:

    /etc/init.d/teaming stop

  3. Run the installer-teaming.linux script.

  4. Follow the prompts, then select Reconfigure settings.

  5. Follow the prompts, then select Advanced installation.

  6. Follow the prompts, selecting the defaults until the Enable Access Gateway option appears, then type Yes.

  7. In the Access Gateway address(es) section, include the IP address of the Access Gateway that is used for the connection to the Teaming server.

    If the Access Gateway is part of a cluster, add the IP address for each cluster member. Wildcards such as 164.99.*.* are allowed.

    When you specify IP addresses in this option, Teaming logins are allowed only from the specified addresses. Also, if Authorization header credentials are not present or are incorrect, the user is prompted for login using Basic Authentication.

  8. When prompted for the Logout URL, specify the URL of the published DNS name of the proxy service plus /AGLogout.

    For example, if the published DNS name of the proxy service is teaming.doc.provo.novell.com, specify the following URL:

    https://teaming.doc.provo.novell.com/AGLogout
    
  9. When you are prompted to use the Access Gateway for WebDAV connections, type No.

  10. Follow the prompts to complete the reconfiguration process.

  11. Start the Teaming server with the following command:

    /etc/init.d/teaming start

  12. Continue with Configuring a Domain-Based Multi-Homing Service for Novell Teaming.

Configuring a Domain-Based Multi-Homing Service for Novell Teaming

The following instructions describe how to set up a domain-based service to protect the Teaming server. In this example, the published DNS name of the service is teaming.doc.provo.novell.com. Users would access the Teaming server with a URL similar to http://teaming.doc.provo.novell.com/teaming. The /teaming path is the default access path for the Teaming application.

To configure a domain-based service for Teaming, complete the following tasks:

Configuring the Domain-Based Proxy Service
  1. In the Administration Console, click Devices > Access Gateways > Edit > [Name of Reverse Proxy].

  2. In the Reverse Proxy List, click New, then fill in the following fields:

    Proxy Service Name: Specify a display name for the proxy service that the Administration Console uses for its interfaces.

    Multi-Homing Type: Select Domain-Based.

    Published DNS Name: Specify the DNS name you want the public to use to access your site. This DNS name must resolve to the IP address you set up as the listening address. For example, teaming.doc.provo.novell.com.

    Web Server IP Address: Specify the IP address of the Novell Teaming server.

    Host Header: Select the Web Server Host Name option.

    Web Server Host Name: Specify the DNS name of the Teaming server.

  3. Click OK.

  4. Click the newly added proxy service, then select the Web Servers tab.

  5. Change the Connect Port to 8080.

    If the Teaming server has port forwarding enabled, you do not need to change from the default port 80.

  6. Click TCP Connect Options.

  7. Change the value of Data Read Timeout option to 1200 seconds.

    This longer timeout is needed for file uploads.

  8. Click OK.

  9. Continue with Configuring Protected Resources.

Configuring Protected Resources

You need to create two protected resources, one for HTML content and one for WebDAV and AJAX content.

  1. Click Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > Protected Resources.

  2. Create a protected resource for HTML content:

    1. In the Protected Resource List, click New, specify a name, then click OK.

    2. (Optional) Specify a description for the protected resource. You can use it to briefly describe the purpose for protecting this resource.

    3. Specify a value for Authentication Procedure. For example, select the Secure Name/Password - Form contract.

    4. In the URL Path List, remove the /* path and add the following two paths:

      /teaming/*
      /ssf/*
      
    5. Click OK.

  3. Create a protected resource for WebDAV and AJAX content:

    1. In the Protected Resource List, click New, specify a unique name, then click OK.

    2. (Optional) Specify a description for the protected resource. You can use it to briefly describe the purpose for protecting this resource.

    3. Click the Edit Authentication Procedure icon.

    4. In the Authentication Procedure List, click New, specify a name, then click OK.

    5. Fill in the following fields:

      Contract: Select the Secure Name/Password - Form contract, which is same contract that you selected for the HTML content protected resource.

      Non-Redirected Login: Select this option.

      Realm: Specify a name that you want to use for the Teaming server. This name does not correspond to a Teaming configuration option. It appears when the user is prompted for credentials.

      Redirect to Identity Server When No Authentication Header is Provided: Deselect this option.

    6. Click OK twice.

    7. For the Authentication Procedure, select the procedure you just created.

    8. In the URL Path List, remove the /* path and add the following two paths:

      /ssfs/*
      /ssf/a/do?*
      /ssf/rss/* 
      

      The /ssfs/* path is for WebDAV content, the /ssf/a/do?* path is for AJAX content, and the /ssf/rss/* path enables non-redirected login for RSS reader connections.

    9. Click OK.

  4. In the Protected Resource List, ensure that the protected resources you created are enabled.

  5. To apply your changes, click Devices > Access Gateways, then click Update.

  6. Continue with Configuring a Rewriter Profile.

Configuring a Rewriter Profile
  1. In the Administration Console, click Devices > Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > HTML Rewriting.

  2. In the HTML Rewriter Profile List, click New.

  3. Specify a name for the profile, select Word as the search boundary, then click OK.

  4. In the And Document Content-Type Header Is section, click New, then specify the following type:

    application/rss+xml
    
  5. In the Variable or Attribute Name to Search for Is section, click New, then specify the following as the variable to search for:

    value
    
  6. Click OK.

  7. Make sure that Enable Rewrite Actions remains selected.

  8. Click OK.

  9. In the HTML Rewriter Profile List, move the Word profile you created to be the first profile in the list, and move the default profile to be the second profile in the list.

  10. Click OK.

  11. To apply your changes, click Devices > Access Gateways, then click Update.

  12. Continue with Creating a Pin List.

Creating a Pin List

The Access Gateway needs to be configured to bypass the published URL of the proxy service:

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

  2. Click Pin List in the configuration page.

  3. Click New, then specify the published DNS name of the proxy service. For example, teaming.doc.provo.novell.com.

  4. Select Bypass as the Pin type.

  5. Click OK.

  6. To save the configuration changes, click Devices > Access Gateways, then click Update.

  7. Continue with Configuring Single Sign-On.

Configuring Single Sign-On

You must configure an Identity Injection policy to enable single sign-on with the Novell Teaming server. This Identity Injection policy should be configured to inject the authentication credentials into the authorization headers.

  1. In the Administration Console, click Policies > Policies.

  2. Select the policy container, then click New.

  3. Specify a name for the policy, select Access Gateway: Identity Injection for the type, then click OK.

  4. (Optional) Specify a description for the injection policy. This is useful if you plan to create multiple policies to be used by multiple resources.

  5. In the Actions section, click New, then select Inject into Authentication Header.

  6. Fill in the following fields:

    User Name: Select Credential Profile > LDAP User Name.

    Password: Select Credential Profile > LDAP Password.

  7. Click OK.

  8. To save the policy, click OK, then click Apply Changes.

    For more information on creating such a policy, see Configuring an Authentication Header Policy in the Novell Access Manager 3.1 SP2 Policy Guide.

  9. Assign this policy to the protected resources:

    1. Click Devices > Access Gateways > Edit > [Name of Reverse Proxy].

    2. Click the name of the teaming proxy service, then click the Protected Resources tab.

    3. For each teaming protected resource, click the Identity Injection link, select the Identity Injection policy, click Enable, then click OK.

    4. Click OK.

    5. To save the configuration changes, click Devices > Access Gateways, then click Update.