Configuring Access

C H A P T E R 4

Configuring Access

After you deploy Content Delivery Server, configure access to your system. You might want to run some components from behind a firewall or prevent access by external systems. You might also want to support a URL that is easy to remember.

This section presents the following topics:

Configure Content Delivery Server for a Firewall

Control Access by External Systems

Configure Alias Forwarding

Control Access to Sun Java System Application Server

4.1 Configure Content Delivery Server for a Firewall

Content Delivery Server generates URLs to access its components from external entities such as a subscriber’s device. If you are running Content Delivery Server behind a firewall, these URLs must be accessible from outside the firewall. The initial values used are the values set for the prefix.external.uri properties in the deployment configuration file, where prefix is the string used to identify the component. If you did not set these properties before you deployed, set the following properties in the CDS.properties file in the $CDS_HOME/deployment/deployment-name/conf directory.

default.external.catalogmanager.uri. Set this property to the published external URI of the web server for the Catalog Manager, for example:

default.external.catalogmanager.uri=http://webhost.domain.com:80/admin/

default.external.developerportal.uri. Set this property to the published external URI of the web server for the Developer Portal, for example:

default.external.developerportal.uri=http://webhost.domain.com:80/developer/

default.external.fulfillmentmanager.uri. Set this property to the published external URI of the web server for the Fulfillment Manager, for example:

default.external.fulfillmentmanager.uri=http://webhost.domain.com:80/fs/

default.external.vendingmanager.uri. Set this property to the published external URI of the web server for the Vending Manager, for example:

default.external.vendingmanager.uri=http://webhost.domain.com:80/vsadmin/

default.external.subscriberportal.uri. Set this property to the published external URI of the web server for the Subscriber Portal, for example:

default.external.subscriberportal.uri=http://webhost.domain.com:80/subscriber/

You must also set the Network ID for the Vending Manager Server account to the internal IP address of the host running the web server. Use the Catalog Manager administration console to update the Vending Manager Server account. See the “Adding Vending Manager Server Accounts” topic of the online help for more information.

Tip - To verify that the Catalog Manager can access the Vending Manager, start a browser on the host where the Catalog Manager is running. Point the browser to http://vending-manager-ip. If the page cannot be displayed, you must correct the domain name specified for the Vending Manager Server account associated with the Vending Manager that you want to access.

4.2 Control Access by External Systems

Content Delivery Server components are accessed through URLs that are generated from the internal and external URI properties set in the deployment configuration file (see Appendix A.) To prevent unauthorized access, set up the access control file with the rules needed to define what access is allowed. The default access control file allows access by all requestors.

Note - You do not need to stop the server to update the access control file. If you change the file while Content Delivery Server is running, the next request to the server forces the file to be reloaded. The new rules take effect immediately.

4.2.1 Access Control File

The access_control.config file in the $CDS_HOME/deployment/deployment-name/conf directory is used to determine when access to the Content Delivery Server components is allowed. This file contains the following types of statements:

Access control lists - One or more patterns of addresses to which the address of the source of the request is matched.

An access control list is identified by the keyword acl and a name that uniquely identifies the list. The list contains one or more address patterns. The format for the statement is acl acl-name {address-patterns}.

acl-name is a string of alphanumeric characters, including underscores, and must not match any keyword used in any statement. address-patterns is one or more host names, IP version 4 (IPv4) address masks, or IP version 6 (IPv6) address masks. For a complete description of this statement in Backus Naur Form (BNF) notation, see Appendix B.

URI groups - One or more relative paths for Content Delivery Server components to which the target of the request is matched.

A URI group is identified by the keyword uri_group and a name that uniquely identifies the group. The group contains one or more relative paths. The format for the statement is uri_group group-name {paths}.

group-name is a string of alphanumeric characters, including underscores, and must not match any keyword used in any statement. paths is one or more absolute URIs that include the servlet context name and are expressed as regular expressions. For a complete description of this statement in BNF notation, see Appendix B.

Rules - Statements that define the requests for access that are allowed and the requests that are denied.

A rule is identified by the keyword access and contains the following information:

Relative path to the Content Delivery Server resources to which access is requested

Protocol used in the request

Method used in the request

IP addresses from which the request is received

Status of the request, which is either allowed or denied

The format for a rule that references a URI group is
access group group-name protocol protocol method method {control-list}. group-name is the name given one of the URI groups in the file. protocol is the protocol used in the request and is either http, https, or any. method identifies the action requested and is either get, post, put, or any. control-list is a list of statements that indicate which addresses are allowed access and which addresses are denied access.

For a complete description of this statement in BNF notation, see Appendix B. For information on how the rules are interpreted, see the next section.

4.2.2 Access Control Process

When a request for access to a Content Delivery Server component is received, the rules in the access control file are used to determine if the access is allowed.

A rule is matched when the following conditions are met:

The component to which access is requested matches a path specified for the URI or URI group that the rule references.

The protocol used in the request matches the protocol specified in the rule.

The method used in the request matches the method specified in the rule.

The source of the request matches an address that is referenced in the control list.

The rules are processed in the order in which they appear in the file. The request is compared against all the rules in the file unless the keyword final is encountered. The last rule matched determines if access is allowed. In general, you want the more restrictive rules at the end of the file.

The final keyword stops the matching process. This keyword can appear at the beginning of the rule or at the end of any control list in a rule. If the keyword appears at the beginning of the rule, processing stops when the source of the request matches an address in any of the control lists in the rule. If the keyword appears at the end of a control list, the processing stops only when the source of the request matches an address in that control list.

