Setting Up a Protected Resource

Click Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > Protected Resources.
Click the name of an existing resource or click New and specify a display name for the resource.
(Optional) Specify a description for the protected resource. You can use it to briefly describe the purpose for protecting this resource.
Select the type of contract to use for the authentication procedure. The contract determines the information a user must supply for authentication. By default, Administration Console allows you to select from the following contracts and options when specifying whether a resource requires an authentication contract:

None: If you want to allow public access to the resource and not require an authentication contract, select None.

Any Contract: If the user has authenticated, this option allows any contract defined for Identity Server to be valid, or if the user has not authenticated, it prompts the user to authenticate, using the default contract assigned to Identity Server configuration.

Name/Password - Basic: Specifies basic authentication over HTTP, using a standard login pop-up provided by the web browser.

Name/Password - Form: Specifies a form-based authentication over HTTP or HTTPS, using the Access Manager login form.

Secure Name/Password - Basic: Specifies basic authentication over HTTPS, using a standard login pop-up provided by the web browser.

Secure Name/Password - Form: Specifies a form-based authentication over HTTPS, using the Access Manager login form.

The contract also determines the session timeout for inactive connections. If you have some resources that need to time out quickly to protect sensitive data and other resources that don’t need this kind of protection, you need to configure contracts for these resources. For more information about this feature, see Assigning a Timeout Per Protected Resource.

If no contracts are available, you have not configured a relationship between Access Gateway and Identity Server. See Managing Reverse Proxies and Authentication.
(Conditional) To modify how the authentication procedures are handled for a specific resource and contract, click the Edit Authentication Procedures icon.

For more information, see Configuring an Authentication Procedure for Non-Redirected Login.
Configure the URL Path.

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

If you have multiple directories on your web server that require the same authentication contract and access control, add each directory as a URL path.

New: To add a path, click New, specify the path, then click OK. For example, to allow access to all the pages in the public directory on the web server, specify the following path:
```
/public/*
```
To allow access to all the files in a directory, but not to the subdirectories and their files, specify the following:
```
/?
```
```
/public/?
```
The /? allows access to the root directory, but not the subdirectories. The /public/? allows access to the files in the public directory, but not the subdirectories.

To allow access to files of a specific type, specify the following:
```
/public/*.pdf
```
This allows access to all the files in the public directory that have a PDF extension. Access to other file types and subdirectories is denied.

To use this protected resource to protect a single page, specify the path and the filename. For example, to protect the login.html page in the /login directory, specify the following:
```
/login/login.html
```
This is the type of URL path you want to specify when you create a Form Fill policy for a protected resource. The URL Path List normally contains only this one entry. If you have multiple pages that the Form Fill policy applies to, list each one separately in the list. For optimum speed, you want Access Gateway to be able to quickly identify the page and not search other pages to see if the policy applies to them.

For more information about how a user’s request is matched to a protected resource, see Understanding URL Path Matching.

For information about using a query string, see Using a Query String in the URL Path.

Modify: To modify a path, click the path link, then modify the URL Path.

Delete: To delete a path, select the path, then click Delete.
Click OK.
In the Protected Resource List, ensure that the protected resource you created is enabled.
(Optional) To add policies for protecting this resource, continue with one of the following:
To apply your changes, click the Access Gateways link, then click Update > OK.

Workaround If URL Rewriting Fails

The format and protocols in a WebSocket connection are not visible to Access Manager and hence it cannot change the protocols.

Some WebSocket applications dynamically frame the WebSocket URI, such as or from the previous response (other than HTML) and interrupts the connection. In such cases, rewriting the URL might not function properly.

For example, if you have configured a proxy service that protects the backend WebSocket application as a Path Based Multi-Homing service and if you have selected the Remove Path on Fill option, the WebSocket application can fail.

Perform the following steps if URL rewriting fails:

Create a character profile to replace the path (path used to frame next request) in the response with the configured path appended before.
Delete the text/html content-type under the And Document Content-Type Header Is section.

For example, If the path configured in proxy service is /test and Remove Path on Fill is selected, the ws URI will be similar to

In this scenario, you must create a character rewriter profile to Search for the string /socket.io and replace with /test/socket.io.

In case of request framing from HTML response, character profile is not required.

NOTE:Content rewriting is not supported after a WebSocket connection is established.

Understanding URL Path Matching

The URL path determines which protected resource is used for a user request. Suppose you create one protected resource with the following URL paths:

/*
/test/*
/test/

You create a second protected resource with the following path:

/test/*.php

Users then send the following paths in their access requests:

/test/ 
/test/1/2/3/file.php
/file.php
/test/file.php
/test/file.php?param1=1234

The first three requests (/test/, /test/1/2/3/file.php, and /file.php) match the first protected resource, and the last two requests (/test/file.php and /test/file.php?param1=1234) match the second protected resource.

You then add the following URL path to the first protected resource:

/test/?

This URL path in the first protected resource causes all the requests to match the first protected resource, and the second protected resource is ignored. The ? wildcard, which matches all content in the current directory, takes precedence over the more specific wildcard (*.php).

Using a Query String in the URL Path

You can specify a query string in the URL path of a protected resource. For example:

URL path: /test/index.html?test=test

When the requested URL has a query string, Access Gateway searches for a protected resource with a matching URL path and query string. If it can’t find a match, the request returns a resource not found error.

Access Gateway Appliance allows you to configure the URL matching process so that it ignores the query string in the URL path. Access Gateway Service does not have this option. If you want the query string ignored, you must remove it from the URL path of the protected resource.