Deploying Cams Web Single Sign-on Security Solution
The Cams web single sign-on security solution flexibly deploys
in an almost unlimited number of network topologies. This Cams tip
explains deploying Cams in commonly found topologies.
Overview
The Cams security architecture enables integration with minimal
impact on your existing network topology. Cams web agents integrate
with existing web and application servers to provide container-based
security as shown in Figure 1. Doing security at the web container-level
means that any resource on the server can be protected by Cams including
static html pages, files, and images. This is dramatically different
from most application-level FORM security solutions that only protect
dynamically generated web pages.
Figure 1 - Basic Cams deployment architecture
Web and application servers protected by Cams can reside on the
public Internet or within a company's private network. Sometimes
the same server might be dual-purposed to provide secure resources
to the Internet and the companies private network simultaneously.
A single Cams policy server can protect multiple web and application
servers located on the public Internet or within a private network.
In other words, web requests do not need to be channeled through
a single network gateway or proxy server. This greatly facilitates
web security, especially on private networks, where it may be difficult
to prevent users from circumventing a gateway to directly access
web and application server resources.
Cams also flexibility integrates with existing user directories
for authentication and group/role associations. There's no need
for difficult directory migrations, duplications, or synchronization.
Cams can be configured to search for users in virtually any LDAP
or SQL directory including Active Directory, SunOne, eDirectory,
OpenLDAP, Oracle 9i, MSSQL, Sybase, MySQL, and more. An open API
enables you (or a service provider) to create an adapter for user
directories that are not currently supported.
Once the Cams web agents and Cams policy server are configured
and communicating, then an access control policy can be centrally
created and managed. Cams flexible permission scheme enables the
same Cams policy server to protect and distinguish between HTTP
URL-based resources with distinct DNS domains, hosts, ports, and
file paths. See the Cams
URL Resource Pattern Matching tip for more information.
Single Server Solutions
In some cases it may be desirable to install and configure the
Cams policy server on a single system with a web or application
server (or both) and user directory. For example, a site may choose
to minimize space and server rentals at a collocation facility.
Though Figure 1 shows at least three separate systems, the Cams
policy server is lightweight and memory efficient and can run on
the same system as the web or application server and user directory
as shown in Figure 2.
Figure 2 - Deploying Cams on the same system as
the web and user directory server
In this configuration, you'll need to make sure that operating
system security is rock solid as a single penetration provides a
hacker with access to all system resources. You'll be able to use
Cams to protect any web resources used for administration of the
site, including Cams protecting itself.
Layered Web Security
Competent security practitioners instruct that it is best to practice
security in layers. In the web space, this best practice would have
you componentize system resources on separate physical servers when
possible and use a combination of firewalls, operating system security,
and web server security.
Over 90 percent of the web servers in use today are either Apache
or Microsoft IIS. Though the religious would argue otherwise, each
of these web servers has strengths and weaknesses. In addition to
web servers, J2EE application servers such as BEA WebLogic and Tomcat
are often used at sites to serve HTTP resources. Though each of
these web and application servers implements and manages security
in a proprietary way, each can be considered to be similar once
a Cams web agent is integrated to provide security. Figure 3 shows
how a farm of Apache, IIS, and/or J2EE web and application servers
can be deployed with Cams web agents and a Cams policy server to
provide a layered security solution.
Figure 3 - Web security in layers with separate
physical servers for system components
Employees are most often on the private network but may have need
to access secure resources while away from the office. Customers
and business partners are almost always remote users. A public firewall
is shown to provide perimeter security to public resources. An internal
firewall is also shown that limits access to the WebLogic application
server, Cams policy server, and user directory resources. For example,
the internal firewall might limit access to the Cams policy server
to a specific port (9191 by default) and to known servers with Cams
web agents.
Apache and IIS each configure and manage security in their own
way. Apache security is configured in httpd.conf
and .htaccess configuration files
with modules that can access LDAP and SQL user directories. With
IIS, security packaging is comprehensive, but it is tied to the
Microsoft platform and not easily extensible. From a layered security
prospective, the IIS security implementation is not considered best
practice as a breach of web server security can lead to a breach
of operating system security and visa versa. Neither of these web
server provides the infrastructure for a comprehensive web single
sign on solution. Also, distributed management capabilities are
weak for both servers, especially for Apache. The situation is made
even more difficult with the addition of J2EE application servers,
where each implements the J2EE security model in a proprietary fashion.
Worst of all, web single sign-on is a difficult proposition, even
across servers of the same type.
With Cams, you can implement a truly componentized, layered security
solution and have the full advantage of a centralized security architecture.
Cams web agents for Apache, IIS, and J2EE servers are installed
and configured to provide web single sign within the same Internet
domain. The integrated Cams web agent obtains its security policy
decisions from the centralized Cams policy server easing management
and reducing vulnerabilities. Security logging is also centralized
on the Cams policy server. The Cams security architecture facilitates
layered web security and eases security implementation and management,
especially as the number of servers increases.
Reverse Proxy Configurations
To centralized security configuration and management, some sites
deploy an HTTP reverse proxy server as a security gateway. In this
configuration, the reverse proxy server resides between the resource
requesters (such as users on the Internet) and the web and application
servers that serve the actual resources. Requests are received in
the URL space of the reverse proxy, the user never knows about the
proxied servers. Figure 4 shows use of the Apache web server as
an HTTP reverse proxy security gateway.
Figure 4 - Apache with a Cams web agent as an
HTTP reverse proxy security gateway
- request.isUserInRole()
- request.getUserPrincipal()
- request.getRemoteUser()
Web Server with Tomcat
Many sites deploy Tomcat as a powerful J2EE web application server
for Apache and IIS. This configuration leverages the fast static
file serving of Apache and IIS. It also enables use of Apache modules
(e.g., mod_rewrite, mod_ssl, mod_php), IIS filters, and other native
web server functionality for requests to Tomcat. Regardless of the
reason for using Apache or IIS with Tomcat, there are three primary
architectures:
- mod_jk passes configured requests directly from Apache and
IIS to Tomcat
- mod_proxy reverse proxies configured requests to Tomcat
- Apache, IIS, and Tomcat act as peer web servers
There are no absolute right or wrong decisions with respect to
choosing any of these architectures. Figure 5 shows how Tomcat web
applications are made available through Apache/IIS only (via mod_jk
on default port 8009) or can be configured for direct access by
end users (via default port 8080). This is also a good example of
how a firewall and Cams can be used to enhance security. Tomcat,
for example, might be enabled on port 8080 to allow administrator
access only to Tomcat's Manager
web application. The firewall can block all public access to port
8080 and the Cams security policy can be configured with a permission
that only allows access to the Manager
web application to users with role Administrator.
Use of port 8080 for all other applications can be blocked by Cams.
Figure 5 - Apache or IIS web server with Tomcat
and Cams security
- request.isUserInRole()
- request.getUserPrincipal()
- request.getRemoteUser()
If you choose Tomcat security only, you loose the ability to secure
static content served by the web server, you cannot do proactive
authentication (authenticate a user before he tries to access a
secure resource), and you distribute your security policy administration
and auditing across J2EE web applications. If you choose both, you
force the user to authenticate twice as there is no way to enable
web single sign on between web servers and Tomcat. You also increase
management difficulty as your security policy is distributed across
web servers and web applications in web.xml.
Failover and Load Balancing
Until now, single Cams policy servers have been shown that secure
one or more web or application servers. But what happens if a Cams
policy server fails or the load site load increases over time? Figure
6 shows a clustering feature that enables multiple Cams policy servers
to implement fault tolerance and increased scalability.
Figure 6 - The Cams Cluster Architecture supports
failover and load balancing
The primary benefits of running multiple Cams policy servers in
a cluster include:
- Fault Tolerance - the ability of the distributed environment
in which Cams is running to gracefully handle the failure of a
Cams policy server (or the host on which it is running) and its
possible recovery.
- Increased Scalability - the ability to handle an increasing
number of security transactions (authentication, access control
checks, etc.) as the number of users, Cams web agents, and protected
resources increases. You may add as many Cams policy servers as
needed to a Cams cluster.
The primary mechanism by which Cams provides fault tolerance is
failover. Cams web agents configured to communicate with multiple
Cams policy servers in a cluster will automatically detect a failed
Cams policy server and avoid further communication with it until
it has recovered. Instead, security requests are sent to an accessible
Cams policy server.
Scalability is provided in the Cams environment by use of load
balancing, which refers to the ability of Cams web agents to delegate
security requests to different Cams policy servers based an algorithm
and/or heuristic. For example, a round-robin load balancing strategy
simply loops over a finite list of Cams policy servers.
Any of the architectures presented in this document can be deployed
using a Cams cluster except the single server solution. Cams requires
that each policy server in a cluster be on a separate physical server.
Additional Reading
To learn more about deploying Cams policy server and web agents,
please reference the following documents:
|
