Administration Guide › Deploying the SPS

Deploying the SPS

This section contains the following topics:

CA SiteMinder® SPS Deployment in an Enterprise

The CA SiteMinder® SPS uses reverse proxy architecture to enable access control, single sign-on, and SSL acceleration. It does not provide the content caching and some other features provided by traditional reverse proxy servers. The CA SiteMinder® SPS is intended to be an addition to enterprise architecture, rather than a replacement for other proxy technologies. As such, the CA SiteMinder® SPS can be placed in clusters with load balancing devices and caching devices on either side of the clusters.

The following illustration shows how the CA SiteMinder® SPS can be inserted into a network to work in conjunction with load balancing devices.

Note: In addition to load balancing devices, caching devices can be placed on either side of the CA SiteMinder® SPS cluster.

Sticky-Bit Load Balancing

When using the cookieless session schemes supported by the SPS, session information for users who access resources through CA SiteMinder® SPS is maintained in an in-memory session store. Because the session information is maintained at the CA SiteMinder® SPS where a user is first authenticated, the same CA SiteMinder® SPS should be used for all the user requests in a single session. When implemented in clusters, the CA SiteMinder® SPS must be used in conjunction with sticky-bit load balancers to provide a consistent connection to the same SPS, enabling single sign-on when using session schemes other than the traditional SiteMinder cookie session scheme.

To deploy the CA SiteMinder® SPS using cookieless session schemes the following must be considered:

In most deployments, the CA SiteMinder® SPS is deployed in clusters, with several servers sharing the load of incoming requests. The load balancing is handled by load balancer devices. These devices must have sticky bit capability to maintain single sign-on.
Sticky bit load balancers ensure that once a user’s session is established with a specific CA SiteMinder® SPS in a cluster, that CA SiteMinder® SPS services all of the user’s requests. This capability is required because the CA SiteMinder® SPS maintains session information for cookie-less sessions in active memory. If a user’s request is not handled using sticky bit technology, the user will be charged for new credentials each time a request is fulfilled by a different CA SiteMinder® SPS in the cluster of servers.
When configuring the settings for the SPS, the default virtual host defined in the server.conf file of the CA SiteMinder® SPS must be defined using the name and IP address of the load balancing device.
The load balancing device must be configured as the point of entry to the SPS.
The load balancing device must point to the cluster of SPSs.
The httpd.conf file, located in the sps_home/secure-proxy/httpd/conf directory, must be modified so that the value of the ServerName directive is set to the name of the load balancing device, not the system on which you installed the SPS.
If using SSL, a certificate must be issued to the load balancer, not the SPS.
The system or systems on which you install the CA SiteMinder® SPS must have approximately 1K of memory for each simultaneous user session that will be maintained in the in-memory session store. For example, if a single system must maintain 1000 concurrent sessions, the system must have 1 megabyte of RAM available for this purpose.

Proxying to Trusted Sites vs. Non-Trusted Sites

The CA SiteMinder® SPS is assumed to proxy for trusted sites within the enterprise. As part of a proxy transaction, SiteMinder generated HTTP header variables and any variables generated by SiteMinder responses are forwarded along with each HTTP and HTTPS request. These responses can be used by other enterprise applications.

Important! If you employ the CA SiteMinder® SPS in transactions that proxy for content on non-trusted sites, the headers that accompany the transaction will also be forwarded to the non-trusted sites. We recommend using the CA SiteMinder® SPS to proxy for destination servers trusted by your enterprise.

Configuring Virtual Hosts for the SPS

You can configure the CA SiteMinder® SPS with multiple hosts and act as a virtual host for one or more hostnames.

To configure CA SiteMinder® SPS as multiple hosts and act as a virtual host for one or more hostnames

Edit the <VirtualHost> parameters of the server.conf file to configure the CA SiteMinder® SPS to act as a virtual host for one or more hostnames.
Edit the configuration file for the embedded Apache Web server.

More information:

Virtual Host Names Configuration

Edit the Apache Configuration File To Handle Multiple Virtual Hosts

When you are running multiple virtual hosts in the same operating environment with the SPS, and transactions run in this environment, update the Apache configuration file (httpd.conf). This file is located in the directory sps_home\secure-proxy\httpd\conf. If SSL is enabled for the web server, also make the same updates to the httpd-ssl.conf file, which is located in the sps_home\secure-proxy\httpd\conf\extra directory. The updates vary depending on whether your operating environment is based on IPv4 or IPv6.

To update the httpd.conf file, and optionally the httpd-ssl.conf file, to handle multiple virtual hosts

For IPv4 environments, add the following LISTEN directive:
LISTEN 127.0.0.1:<_port>
For IPv6 environments, add the following LISTEN directive:
LISTEN [::1]:<_port>
For dual stack environments with IPv4 and IPv6 supports, add the following LISTEN directives:
LISTEN 127.0.0.1:<_port>

