Cams Technical Paper
This document provides a technical overview of key Cams technical
Cams is a centralized access management solution. Distributed Cams
web agents delegate security decisions to a central authority -
the Cams policy server. As packaged, Cams protects web resources
such as web pages, files, and dynamic web applications that are
served using the HTTP protocol. However, at its core the Cams architecture
also enables the potential to protect virtually any type of resource
such as Java and Windows/Linux/UNIX native code applications, web
services, and more. When a Cams web agent sends an authentication
or access control request, the corresponding service hosted within
a Cams policy server makes a decision, and the requesting Cams web
agent enforces the decision.
Cams architecture enables authentication configuration and access
control policy to be centralized at the Cams policy server. This
results in centralized user activity logging and security administration.
NOTE: References in this document
to a user can represent an individual
or a computer. For example, a user could be a business partner order
entry system placing an automated, secure order.
In the Cams security model, resources and user accounts are owned
by a specific security domain. This enables management to be partitioned
according to organizational or physical boundaries. Different security
domains may be securely configured and managed by different individuals,
departments, and companies. All requests are first passed to the
system security domain and may be delegated to other security domains
as defined by the access control policy.
Each security domain contains it's own set of services, which include:
- Authentication service - verifies
the user's identity and establishes a session that exists until
the user logs out or the session times out
- Access control service - grants
or denies access to protected resources based on an access control
- Session access service - provides
information to Cams web agents about authenticated users
- Session control service - enables
modification and explicit closure (logout) of sessions
- Session manager service - manages
authenticated user sessions and expires them if inactive for a
- Service manager service - manages
custom services created for use by other components or services
within a security domains
All security domain services are defined in a security domain specific
configuration that's pluggable. Hence, the Cams architecture allows
individual services to be customized to meet specific business requirements.
Typically, the authentication and access control services are of
greatest interest because they are the most configurable.
Cams enables authentication against any number of existing customer
site user directories. Hence, there's no need to setup any difficult
to manage replication processes, directory migrations or forced
creation of a new user directory.
When an unidentified user accesses a resource, the Cams policy
server may require the user to authenticate (depending upon the
access control policy for the resource). User authentication is
performed against one or more Cams login configurations. Each login
configuration can reference one or more pluggable and stackable
Cams JAAS login modules, where each login module generally corresponds
to a user directory. Login modules are invoked in order along with
any stack dependencies between them using the standard PAM REQUIRED,
REQUISITE, OPTIONAL, and SUFFICIENT flags.
Cams is supplied with login modules for accessing user data in:
- Microsoft Active Directory
- LDAP v3 compliant servers such as SunOne
- SQL databases such as Oracle 9i and Microsoft SQL server
- An XML file user directory supplied with Cams for convenience
Source code is provided for each Cams login module to facilitate
customization for various user directory schema and the creation
of new login modules as required. In addition, Cams provides a source
code for a callback handler that handles username and password credentials
for HTTP FORM authentication. New callback handlers can easily be
created to support virtually any other type of credentials such
as an account number, social security number, pin, etc.
Once a web user is authenticated, a Cams session is created and
an HTTP cookie with one-way hashed session information that prevents
spoofing is sent to the browser. The cookie will not disappear unless
the user logs out, a Cams detects that the associated session has
expired and instructs the browser to remove the cookie, or the user
exits the browser. A configurable session time out value also automatically
expires inactive sessions on the Cams policy server. The Cams session
cookie is memory resident in the browser, it is not persisted to
Cams provides a session event API that enables invocation of custom
business processes when a new session is created. For example, a
site may want to send an email notification to a specified address
when users with a certain profile login. Or, user profile information
can be queried once and saved with the Cams security session for
easy retrieval by web applications many times using Cams secure
HTTP request headers (Cams uses request headers to securely make
Cams security session information available to web applications).
Access Control Service
Each security domain protects the resources that it owns using
an access control policy, which contains a set of permissions and
a library of access control rules.
A permission associates a set of resources (defined using a resource
pattern) with one of two possible actions; 1) An access control
rule that will be evaluated to grant or deny access to the resource,
or 2) Another security domain to which access control will be delegated.
A special system security domain
receives all access control requests and can delegate them to other
security domains as required. The system
security domain also authenticates Cams system administrators and
web agents, and protects system-level resources.
URL resource patterns include a lot of flexibility and some limitations.
In particular, use of the wildcard character '*' is supported only
in certain contexts, which helps maximize performance and simplifies
the rules for best permission matching. The meaning of '*' depends
on the part of the URL pattern in which it is used. URL resource
patterns are composed of four sub-patterns:
shemePattern :// hostPattern : portPattern / uriPattern
- scheme - resource type, currently either http or cams
- host - IP address or DNS hostname for the server where the
resource is located
- port - the port number on which the server listens for client
- URI - the path on the server to the resource
Each sub-pattern has its own validation rules. The best matching
pattern is based on URI first, port second, host third, and scheme
last. Cams implements resource pattern scoring based on field weighting
and field pattern specificity to ensure that more specific patterns
Access Control Rules
Cams includes rules that enable access control by:
- Authenticated user and user roles (Role-based access control)
- Remote host name or IP address
- SQL data contraints (rules based on queries)
- Obligation redirects (route web application workflow)
- HTTP request attributes (like query parameters)
- Connection confidentiality (SSL/TLS)
- Composed and custom
Existing access control rules can be combined into new, reusable
rules using AND, OR and NOT operators. New access control rules
can also be created using a programmer's API. For example, a site
might create a custom rule to grant access to a resource based on
a database value, such as the amount of money in an account.
Web Single Sign On (Web SSO)
Cams supports web single sign-on functionality within a single
DNS domain plus subdomains. On a site that supports web SSO, once
a user has authenticated, he can use any other server within the
same DNS domain (or subdomains) without re-authenticating. Cams
web agents support web SSO by use of HTTP Cookies, which are allowed
by Internet standards to work only within a single DNS domain.
Cams Web Agents
Cams web agents are software components that delegate authentication
and access control security requests to a Cams policy server. Cams
web agents enforce access control and authentication on web pages,
files, images, cgi-bin scripts and programs, servlets, Java Server
Pages, ASPs, PHP applications, etc.
When authentication is necessary to access a protected resource,
a Cams web agent redirects users to a site-specific login page.
Once login credentials are supplied, the Cams web agent delegates
authentication requests to a Cams policy server. After authentication,
Cams web agents support personalization by making user-specific
values available to web applications via secure Cams HTTP request
Cams provides web agent support for:
- Apache 2.0 and 2.2 on Linux and Solaris
- Microsoft IIS 6 and 7 on Windows
Java Application Servers
- Oracle WebLogic
- IBM WebSphere
- Any J2EE server that supports Servlet API 2.3 or greater
Porting to new server and application environments is facilitated
with the Cams client and agent API, which are written in both Java
and C. Support for additional Cams web agents is customer demand
Apache Reverse Proxy Agent
A reverse proxy server allows an organization to channel incoming
HTTP requests through a centralized server. The reverse proxy then
maps those requests to other servers within a protected network.
The Apache web server can be configured as a reverse proxy server.
By integrating a Cams Apache web agent with Apache configured as
a reverse proxy, resources can be protected by Cams on web and application
servers that do not have an integrated Cams web agent.
Performance and Failover
Cams provides for enterprise performance needs by using efficient
messaging, caching, object pooling, and load distribution. The Cams
software architecture and distributed web agent topology enables
a single Cams policy server to handle many millions of security
requests each day.
The Cams messaging framework is an optimized protocol that Cams
web agents use to communicate with the Cams policy server. Normally,
authentication and access control requests are sent by the Cams
web agent, processed by the Cams policy server and returned in less
than 5 milliseconds. Furthermore, Cams web agents can be configured
to cache requests that are unconditionally granted access, avoiding
some access control requests to the Cams policy server. In this
case, a cache configuration value determines the amount of time
a request is cached before a refresh is required. Load testing indicates
that Cams imposes 10 to 15 percent of overhead on a typical HTTP
The Cams policy server and web agents use object pooling to efficiently
reuse connections and other resources that are time intensive to
create. Furthermore, the Cams web agent topology distributes the
authentication and access control load across multiple front end
servers. This, in conjunction with web agent caching, allows the
Cams policy server to deflect many potential access control requests.
The Cams policy server is a standalone Java-based server making
it portable to any platform that supports J2SDK 1.4 or 1.5. A clustering
feature enables any number of Cams policy servers to share configuration
information. Should one Cams policy server go down, Cams web agents
automatically route requests to another until service to the failed
node is restored. The Cams cluster configuration also provides load
balancing through round robin requests to Cams policy servers that
form a cluster by associated Cams web agents.
The Cams policy server is configured using three security domain
specific XML files.
- security-domain.xml - Security
domain service configuration
- login-config.xml - Authentication
- access-control-policy.xml -
Security policy rules and permission
One more XML file, security-domain-registry.xml,
defines available security domains within a Cams policy server.
All configuration files are modified by a system administrator
using a text editor. Generally, very little needs to be configured
and security-domain.xml. These changes
along with configuring authentication in login-config.xml
are usually done at the initial integration and don't change
much over time. Graphical login configuration tools are provided
to assist administrators with generation of the XML required for
Active Directory, LDAP and SQL database authentication.
Most ongoing configuration management is to refine the access control
policy, which is defined in access-control-policy.xml.
This file includes the permissions and access control rules that
enforce your business security policy. The access control policy
is automatically reloaded when the file is saved, after being validated
for correct syntax.
The Cams policy server centrally logs system and security events
into configurable, security domain specific log files.
- authentication log - contains
information about successful and unsuccessful authentication requests
within a security domain
- access control log - contains
information about access control requests made by remote agents
on behalf a client wishing to access resources protected by a
- session manager log - contains
information about the sessions created, closed, and expired
- session access log - contains
information about requests for remote access to an authenticated
- session control log - contains
information about requests to update, close or expire sessions
Two system log files capture Cams server-level output:
- cams server log - contains information
about the startup, shutdown, warnings, and errors of it's services
- system trace log - contains information
output to the console regarding startup/shutdown of Cams, initialization
of services, errors, etc.
Web Application Programming
Cams provides programmers with a security infrastructure that can
eliminate duplication of security code within web applications and
avoid the creation of security islands. Furthermore, Cams provides
the information to make fine-grained access control decisions. In
plain English, this means that users with distinct identities, roles,
account information, logon locations, logon times, etc. may be presented
with completely different user interfaces and application functionality.
The difference can range from dynamically changing a button or image
based on user values to completely denying access to a resource.
Java J2EE web containers with a Cams web agent provide programmers
access to the J2EE servlet API calls:
- request.getRemoteUser() - determine
the user name with which the client authenticated
- request.isUserInRole(String name)
- determine if a user is in a specific security role
- request.getUserPrincipal() -
returns a java.security.Principal object
Java, PHP, Perl, C/C++, ASP.Net, etc. programmers can use Cams
secure HTTP request headers to obtain information about a user request.
By default, Cams adds the following spoof-proof values to the request
headers sent by the HTTP browser:
- CAMS_HTTP_SESSION_ID - the authenticated user's session id
- CAMS_HTTP_SESSION_CREATED - the date/time when the user's session
- CAMS_HTTP_SECURITY_DOMAIN - the security domain to which the
authenticated user session belongs
- CAMS_HTTP_USER - the authenticated user name
- CAMS_HTTP_ROLE - the role(s) assigned to the authenticated user.
One instance of this header is added for each role
- CAMS_HTTP_ROLES - a comma-delimited list of roles assigned to
the authenticated user
In addition to these intrinsic Cams HTTP request headers, programmers
can create custom HTTP request headers using the Cams session API.
Cams includes comprehensive administrator and programmer guides,
and Javadoc for public APIs. Complete instructions are provided
with clear examples on how to configure and programmatically customize
Cams. An XML tag library reference defines all the tags available
in each security domain configuration file. Clear instructions are
provided on how to harden a Cams installation to prevent both internal
and external threats.
Cams provides high-performance web single sign-on and access control
to web and application servers. The Cams policy server is highly
configurable through a set of security domain specific files. Most
ongoing configuration is done with the access control policy as
specified by rules and permissions. Rules can be Cams intrinsic,
combined with logical operators or custom for an organization's
Cams provides container-based protection for specific web and application
servers like Apache, IIS, BEA WebLogic, IBM WebSphere, and Tomcat
through web agents, and for all web resources through the Apache
reverse proxy. API's are provided to allow creation of custom web
agents. The distributed Cams web agent topology and Cams internal
architecture is designed to support the scalability and performance
needs of traffic intensive sites. Finally, web programmers and administrators
are provided with the tools needed to create and manage the life-cycle
of their web application and static content security.