When processing stops, the status of the request is determined by the keyword in the control list that contains the address of the source of the request. If the keyword is allow, access is allowed. If the keyword is deny, access is denied and the error code 404 is returned.

If no rules are matched, access is allowed. To deny access to all requests that do not match any rule, add the following rule at the beginning of your rules:

access uri ‘/.*’ protocol any method any {deny any;}

4.3 Configure Alias Forwarding

Alias forwarding is a technique for accepting a URL and redirecting the user to a different location. This feature enables you to provide subscribers with a URL that is easy to remember and redirect the request to the correct location. You can also use this feature to intercept requests and redirect them for special processing.

The mapping of URLs for Content Delivery Server is defined in the aliasforwarding.xml file. This file is in the $CDS_HOME/deployment/deployment-name/conf directory. To use a different file, set the filter.AliasForwarding.file property in the DefaultWebApp.properties file in the $CDS_HOME/deployment/deployment-name/conf directory.

The alias forwarding file is a filter that uses XML to describe the redirection that takes place when a URL is received. The following table describes the elements in this file.

TABLE 4-1 Alias Forwarding File Elements
Element	Description
`AliasForwarding`	Wraps the entire file. Only one instance of this element appears in the file and contains all other elements.
`AliasMap`	Describes a single mapping. This element contains the `URLPattern`, `TargetContext` and `TargetPath` elements.
`URLPattern`	Pattern used to match the incoming URL. The string `/*` is interpreted as a wildcard when it appears at the beginning or the end of the pattern.
`TargetContext`	Context root that identifies the web application to which the request is redirected. The value specified must be an existing context root that is deployed with the application server on which Content Delivery Server is deployed. By default, Content Delivery Server has applications deployed at the following context roots: `/DefaultWebApp` `/admin` `/vsadmin` `/developer` `/subscriber` `/fs` If no value is provided for this element, the root URI is used.
`TargetPath`	Path under the context root to which the request is redirected. This value must be an absolute path and must be valid for the specified context root.

The following code example shows a sample mapping file.

CODE EXAMPLE 4-1 Sample `aliasForwarding.xml` File
<AliasForwarding> <AliasMap> <URLPattern>/dev</URLPattern> <TargetContext>/developer</TargetContext> <TargetPath>/main</TargetPath> </AliasMap> <AliasMap> <URLPattern>/sub</URLPattern> <TargetContext>/subscriber</TargetContext> <TargetPath>/desktop_home.do</TargetPath> </AliasMap> </AliasForwarding>

CODE EXAMPLE 4-1 Sample aliasForwarding.xml File

<AliasForwarding>
    <AliasMap>
        <URLPattern>/dev</URLPattern>
        <TargetContext>/developer</TargetContext>
        <TargetPath>/main</TargetPath>
    </AliasMap>
 
    <AliasMap>
        <URLPattern>/sub</URLPattern>
        <TargetContext>/subscriber</TargetContext>
        <TargetPath>/desktop_home.do</TargetPath>
    </AliasMap>
</AliasForwarding>

The alias forwarding filter is deployed to the context root /DefaultWebApp, which is set up by Content Delivery Server as the default application for requests to Content Delivery Server. Requests that do not contain a URL that matches a known context root are sent to the default application and are processed by the filter. Requests that do contain a URL that matches a known context root are sent directly to the application and are not processed by this filter. For example, based on the mappings in CODE EXAMPLE 4-1, a request to /sub is processed by the filter and rerouted to /subscriber. However, a request to /subscriber is sent directly to the application and is not processed by the filter.

When a request is received by the default application for Content Delivery Server, the incoming URL is matched against each URLPattern element in the alias forwarding file according to the following rules:

If the incoming URL does not begin with a slash (/), the slash is assumed.

If the pattern or the incoming URL does not end with a slash (/) or a file name extension, a slash is assumed.

If the pattern is /*, the incoming URL is always a match.

If the pattern is more than three characters, begins with /, and ends with /*, the string between the slashes is matched with the beginning of the incoming URL. For example, the pattern /PATH/* matches the URLs /PATH and /PATH/anything.

If the pattern begins with /*., the string following the period is matched with the end of the incoming URL. For example, the pattern /*.EXT, matches any URL that ends with .EXT.

If the pattern begins with *., the string following the period is matched with the end of the incoming URL. For example, the pattern *.EXT matches any URL that ends with .EXT.

If the pattern begins with / and ends with /, the string between the slashes is matched with the incoming URL. For example, /PATH/ matches the URLs /PATH and /PATH/.

If the pattern begins with /, the string following the slash is matched with the incoming URL. For example, /PATH matches the URLs /PATH and /PATH/.

The process stops when a match is found. The request is then redirected to the location derived by appending the values for TargetContext and TargetPath that are associated with the URLPattern that matched the incoming request. If no match is found, the request is returned to the application server.

Depending on how you define the mappings, it is possible that when a match is found, the new location is also processed by the filter. Make sure that you do not create a circular mapping that generates only URLs that are processed by the filter and never a URL that is redirected to an actual location.

4.4 Control Access to Sun Java System Application Server

The Sun Java System Application Server includes a security manager that blocks access by applications that do not have the necessary permission defined in the security policy. This policy is a file named server.policy and is located in the $CDS_HOME/deployment/deployment-name/sun/domains/server-domain/config directory after a deployment.

If you write your own adapters using the APIs described in the Sun Java System Content Delivery Server Customization Guide, the default set of permissions in the security policy might not be enough for your adapters to run successfully. Edit the server.policy file to add any custom permissions that your adapters need and restart Content Delivery Server. See the documentation for the Sun Java System Application Server for more information on the security policy.