CA SiteMinder® SPS in an Enterprise

Contents
sm1252sp1
Contents
CA Access Gateway
 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 Access Gateway
is intended to be an addition to enterprise architecture, rather than a replacement for other proxy technologies. As such, the
CA Access Gateway
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 Access Gateway
can be deployed in a network to work in conjunction with load balancing devices:
Deploy Secure Proxy Server in an Enterprise
Deploy Secure Proxy Server in an Enterprise
 
In addition to load balancing devices, caching devices can be placed on either side of the
CA Access Gateway
cluster.
Sticky-Bit Load Balancing
When using the cookieless session schemes supported by the
CA Access Gateway
, session information for users who access resources through
CA Access Gateway
is maintained in an in-memory session store. Because the session information is maintained at the
CA Access Gateway
where a user is first authenticated, the same
CA Access Gateway
should be used for all the user requests in a single session. When implemented in clusters, the
CA Access Gateway
must be used in conjunction with sticky-bit load balancers to provide a consistent connection to the same
CA Access Gateway
, enabling single sign-on when using session schemes other than the traditional
CA Single Sign-On
cookie session scheme.
To deploy the
CA Access Gateway
using cookieless session schemes the following must be considered:
  • In most deployments, the
    CA Access Gateway
    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 Access Gateway
    in a cluster, that
    CA Access Gateway
    services all of the user’s requests. This capability is required because the
    CA Access Gateway
    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 Access Gateway
    in the cluster of servers.
  • When configuring the settings for the
    CA Access Gateway
    , the default virtual host defined in the server.conf file of the
    CA Access Gateway
    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
    CA Access Gateway
    .
  • The load balancing device must point to the cluster of
    CA Access Gateway
    s.
  • 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
    CA Access Gateway
    .
  • If using SSL, a certificate must be issued to the load balancer, not the
    CA Access Gateway
    .
  • The system or systems on which you install the
    CA Access Gateway
    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 Access Gateway
is assumed to proxy for trusted sites within the enterprise. As part of a proxy transaction,
CA Single Sign-On
generated HTTP header variables and any variables generated by
CA Single Sign-On
responses are forwarded along with each HTTP and HTTPS request. These responses can be used by other enterprise applications.
If you employ the
CA Access Gateway
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 Access Gateway
to proxy for destination servers trusted by your enterprise.
Configuring Virtual Hosts
You can configure the
CA Access Gateway
with multiple hosts and act as a virtual host for one or more hostnames.
Follow these steps:
  1. Edit the <VirtualHost> parameters of the server.conf file to configure the
    CA Access Gateway
    to act as a virtual host for one or more hostnames.
  2. Edit the configuration file for the embedded Apache Web server.
Edit the Apache Configuration File To Handle Multiple Virtual Hosts
When you are running multiple virtual hosts in the same operating environment with the
CA Access Gateway
, 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 Access Gateway
to recognize multiple user agent types, assign different session scheme mappings for those user agents based on virtual hosts, you must follow these steps:
  1. Configure session schemes, or verify the configuration of the schemes included with the
    CA Access Gateway
    .
  2. Define user agent types in the server.conf file.
  3. 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).
  4. 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
CA Access Gateway
.
# 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
CA Single Sign-On
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 Access Gateway
will use
CA Single Sign-On
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>