| Back | Next | Contents | Cams Administrator's Guide |
The Cafésoft Access Management System, Cams™, is an easy-to-use, reliable, and cost-effective security platform that centrally controls, administers, and monitors access to secure network applications and data. Administrators decide who gets access to system resources, and Cams enforces the policy and logs the results. Resources protected by Cams can reside on the corporate Internet, an extranet, or the Internet. Cams makes sites more secure and manageable by centralizing application security administration and access, rather than building custom access control systems into each application. This centralized approach reduces development and administration complexity and costs, while improving time to market, application security, and user satisfaction.
As a Cams administrator, you'll need some basic knowledge on how Cams is organized and how it works before you can configure access control, authentication, and auditing. This chapter provides an overview of Cams and refers you to other chapters that contain details on how to administer Cams servers, security services, and agents.
Cams is a centralized access management solution, in which distributed agents delegate security decisions to a central authority - the Cams server. Cams is designed to protect virtually any kind of resource, including: web pages, files, datasources, Enterprise Java Beans, and more. When an agent sends an access control request, an access control service hosted within the Cams server decides whether to grant or deny access to the requested resource, and the requesting agent enforces the decision.
Figure 1 shows a possible Cams deployment in which User 1 attempts to access web resources available on two different web servers. Each web server contains a Cams web agent, which delegates access control and authentication requests to a centralized Cams server. User 2 trys to access an application server hosting servlets, Enterprise Java Beans, and datasources via a custom Java application or applet. The application server also contains an embedded Cams application server agent, which delegates access control and authentication decisions to the Cams server.
Figure 1 - Using Cams for centralized access management
As you can see, Cams enables access control policy and login configuration to be centralized at the Cams server. The Cams server also centralizes user activity logging and security administration. Also, though Figure 1 shows people making resource requests via graphical user interfaces, keep in mind that 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.
At the core of Cams is the Cams server, which hosts a set of cooperative, high-level security services including:
The Cams server is both a policy server and an authentication server handling both access control and authentication requests. Services provided by the Cams server are organized into three logical layers as shown in Figure 2.
Figure 2 - Logical Cams service layers
The network adapter layer enables a Cams server to offer services on different TCP/IP ports and to support network clients that speak different protocols. The service provider layer provides security services like authentication and access control. This abstraction provides the flexibly to use Cams to be extended protect almost any network resources, while reusing the same Servicer Provider Layer services.
Cams agents generally access security services on one TCP/IP port, while administrative services that enable Cams server shutdown and service control are available on another port. This enables you to use a firewall to limit access to certain Cams Services. Of course, you'll also use Cams itself to implement access control and authentication for Cams agents.
The Cams engine layer hosts security domain services, which provide a way to partition resources and users according to administrative needs. So what's a security domain? Read on to find out.
In the Cams security model, resources and user accounts are owned by a specific security domain, which enables access 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.
Each security domain contains it's own set of services, which include:
The first four security domain services mimic those available at the service provider-level. The last two services: session manager and service manager, are unique to security domains. As an administrator, the ones that will interest you most are the access control service and the authentication service, because they are the most configurable. The following sections provide an overview of how each security domain's access control and authentication services are organized so you'll understand how to configure them.
The access control service hosted within each security domain has it's own processing pipeline, called an access control pipeline. This pipeline contains a pluggable sequence of access control valves. By default, the first access control valve configured in Cams logs the request and the last valve (also referred to as the basic valve) uses the security domain-specific access control policy to grant or deny access. The overall structure of components within a security domain's access control service is shown in Figure 3.
Figure 3 - The structure of a security domain's 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: an access control rule that will be evaluated to grant or deny access to the resource, or a security domain to which access control will be delegated. A special system security domain receives all access control requests and delegates most of them to one or more other security domains that you've configured. The system security domain also authenticates Cams system administrators, agents, and protects system-level resources.
Cams includes access control rules that enable you to control access to resources by:
These rules can be customized for your needs and combined into reusable, hierarchical expressions using logical "AND", "OR", and "NOT" operators. In addition, new access control rule types can be created using a programmer's API and plugged into any Cams access control policy. For example, you might want to create a custom rule to grant access to a resource based on a database values such as the amount of money in an account.
A Cams agent sends an access control request to a Cams 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.cafesoft.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 agent. You can learn about how Cams access control services work by reading Access Control Services.
The Authentication service hosted within each security domain also has it's own processing pipeline, called an authentication pipeline. This pipeline contains a pluggable sequence of authentication valves. By default, the first authentication valve logs the authentication request and the last valve (also referred to as the basic valve) attempts authentication based on information contained in an authentication request. The overall structure of components within a security domain's authentication service is shown in Figure 4.
Figure 4 - The structure of a security domain's authentication service
Each security domain has its own login configuration, which configures how clients authenticate. The login configuration contains login configuration entries, one for each type of application that may attempt authentication.
Each Login Configuration Entry references one or more login modules, which enable you to configure authentication against a user repository like an LDAP server, a relational database management system (SQL), and an XML file containing users, passwords, groups, and roles. Cams provides a number of configurable login modules, which are compatible with the Java Authentication and Authorization Service (JAAS) API and are ready to support LDAP, RDBMS (SQL), and XML user repositories. You can also create custom login modules to implement authentication for systems not currently supported by Cams.
You can learn about how the Cams authentication services by reading Login Configuration.
Cams agents are software components that delegate security requests to a Cams server. The purpose of an agent may be to delegate and enforce access control requests to a Cams server or to delegate and enforce authentication requests. The way a Cams agent is installed and configured depends very much on the agent and the environment in which it's installed.
Cams currently supports Web Agents, which are installed within a web servers (like Apache and Tomcat) to enforce access control and authentication on web pages, cgi-bin files, servlets, Java Server Pages, etc. Web agents prompt users requiring authentication using a site specific login page, then delegate the authentication requests to a Cams server with the user's credentials. Web agents support site personalization by making user-specific values available to applications via special HTTP headers.
You can learn how to install and configure the available Cams agents by reading the Apache Web Agent, IIS Web Agent, and Tomcat Web Agent documents.
Web single sign-on enables a user to authenticate on one web server and access resources hosted on other web servers (or other virtual hosts within the same web server) without having to re-authenticate. Cams currently supports web single sign-on functionality within a single DNS domain plus subdomains. Figure 5 shows a user's experience at a site where each web server implements it's own authentication and access control and SSO is not implemented. After the user authenticates with server www.travel.com, then accesses resources on www2.travel.com and payment.travel.com, he must re-authenticate with each server.
Figure 5 - Accessing multiple web servers in a DNS domain without SSO support
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. Figure 6 shows this scenario.
Figure 6 - Accessing multiple web servers in a DNS domain with SSO support
Cams Web Agents support Web SSO by use of HTTP Cookies, which are configured by default in most browsers to work within a single DNS domain. You can learn more about how to configure Web SSO by reading the Apache Web Agent, IIS Web Agent, and Tomcat Web Agent documents.
© Copyright 1996-2003 Cafésoft LLC. All rights reserved.