Cams™ Technical Paper

This document provides a technical overview of key Cams technical features.

Architectural Overview

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.

Security Domains

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:

1. Authentication service - verifies the user's identity and establishes a session that exists until the user logs out or the session times out
2. Access control service - grants or denies access to protected resources based on an access control policy
3. Session access service - provides information to Cams web agents about authenticated users
4. Session control service - enables modification and explicit closure (logout) of sessions
5. Session manager service - manages authenticated user sessions and expires them if inactive for a configurable period
6. 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.

Authentication Service

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 disk.

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.

Permissions

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

where:

• 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 connections
  
• 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 are matched

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)
  
• Date/time
  
• 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 headers.

Cams provides web agent support for:

Web Servers

• Apache 1.3 on Linux and Solaris (Cams 2.1 and prior)
• Apache 2.0 on Linux, Windows and Solaris
  
• Microsoft IIS 5.0, 5.1 and 6.0
• Sun ONE 6.x on Solaris
• Oracle 9iAS and 10g on Linux and Solaris

  Java Application Servers
  

• BEA WebLogic 7.x and 8.x
• IBM WebSphere 5.x
• JBoss 3.2.x and 4.x
  
• Tomcat 4.x, 5.x and 5.5.x
• Other J2EE servers that support 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 driven.

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 request.

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.

Configuration Management

The Cams policy server is configured using three security domain specific XML files.

• security-domain.xml - Security domain service configuration
• login-config.xml - Authentication configuration
• 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 in security-domain-registry.xml 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.

Auditing

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 security domain
• 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 users session
• 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 was created
  
• 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.

Documentation

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.

Summary

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 business policy.

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.