| Back | Next | Contents | Cams Administrator's Guide |
As a Cams administrator, knowledge of how Cams is organized will be helpful when you begin to configure authentication and access control. This document provides a brief overview of Cams and refers you to other documents where you'll find more information.
Cams is a centralized web security solution, in which Cams web agents delegate security decisions to a central security authority - the Cams policy server. The Cams policy server is designed to protect any kind of web resource, including web pages, files, dynamic web applications, and even non-web resources. When a Cams web agent sends an access control request, an access control service hosted within the Cams policy server decides whether to grant or deny access, and the requesting Cams web agent enforces the decision. If the access to the protected web resource requires authentication, the Cams policy server will notify the Cams web agent, which then prompts the user to login by displaying a registered login page. The user will generally enter a username and password, then submit them to the web server, where the Cams web agent intercepts the credentials and delegates an authentication request to the Cams policy server. If the user is successfully authenticated, the HTTP request is forwarded to the originally requested URL (the one that required successful authentication for access), otherwise an error is displayed.
Figure 1 shows a Cams deployment where two Cams policy servers are configured to provide failover and load balancing. Each Cams policy server uses its own instance of the same security policy and each accesses the same user directory to authenticate users. Cams web agents delegate authentication and access control requests to the Cams policy servers on a round robin basis. If one Cams policy server fails, then all requests are routed through the other. Given sufficient hardware resources any number of Cams policy servers can be deployed at a site (including only one) and any number of Cams web agents can connect to a Cams policy server.
Figure 1 - Cams web agent and Cams policy server deployed in a failover and load balanced architecture
Use of Cams enables login configuration (for authentication) and access control policy to be implemented with the Cams policy server, which centralizes security administration and security event logging. Also, though Figure 1 implies that users are making resource requests with a graphical user interface, a user could also be computer. For example, a user could be a business partner order entry system placing an automated, secure order at your site.
The server-based approach to web application security provided by Cams greatly simplifies the task of web application security programming, maintenance, and administration, while minimizing security vulnerabilities at your site. At the same time Cams provides users with web single sign-on to multiple resources reducing the support burden, user frustration, and cost of password resets that are imposed by sites with multiple sign-ons (and user accounts).
The Cams policy server has a service oriented architecture that handles authentication, access control, session management, and more. Cams web agents generally access these security services on one TCP/IP port, while administrative services that enable Cams policy server shutdown and service control are available on another port. This enables you to use a firewall to limit access to certain Cams services based on the TCP/IP port. You also use Cams itself to implement access control for connecting Cams web agents.
In the Cams security model, services and resources are owned by a security domain. This division enables security management to be partitioned according to organizational or physical boundaries as shown in Figure 2. Different security domain resources may be configured and managed by different individuals, departments, and even companies.
Figure 2 - Cams security domains enable security management to be delegated
Cams security domains are declared in a security domain registry. The system security domain is required and is often the only security domain at many sites. The system security domain handles authentication of Cams web agents and is the root for delegation of resource permissions to other security domains. Any number of additional security domains can be created and hierarchically nested as required by your organization's security policy.
Each security domain contains its own set of services, which include:
Each Cams security domain has three configuration files and an optional Cams user directory (cams-users.xml) as shown in Figure 3. These configuration files are persisted to disk in XML format by default, but can be saved to other storage systems such as an LDAP directory or SQL database.
Figure 3 - Security domain services are configured in three required XML files
All security domain services are configured in security-domain.xml. Values in login-config.xml configure user directories (e.g., LDAP and SQL databases) and how Cams requests authentication credentials from users. The access-control-policy.xml file defines the rules and permissions that protect web resources and access to the Cams policy server by agents. As a Cams administrator, the authentication and access control services will be of greatest interest to you. The following sections provide an overview of how each security domain's authentication and access control services are organized.
You can learn how to configure Cams security domains by reading Security
Domain Configuration.
User authentication is performed against one or more user directories as specified in a security domain's login configuration. By default, a login configuration is stored in a security domain's login-config.xml file. Each login configuration can reference one or more user directories within a login configuration entry, which are accessed in order with specified success/fail dependencies between them as shown in Figure 4.
Figure 4 - The Cams policy server authenticates users against standard user directories
Each login configuration entry references one or more login modules, which enables you to configure authentication against a user directory like an LDAP server, an SQL database, and an XML file containing users, passwords, groups, and roles. Cams provides a number of configurable login modules, which support LDAP v3 servers, Microsoft Active Directory, SQL databases, and XML user repositories. Developers can also use the Cams API to create custom login modules that implement authentication for user directories not currently supported.
Cams web agents support FORM authentication with username and password credentials. If you require other authentication credentials such as an account number, a postal code, or a social security number, you can easily extend Cams to support your requirements.
Figure 5 - Cams FORM authentication uses customizable login, denied, and error pages
Figure 5 shows the use of Cams login, denied, and error pages on a web server with a Cams web agent. These dynamic pages enable Cams to prompt for user credentials and to return contextual error and access denied messages to the user. In a farm of web servers protected by Cams, any or all Cams web agents can be configured to serve these pages. Example JSP, ASP, and shell script login, denied, and error pages are provided with Cams web agents.
Cams supports both lazy and proactive authentication. With proactive authentication, you login before accessing a secure resource. With lazy authentication, you login when prompted by Cams after requesting a resource requiring authentication.
You can learn how to configure the Cams authentication service by reading Login Configuration.
Each security domain protects resources it owns using an access control policy, which is a list of permissions and access control rules. By default, an access control policy is stored in a security domain's access-control-policy.xml file. Standard Cams access control rules include:
Figure 6 - A Cams security domain's access control policy is defined by rules and permissions
Existing access control rules can be combined into new, reusable rules using AND, OR, and NOT operators. Custom 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.
Cams access control policy permissions associate resources (e.g., web URLs) with one of two possible actions: an access control rule that will be evaluated to grant or deny access or a security domain to which access control will be delegated. For HTTP resources, a permission is comprised of three elements:
Every grant or deny access control decision by Cams is based upon a security domain permission. The system security domain receives all access control requests and may delegate them to other security domains if specified by a permission. Permission delegation is a powerful concept that allows access control management to be distributed throughout an organization or across organizational boundaries.
A Cams web agent sends an access control request to a Cams policy server to check a user's access to a resource. The access control request contains information about the requested resource including a resource type, a unique resource identifier, and one or more requested actions. For example, the following resource request parameters correspond to a user accessing http://www.mycompany.com/index.html via a web browser:
The access control request also contains other parameters that may be important for deciding whether to grant or deny access like:
Ultimately an access control service within a Cams security domain will handle the request and populate an access control response, which will be returned to the Cams web agent to enforce.
You can learn how to configure Cams access control services by reading Access Control Services.
Cams keeps accurate tabs on authentication, access control, and session information. Each Cams security domain writes up to five configurable logs as show below. By default, Cams writes logs to text files but can use other storage types like a database. Logs are also maintained by the Cams policy server for system-level information and by Cams web agents.
NOTE: Cams logs are extremely valuable during site configuration and debugging. Look in console.log, system-trace.log, and cams-server.log to see system-level output. Look in the authentication log to see if authentication is occuring as expected. Each service-level log file name is prepended with the name of the security domain to which it belongs. You can also set debug flags in many locations within a security domain's configuration file, the Cams policy server configuration file, and Cams web agent configuration files to see more verbose output.
You can learn more about Cams security domain logging options by reading the
log section for each of the Cams services in Security
Domain Configuration.
Cams web agents are native C and Java software components that are installed within web servers (like Apache and Microsoft IIS) and J2EE application servers (like BEA WebLogic and Tomcat). The primary role of a Cams web agent is to delegate access control checks to a Cams policy server and to enforce the associated responses. Any Cams web agent may also be configured to prompt users for authentication credentials and forward them to a Cams policy server.
Cams web agents enforce access control on static files like web pages and images as well as dynamic web applications created using JSP/servlet, ASP.Net, PHP, Cold Fusion, CGI, etc. A Cams web agent configured for authentication services sends the Cams login page to the user's browser when authentication is requested by a Cams policy server. When the user submits the login form, the Cams web agent delegates the authentication check to a Cams policy server. If the user is authenticated, the Cams web agent redirects the user's browser to the originally requested URL.
Cams web agents enable site personalization and fine-grained access control by making user-specific session values available to web applications via secure Cams HTTP request headers. All confidential traffic sent between a Cams web agent and Cams policy server is encrypted by default. Other configuration values are available to enable features such as access control check caching, logging, etc.
You can learn how to install and configure specific Cams web agents by reading the web agent guides found at the Cafesoft Documentation Center.
A valid Cams policy server session provides you with single sign-on access to secure resources for which you have permission within a single DNS domain, including subdomains. Upon successful authentication, Cams creates a user session and sends an HTTP cookie with a secure, encrypted session identifier to your browser. Other values are optionally hashed with the session identifier to provide greater security such as the IP address of the remote user, the browser user agent, etc. The cookie remains in browser memory until you logout, exit your browser, or your session expires. Cookies must be enabled in the user's browser for Cams web security to work correctly.
© Copyright 1996-2004 Cafésoft LLC. All rights reserved.