Access Manager in the Web environment
This section gives a generalized view of Access Manager integration in the Web environment. Ease of application integration is a key principle that Access Manager adheres to. Though there are many facets to integration, my focus is on how Access Manager can add value to Web application environments. Following are three levels of integration for developers or architects to consider. Each level builds upon the previous level.

Level 1: Web single sign-on
The first level of integration involves configuring Access Manager's WebSEAL smart junctions for any HTTP-compliant Web server or application server with WebSEAL. An example of WebSEAL smart junctioning is in Figure 2 below. By junctioning these servers, WebSEAL can provide Web single sign-on, coarse-grained access control (whether one can access the Web server or not), high availability, and scalability. Level 1 integration is shown in Figure 2.

Figure 2. Web single sign-on

Level 2: URL access control
Level 2 integration enables access control for individual objects on the Web server or application server, and requires placing a small customizable common gateway interface (CGI) script called query_contents on the Web server. This allows the management console to display and manage the Web space, or application space, of the Web and application servers. Access Manager handles access control for static content and dynamic content. With the dynurlcp utility you can place ACLs in components of applications or CGIs. By passing user and group information in the HTTP headers, the application server can make further access control decisions if required. This information passed from WebSEAL can also be used to access back-end applications. Level-2 integration is shown in Figure 3.

Figure 3. Level 2: URL Access Control

Level 3: Web application server aznAPI or J2EE/JAAS integration
With level 3 integration, Access Manager implements aznAPI, which allows an application to call out to an authorization service for authorization decisions. The Access Manager identity information (iv_user, iv_group and iv_cred), passed to the application server by the HTTP header, can be used by aznAPI to make further fine-grained access control decisions based on the specific internals of the application (and any authorization decisions enforced by WebSEAL). Information passed from WebSEAL and obtained from the Access Manager framework can be used to make access decisions to back-end applications. Figure 4 shows level 3 integration.

Figure 4. Level 3: Integration with Access Manager - Web application aznAPI integration

Level 3 integration requires installing aznAPI on the application server, extending or developing the application server to use aznAPI, and loading the application namespace into the Access Manager management server (either by using query_contents or the Access Manager management API). Access Manager is responsible for both authentication and fine-grained access control. With aznAPI, integration can be enhanced by using dynamic roles, which are enabled by Privacy Manager. Access Manager offers Java programmers an alternative to aznAPI by enabling Access Manager as a provider of authentication and authorization services for any 1.3 JVM (and IBM 1.2.x JVMs).