| 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 authentication (via a login configuration) and access control 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.
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. Active Directory, 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 Cams web 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 Active Directory, an LDAP server, an SQL database and an XML file containing users, passwords and roles. Cams provides a number of configurable login modules, which support Microsoft Active Directory, LDAP v3 servers, 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, PERL and UNIX shell script login, denied and error pages are provided with Cams web agents. You can customize these page or provide your own in any dynamic scripting language supported by your web server.
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 user specific value returned by a web service specific.
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. 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 are native C and Java software components that are integrated with web servers (like Apache, Microsoft IIS and SunOne) and application servers (like BEA WebLogic, IBM WebSphere and Tomcat) to delegate access control checks to a Cams policy server and enforce the associated responses.
When a user makes a request to a web or application server configured with a Cams web agent, the Cams web agent sends an access check request to a Cams policy to determine if the resource is protected. If it is, the Cams web agent enforces the grant or deny answer it receives. Any Cams web agent may also be configured as an authentication proxy to prompt users for authentication credentials using a login form and forward the credentials to a Cams policy server as an authentication request. If the user is authenticated, the Cams web agent redirects the user's browser to the originally requested URL, and the access check is performed again, this time with the known user identity. Cams web agents also provide many other values services when configured to do so.
Each Cams web agent is custom for the web or application server that it supports. Consequently, the components and files included with different Cams web agents may vary, even though each Cams web agent is similar in purpose. From a high level, the components associated with a Cams web agent include:
NOTE: Each Cams web agent includes installation and configuration instructions. Most configuration values are the same for all Cams web agents. Once you become familiar with the most important values, you'll find Cams web agent integration easy.
Program executables and libraries may be Java byte code, native or stand-alone applications that define the Cams web agent programmatic logic and its integration into the web or application server. The installation process described in each Cams web agent document will describe how to install these files into the correct locations. You will not need to modify the Cams web agent, but you will probably need to configure them.
Each Cams web agent includes a cams-webagent.conf configuration file. This file is often placed in the same directory with other configuration files for the web or application server. You use this file to configure the Cams web agent values specific to your installation. For example, you need to inform each Cams web agent of the Cams policy server location, the Cams cluster name, Cams policy server name and the credentials that are required for the Cams web agent to authenticate.
The Cams web agent documentation describes how you'll need to configure each of the properties found in this file (the file also contains informative comments). In addition, each web and application server has a native configuration. You'll typically edit a configuration file (e.g. httpd.conf for Apache or server.xml for Tomcat) to inform the web or application server of the existence of the Cams web agent.
Cams web agents work in conjunction with dynamic HTML pages that prompt users for login credentials and report errors and access denials. Any scripting language may be used like ASP, JSP, PERL, PHP or Cold Fusion. You can use and modify the pages supplied with each Cams web agent or even create your own if needed! Example pages are available using ASP, JSP, PERL and Linux/UNIX shell scripts. The language of the pages is not important, they just need to use certain conventions in order to work with Cams web agents.
NOTE: Each Cams web agent includes a Scripts document in the intallation guide about programming these pages along with information on how to create a dynamic or static logout URL on any page. They're simple scripts to customize or incorporate into your pages.
Cams web agents are easily customized using configuration values in cams-webagent-conf. Here's a list of some additional Cams web agent responsibilities that are enabled by default or can be enabled at any time:
To learn more about Cams web agent installation and configuration, please read the Cams web agent guide included with each Cams web agent (and found at the Cafésoft Documentation Center).
HTTP cookies save server side information within a user's browser. The browser maintains a table of cookies and sends them with each request ONLY to sites from which they originated. Strict Internet-standard rules define cookie creation, modification and use.
Cams uses cookies that are maintained only in the browsers memory and never written to disk to securely store session identifiers. Upon successful authentication, the Cams policy server creates a user session and the Cams web agent sends an HTTP cookie with a secure, encrypted session identifier to your browser in a format that can only be deciphered by the Cams policy server from which it originated using a site and security domain specific key. 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.
Each subsequent request is sent by the browser with the cookie enabling the Cams web agent to send it to the Cams policy server, which uses the cookie to identify the user and authorize requests for protected resources. The cookie remains in browser memory until you logout, exit your browser or your session expires.
With a single Cams session cookie cookies, a valid Cams policy server session provides single sign-on access to secure resources for which you have permission within a single DNS domain, including subdomains. You can use the two right most dots of a fully-qualifed DNS name to determined the hosts that will get a Cams session cookie (for example, any host in .mycompany.com would receive a Cams session cookie created within that domain, such as www.mycompany.com and myhost.mycompany.com).
NOTE: End users can choose to disable cookies in their browsers. You must ensure that they are enabled for sites protected by Cams. If they are not, authentication may be valid but session state is not maintained. The effect is the same as if the user had not authenticated.
© Copyright 1996-2005 Cafésoft LLC. All rights reserved.