LISTEN [::1]:<_port>

In addition, update the loopback address entry in the hosts file so that the new host name is added, as follows:

IPV4: 127.0.0.1
IPV6: [::1]

The hosts file is usually located on Windows in C:\WINDOWS\system32\drivers\hosts. On UNIX, the hosts file is usually in /etc/hosts.

Implementing Session Scheme Mappings for Multiple Virtual Hosts

If you want to configure the CA SiteMinder® SPS to recognize multiple user agent types, assign different session scheme mappings for those user agents based on virtual hosts, you must follow these steps:

Configure session schemes, or verify the configuration of the schemes included with the SPS.
Define user agent types in the server.conf file.
Create a section for each virtual host in the server.conf file that defines any directives that differ from default settings (refer to Overriding Default Values for a Virtual Host).
Define session scheme mappings for each virtual host.

The following excerpts from a server.conf file provide an example where a user agent type has been defined for Internet Explorer (IE) browser users. IE users will be mapped to use session schemes other than the default session scheme defined for a virtual host. The following example shows the session schemes defined in the server.conf file.

#Session Schemes
<SessionScheme name="default">
	class="com.netegrity.proxy.session.SessionCookieScheme"
	accepts_smsession_cookies="true"
</SessionScheme>
<SessionScheme name="ssl_id">
	class="com.netegrity.proxy.session.SSLIdSessionScheme"
	accepts_smsession_cookies="false"
</SessionScheme>
<SessionScheme name="simple_url">
	class="com.netegrity.proxy.session.SimpleURLSessionScheme"
	accepts_smsession_cookies="false"
</SessionScheme>
<SessionScheme name="minicookie">
	class="com.netegrity.proxy.session.MiniCookieSessionScheme"
	accepts_smsession_cookies="false"
	cookie_name="MiniMe"
</SessionScheme>

The following example shows the definition of the IE user agent type. This user agent type will be referenced when defining session scheme mappings later in the server.conf file.

# TO-DO: Define Any User Agents, if you want to
# use a different session scheme based on
# the type of client accessing the server.
#
# NOTE:  UserAgent matching is done in the order
# in which the user agents are defined in this file.
 <UserAgent name="IE">
     User-Agent="MSIE"
 </UserAgent>
# <UserAgent name="NS">
#     User-Agent=some other regular expression
# </UserAgent>

The preceding example shows that the default session scheme specified in the defaultsessionscheme directive is mini-cookie. This session scheme will be used for all transactions unless another session scheme is explicitly included in a session scheme mapping, or another scheme overrides the default session scheme in the definition of a virtual host.

The <VirtualHostDefaults> directive shows the session scheme mapping for the IE user agent type that was defined in <UserAgent name="IE">. This mapping indicates that for all virtual hosts using default session scheme mappings, IE browser users’ sessions will be maintained using the simple URL rewriting sessions scheme.

<VirtualHostDefaults>
	# Service Dispatcher
	<ServiceDispatcher>
		class="com.netegrity.proxy.service.SmProxyRules"
		rules_file="conf\proxyrules.xml"
	</ServiceDispatcher>
	# default session scheme
	defaultsessionscheme="minicookie"
	#TO-DO:  Define any session scheme mappings
	<SessionSchemeMappings>
       #    user_agent_name=session_scheme_name
           IE="simple_url"
       #    NS=simple_url
	</SessionSchemeMappings>

The Virtual Host directives show the server name and IP address for the default virtual host configured for the SPS.

# Default Virtual Host
<VirtualHost name="default">
	hostnames="server1, server1.company.com"
	addresses="192.168.1.10"

	#The defaults can be overriden
	#not only for the Virtual Host
	#but for the WebAgent for that
	#virtual host as well
	#<WebAgent>
	#</WebAgent>

</VirtualHost>

The Virtual Host directive for additional virtual host shows the specific default virtual host settings that will be overridden for the server2 virtual host. Notice that these overrides include new session scheme mappings. The default scheme for server2 is default. In Session Scheme directive the default is defined as the traditional SiteMinder cookies session scheme. Further, the session scheme mapping for IE users in Virtual Host directives is also mapped to the default scheme. Therefore, the CA SiteMinder® SPS will use SiteMinder cookies session scheme to maintain sessions for all users who access server2.

# Additional Virtual Host
<VirtualHost name="host2">
       requestblocksize="4"
	responseblocksize="4"
	hostnames="server2, server2.company.com"
	#addresses="192.168.1.15"
	# default session scheme
	defaultsessionscheme="default"

	#TO-DO:  Define any session scheme mappings
	<SessionSchemeMappings>
       #user_agent_name=session_scheme_name
           IE="default"
	</SessionSchemeMappings>

	#<WebAgent>
	#</WebAgent>
</VirtualHost>