Application Integration: Sun Java System Access Manager 2004Q2 and JDBC Authentication Module

Print-friendly Version

Today, most user authentication solutions for Web applications are ad hoc and are based on proprietary schema definitions in relational databases. So, if you have multiple Web applications, you may have a separate user database for each of your applications.

Sun Java System Access Manager 2004Q2 (formerly Sun Java System Identity Server and called Access Manager for short) provides an end-to-end, standards-compliant framework for authentication that centralizes configuration of identity according to an extensible framework. By adopting this framework, you can efficiently manage the resources that identities access and, with support from the Liberty architecture and Security Assertion Markup Language (SAML), achieve interoperability with other infrastructures. With the authentication service in Access Manager and minimal revisions in application code, applications can leverage numerous features such as Single Sign-On (SSO) and centralized configuration for authentication and authorization.

The example in this article demonstrates how to authenticate, through Access Manager, accesses to Web applications against databases. Specifically, the example illustrates how to customize a Java Database Connectivity (JDBC) authentication module so that the authentication service of Access Manager can verify user credentials and accord them access to a simple Web application, which calls the authentication service through the Access Manager Software Development Kit (SDK).

This section describes the authentication framework of Access Manager, the encapsulated Java Authentication and Authorization Service (JAAS) API, and their benefits.

The authentication framework in Access Manager is based on JAAS. Specifically, Access Manager

• Implements the authentication portion of JAAS-JAAS PAM modules;
  
  
• Allows the server and the PAM modules it exposes to be interfaced through JAAS authentication APIs; and by the way,
  
  
• Supports JAAS authorization wrappers around the policy framework.

You can wrap proprietary authentication interfaces around a custom authentication module and then plug that module into the Access Manager authentication framework from the Administration Console. Afterwards, Access Manager can manage the new module just as it does other modules on Access Manager, such as the Lightweight Directory Access Protocol (LDAP), UNIX, and RADIUS. You adopt the new module through the authentication service just like other preinstalled module service programming interfaces (SPIs).

Customizing the authentication module involves two major steps:

1. Implementing an interface by applying the package com.iplanet.authentication.spi.
   
   That package contains a series of APIs for creating authentication services--a process that requires the implementation of the JAAS LoginModule and methods for accessing the authentication service and module configuration files. As soon as that architecture is in place, the authentication framework can manage all custom JAAS authentication modules.
   
   
2. Adding the module to the list of available authentication modules.

Although the authentication framework supports pure JAAS pluggable authentication modules, it's simpler and more straightforward to customize the authentication module with the Access Manager authentication SPI. As a rule, you would implement the following four classes:

• Class 1 -- For extending the javax.security.auth.login.Configuration class
  
  
• Class 2 -- For implementing the javax.security.auth.spi.LoginModule interface
  
  
• Class 3 -- For implementing the java.security.Principal interface
  
  
• Class 4 -- For implementing the java.security.PrivilegedAction interface

But to develop pluggable authentication modules with the Access Manager authentication SPI, you can significantly save development cycles because you need implement only two classes:

• One class for implementing com.sun.identity.authentication.spi.AMLoginModule
  
  
• One class for implementing the java.security.Principal interface

The authentication framework offers diverse authentication benefits for a variety of applications:

• For Web applications, the authentication service simplifies the client-side authentication logic by performing almost all authentication tasks.
  
  
• For stand-alone applications written in either C or the Java programming language, the authentication service offers authentication APIs.
  
  
• For applications written in languages other than Java or C, the authentication service offers the XML interface. By employing the URL http://server_name.domain_name:port_number/service_deploy_URI/authservice, an application can open a connection with the HTTP POST method and exchange XML messages with the authentication service. The format is an XML representation of JAAS.

In addition, the authentication service complies with JAAS standards and supports SSO, chain-of-authentication modules, policy-based authorization, the Liberty Alliance specifications, SAML, centralized audit trails, and other advanced security features. On Access Manager, therefore, you can switch to other authentication methods, such as LDAP, UNIX, RADIUS, or certificates. The change is transparent to clients--of course, the new authentication method must use the corresponding authentication information, usually user name and password--and requires only a few clicks in the Access Manager Administration Console to take effect.

The Administration Console, a Web-based GUI, is another benefit offered by Access Manager. From the console, you can customize an authentication module by integrating that module as an authentication service into the Access Manager service management framework. To define the custom service, you need create only two files.

In this section are the business case for adopting the JDBC authentication module and the procedure for implementing that module.

Absent an integration of the Access Manager authentication service into Web applications, businesses usually opt for ad hoc alternatives for authenticating users, such as saving user IDs and passwords into a table in a relational database or other similar approaches. For such applications, businesses need a way to authenticate users against an existing relational database through the Access Manager authentication service. Customers can then benefit from Access Manager features (such as SSO and standards-based, centralized authentication and authorization), and businesses can obviate the need to immediately switch the user database to an LDAP server (Sun Java Enterprise System Directory Server, in the case of Access Manager). Note: You still need an LDAP directory, though, because authorization and profile information tend to require it in many cases in the current version of Access Manager.

The answer to these needs is simple: Develop a custom authentication module with the SPI in the Access Manager authentication SDK and plug this module into the Access Manager authentication framework. All you need to change in the application is the login logic. Instead of a direct authentication to the database with the JDBC API, the Access Manager authentication API completes the login logic.

FIGURE 1 shows the relationship between the JDBC authentication module and the architecture of the Access Manager authentication framework. The user information resides in a PointBase database. A Web-based authentication client calls the module through the Access Manager authentication service.

FIGURE 1: Relationship Between the JDBC Authentication Module and the Architecture of the Access Manager Authentication Framework

The following subsections explain the three steps for implementing the module:

• Customizing a module
  
  
• Configuring the authentication module
  
  
• Defining a custom service for the module

Step I. Customize Your Module.

The abstract class com.sun.identity.authentication.spi.AMLoginModule implements the JAAS login module (LoginModule). Extend that class to implement three methods of AMLoginModule in order to access the Access Manager authentication service, as follows.

The init() method. This is an abstract method that initializes LoginModule with the relevant information. Subsequent to an instantiation of LoginModule and before any calls to LoginModule's other public methods, AMLoginModule calls init(), which may traverse the options to determine the configurations that affect LoginModule's behavior and save the option values in variables for future use. In this example, init() includes JDBC connection parameters, such as the database URL, the table name, the user name and password in the database, and the JDBC driver.

Here is the code for init().

public void init(Subject subject, Map sharedState, Map options) {
        // The return value of options.get() is type of "HashSet"
        dbDriver =
        (String)((HashSet)(options.get("iplanet-am-auth-jdbc-db-
driver"))).iterator().next();
        dbUrl =
        (String)((HashSet)(options.get("iplanet-am-auth-jdbc-db-
url"))).iterator().next();
        dbUserName =
        (String)((HashSet)(options.get("iplanet-am-auth-jdbc-db-
user"))).iterator().next();
        dbPassword =
        (String)((HashSet)(options.get("iplanet-am-auth-jdbc-db-
password"))).iterator().next();
        if (dbUserName == null) dbUserName = "";
        if (dbPassword == null) dbPassword = "";
        if (dbDriver != null) loadDBDriver(this.getClass(), dbDriver);
        //generate the user credential query out of the options
        String dbUserTable =
        (String)((HashSet)(options.get("iplanet-am-auth-jdbc-auth-
table"))).iterator().next();
        String dbUserTableUserField =
        (String)((HashSet)(options.get("iplanet-am-auth-jdbc-auth-
ufield"))).iterator().next();
        String dbUserTableCredentialField =
        (String)((HashSet)(options.get("iplanet-am-auth-jdbc-auth-
cfield"))).iterator().next();
        queryStr =
        "select "+dbUserTableCredentialField+" from "+dbUserTable+" where
"+dbUserTableUserField+"=?";
    }

The process() method. This method implements the actual login logic for authentication. In this example, process() prompts for a user name and password and attempts to verify those credentials against a database. Typically, the process proceeds this way:

1. Perform the authentication.
   
   
2. This next step varies according to the result:
   • If authentication succeeds, save the principal data and return -1.
     
     
   • If authentication fails, as in the case of an incorrect password, process() throws the InvalidPasswordException error and, if the number of login attempts reaches the maximum allowed, locks out the account.
     
     If the failure results from a faulty database connection and other similar problems, process() throws the AuthLoginException error.

Here is the code for process().

public int process(Callback[] callbacks, int state) throws AuthLoginException {
        int currentState = state;
        String userName;
        String passwd;
        try{
            if (currentState == 1) {
                userName = ((NameCallback) callbacks[0]).getName();
                passwd =  new String(((PasswordCallback)callbacks[1]).getPassword());
                if (userName.equals("") || passwd.equals("")) {
                    throw new AuthLoginException("names must not be empty");
                }
                //load user from database
                if ( dbLogin(userName,passwd) ) {
                    userTokenId = userName;
                    return -1;//return -1 for login successful;
                }else{
                    throw new InvalidPasswordException ("InvalidPassword");
                }
            }else{

                throw new AuthLoginException("Login failed!");
            }
        } catch (SQLException e){
              throw new AuthLoginException("Login failed with SQLException");
        } catch (ClassNotFoundException e){
              throw new AuthLoginException("Login failed with ClassNotFoundException");
        }
    }

The getPrincipal() method. Call this method once only at the end of a successful authentication session. A login session is considered successful when the module has sent all login pages and has thrown no exceptions. This method retrieves the authenticated token string--the user ID in the Access Manager environment.

Here is the code for getPrincipal().

public java.security.Principal getPrincipal() {
        if (userPrincipal != null) {
            return userPrincipal;
        } else if (userTokenId != null) {
            userPrincipal = new SamplePrincipal(userTokenId);
            return userPrincipal;
        } else {
            return null;
        }
    }

Step II. Configure the Authentication Module.

Each authentication module has its own configuration file in XML format, located in Access_Manager_dir/SUNWam/web-apps/services/config/auth/default. That configuration file, named module_name.xml, for the authentication module defines the information required for authentication. Modifying the elements in this file automatically and dynamically customizes the authentication interface. In this example, the user name and password used by the callback method are in the configuration file called JDBC.xml.

Note - Access Manager also uses this configuration file to automatically generate login Web pages for users. In this example, a page based on the JavaServer Pages (JSP) technology collects the authentication information; the page generated by Access Manager is not in use here.

Here is the code for ModuleProperties().

<ModuleProperties moduleName="JDBC" version="1.0" > 
	<Callbacks length="2" order="1" timeout="60" 
			header="This is a DB login module sample page" > 
			<NameCallback> 
				<Prompt> User Name </Prompt> 
			</NameCallback> 
			<PasswordCallback echoPassword="false" > 
				<Prompt> Password </Prompt> 
			</PasswordCallback> 
	</Callbacks> 
</ModuleProperties> 

Step III. Define a Custom Service for the Module.

In Access Manager, a service is a means of managing groups of attributes with a particular focus and scope. To define a JDBC service managed by Access Manager, you create an XML service file. A localization properties file specifies the screen text and messages that an administrator or user sees when directed to the service attribute configuration page of a JDBC authentication module.

The XML service file will be imported into Access Manager. Once the service is imported, you can register it to any organization and manage or customize its attributes through the Access Manager Administration Console. You must copy the localization properties file to the Access_Manager_dir/SUNWam/locale directory. For detailed steps of defining a custom service, refer to the Access Manager documentation.

Note - The name of a service (other than the name of an authentication module) as defined in the XML service file can be any unique string. The name of an authentication module service as defined in the XML service file must be in the form iPlanetAMAuth_module_nameService. In our example, the name is iPlanetAMAuthJDBCService.

The content in the localization file amAuthJDBC.properties. is shown below.

iplanet-am-auth-jdbc-service-description=JDBC
a101=Database Driver Classname
a102=Database URL
a103=Database user
a104=Database password
a105=UserInfo Table Name
a106=UserID field
a107=Credential field

The content in the file amAuthJDBC.xml is shown below.

<?xml version="1.0" encoding="UTF-8"?>

<!--
    Copyright (c) 2004 Sun Microsystems, Inc. All rights reserved
    Use is subject to license terms.
-->

<!DOCTYPE ServicesConfiguration
    PUBLIC "=//iPlanet//Service Management Services (SMS) 1.0 DTD//EN"
    "jar://com/sun/identity/sm/sms.dtd">
<ServicesConfiguration>
    <Service name="iPlanetAMAuthJDBCService" version="1.0">
        <Schema
            serviceHierarchy="/DSAMEConfig/authentication/iPlanetAMAuthJDBCService"
            i18nFileName="amAuthJDBC"
            i18nKey="iplanet-am-auth-jdbc-service-description">
	    
            <Organization>
                <AttributeSchema name="iplanet-am-auth-jdbc-db-driver"
                    type="single"
                    syntax="string"
                    i18nKey="a101">
                    <DefaultValues>
                        <Value>com.pointbase.jdbc.jdbcUniversalDriver</Value>
                    </DefaultValues>
                </AttributeSchema>

                <AttributeSchema name="iplanet-am-auth-jdbc-db-url"
                    type="single"
                    syntax="string"
                    i18nKey="a102">
                    <DefaultValues>
                        <Value>jdbc:pointbase://127.0.0.1:9092/sample</Value>
                    </DefaultValues>
                </AttributeSchema>

                <AttributeSchema name="iplanet-am-auth-jdbc-db-user"
                    type="single"
                    syntax="string"
                    i18nKey="a103">
                    <DefaultValues>
                        <Value>PBPUBLIC</Value>
                    </DefaultValues>
                </AttributeSchema>
                <AttributeSchema name="iplanet-am-auth-jdbc-db-password"
                    type="single"
                    syntax="password"
                    i18nKey="a104">
                    <DefaultValues>
                        <Value>PBPUBLIC</Value>
                    </DefaultValues>
                </AttributeSchema>

                <AttributeSchema name="iplanet-am-auth-jdbc-auth-table"
                    type="single"
                    syntax="string"
                    i18nKey="a105">
                    <DefaultValues>
                        <Value>user_t</Value>
                    </DefaultValues>
                </AttributeSchema>

                <AttributeSchema name="iplanet-am-auth-jdbc-auth-ufield"
                    type="single"
                    syntax="string"
                    i18nKey="a106">
                    <DefaultValues>
                        <Value>uid</Value>
                    </DefaultValues>
                </AttributeSchema>

                <AttributeSchema name="iplanet-am-auth-jdbc-auth-cfield"
                    type="single"
                    syntax="string"
                    i18nKey="a107">
                    <DefaultValues>
                        <Value>passwd</Value>
                    </DefaultValues>
                </AttributeSchema>
            </Organization>
        </Schema>
    </Service>
</ServicesConfiguration>

You can use the Web-based authentication service user interface in Access Manager for all out-of-the-box authentication modules installed in the Access Manager deployment. This interface consists of one or more login pages that are based on the requirements of the invoked authentication module. You can customize these pages so that their look and feel accords with other Web pages in your application.

To minimize the modifications to an existing application, our example uses "0-page login." That way, the existing login page remains; it forwards the authentication request to Access Manager by encoding the login information into the URL by means of the login URL parameters provided by Access Manager.

Caution - The example technique could represent a fairly major security issue. Since you're encoding these as http GET strings, the password value will be logged in clear text in the deployment containers access logs.

FIGURE 2 illustrates the authentication and SSO flow when a user accesses the example Web application through the Access Manager authentication service.

FIGURE 2: Authentication and SSO Flow of Access Manager Authentication Service

In the login process, the developer of the authentication client assembles the URL from a login request. A typical URL used for login is (all on one line)

http://server_name.domain_name:port_number/amserver/UI/
Login?IDToken1=userid&IDToken2=password&org=orgName
&module=JDBC&goto=success_login_page&gotoOnFail=login_fail_page

where

• IDToken1 and IDToken2 parameters are used by the JDBC authentication module for user ID and password, respectively.
  
  
• org parameter enables a user to authenticate as a user in the organization specified by orgName.
  
  
• module parameter allows authentication by the authentication module specified by moduleName (here, JDBC).
  
  Note: Typically, org and module are not needed; at most, you might use one or the other.
  
  
• goto parameter links to the URL specified by success_login_page after successful authentication against the database.
  
  
• gotoOnFail parameter links to the URL specified by login_fail_page if a user fails authentication.

In the logout process, the goto=logout_URL parameter links users to a desired Web page after logout. For our example, the logout URL is (all on one line) http://server_name.domain_name:port_number/amserver/UI/
Logout?goto=http://web_servername:port_number/authsample/index.html.

After authentication, a user can access other authentication-required pages without logging in again. The SSO token API checks the SSO token in the request to determine whether the user has already been authenticated. To extract the SSO token from the request in order to validate the token, add the following code to each authentication-required page.

. . .
    SSOTokenManager ssoManager = SSOTokenManager.getInstance();
    SSOToken ssoToken = null;
    String orgName = "";
    try{
        ssoToken = ssoManager.createSSOToken(request);
      . . .
    }catch(Exception e){
        // Exception handling
    }
    if (ssoToken != null && ssoManager.isValidToken(ssoToken)) {
				// Allow access to the requested page
			} else {
				// Forward to an error page, which prompts user to 
				// log in
			}
        . . .

To minimize the modifications to an existing application, this piece of code mimics the behavior of the Access Manager policy agent.

Note - Access Manager provides agents for most current Web server and application server products. When using an Access Manager policy agent to protect your Web resources, configure policies in the Access Manager Administration Console. For information about policy agents, see J2EE Policy Agents Guide.

The environment for compiling, deploying, and executing the example is a Solaris environment consisting of the following entities:

• Sun Java Enterprise System Access Manager
  
  
• Sun Java Enterprise System Application Server 7 (hereinafter called Application Server) update 1 as the Web container
  
  
• JDK version 1.3.1_06 or higher
  
  
• PointBase relational database server bundled with Application Server to store the user table The user information table is a very simple database table that contains only two fields: the user ID and the user password.
  
  
• GNU make as the build tool
  
  
• All the source code and the Make file, which are packed into AuthModule.zip.

Before proceeding, download the authentication module to any directory and unzip it.

To compile the module:

1. Go to the directory of the source code sample_code_root/module.
   
   
2. Edit the Make file to change the following environment variables as appropriate for your environment:
   
   
   • BASE_DIR: Where Access Manager is installed
     
     
   • WORK_DIR: Where the source code of the JDBC authentication module is unzipped
     
     
   • JAVA_HOME: Where the JDK is installed
   
   
   
3. Modify the login URL in Login.jsp before compiling and packaging the example.
   
   
4. Invoke gmake all to install the JDBC authentication module into Access Manager.

To compile the Web application:

1. Go to the directory of the source code sample_code_root/webclient.
   
   
2. Edit the Make file to change the following environment variable in accordance with your environment:
   
   JAVA_HOME: Where the JDK is installed.
   
   
3. Invoke gmake to generate the Web archive (WAR) file.

You deploy the example by deploying the module, JDBC authentication service, and the Web application, as explained below.

To deploy the module:

1. Log in to the Access Manager Administration Console as amadmin, specifying the URL as follows: http://server_name.domain_name:port_number/console_deploy_URL
   
   
2. Select the Service Configuration tab in the top frame.
   
   
3. In the Service Configuration frame (the left frame), select Authentication and then select Core.
   
   
4. In the right frame of Pluggable Auth Modules Classes, add the class file name: com.sun.identity.samples.authentication.modules.jdbc
   
   
5. Log in to Access Manager Administration Console as amadmin at http://server_name.domain_name:port_number/console_deploy_URI
   
   For example, http://lionet.prc.sun.com:8000/amconsole
   
   
6. Select the Identity Management tab view and select your organization.
   
   Note: If you have not created a suborganization, create one now by clicking the New button in the left frame.
   
   
7. Select Services from the View drop-down list.
   
   
8. Click Core in the navigation frame under Authentication.
   
   Note: If no registered service is listed, register Core under Authentication by clicking the Register button in the left frame. Create the service template for it when you are asked to do so.
   
   
9. Add JDBC to the list of highlighted modules in the Organization Authentication Modules attribute.
   
   
10. Select Ignored in the User Profile attribute.
    
    
11. Click Save to save the changes.
    
    
12. Log out and restart Access Manager.

To deploy the service:

Before deployment, verify that the PointBase relational database server bundled with Application Server contains a table named user_t with two attributes: uid and passwd. Create the table now if necessary.

Note - The Access Manager GUI is similar to that of Sun Java System Identity Server.

1. Import JDBC Authentication Service to Access Manager. Type (all on one line):
   Access_Manager_dir/SUNWam/bin/amadmin --runasdn uid=amAdmin,ou=People,default_org,root_suffix --password password --schema amAuthJDBC.xml
   
   
2. Copy the properties file amAuthJDBC.properties to Access_Manager_dir/SUNWam/locale.
   
   
3. Log in to the Access Manager Administration Console and register JDBC authentication service in the top-level organization, as shown in FIGURE 3.
    
   

   FIGURE 3: Registering JDBC Authentication Service with Access Manager

    
   
   
   
4. Register JDBC Authentication Service to the organization at which you want users to have the new service, as shown in FIGURE 4.
    
   

   FIGURE 4: Registering JDBC Authentication Service with an Organization

    
   
   
   
5. Configure the attributes for the JDBC login module from the Access Manager Administration Console, as shown in FIGURE 5.
    
   

   FIGURE 5: Configuring JDBC Login Module Attributes

    
   
   
   
6. Redeploy the service's WAR file by running the install script that corresponds to the Web container on which these samples are deployed.
   
   For example, if the samples are deployed on Application Server, run amas70config. For Sun Java System Web Server, run the amws61config script found in Access_Manager_dir/SUNWam/bin.

To deploy the Web application:

1. Add the location of JDBC login module Java archive (JAR) file to the class path of the Java virtual machine (JVM) of the Web container on which this Web application will run.
   
   For example, suppose that the Web container in which you want to deploy the Web application is on the same machine as Access Manager. In that case, you would add $(BASE_DIR)/SUNWam/web-apps/services/WEB-INF/lib/JDBC.jar to the JVM class path of your Web container (say, Sun Java System Web Server or Application Server).
   
   
2. From the Application Server Administration Console, deploy on the Web container the WAR file that you generated in the sample_code_root/webclient directory when you compiled the Web application.
   
   Note: The WAR file can be different from the Web container in step 1.
   
   
3. Set the deployment URL.
   
   The URL is relative to the entire URL and in our example is /authsample.

To execute the module:

1. Open a browser on any machine that can connect to the Web server on which the sample application is running.
   
   
2. Supply the URL address to the browser by entering
   
   http://server_name.domain_name:port_number/authsample

   The login page of the example application is displayed.

   The following screens are displayed while the Web application is running:

   • FIGURE 6 - Login page
   • FIGURE 7 - Welcome page
   
   

   One of the following screens is also displayed, depending on success or failure.

   • FIGURE 8 - Accessed protected page
   • FIGURE 9 - Error page

Note - The Access Manager GUI is similar to that of Sun Java System Identity Server.

FIGURE 6: Login Page

FIGURE 7: Welcome Page After Login

FIGURE 8: Protected Page as Accessed After Authentication

FIGURE 9: Error Page When Unauthenticated User Tries to Access a Protected Page

The robustness of Access Manager accommodates creative exploitation of the Access Manager/JDBC integration. This section describes a few examples.

Developers know the importance of debugging. The logging services of Access Manager assist you in debugging your authentication module by letting you control the amount of generated debug information and enabling you to determine which part of authentication caused a problem.

Controlling the Volume of Information

Should you want all the debug information generated by a service within Access Manager, first make sure you have enough disk space to hold megabytes' worth of generated debug information.

To specify collection of all debugging data, change the debug-level setting in the configuration file Access_Manager_dir/SUNWam/lib/AMConfig.properties to

com.iplanet.services.debug.level=message

Then restart Access Manager.

The default location of debug files is /var/opt/SUNWam/debug. When you begin examining the files, start with amAuth. You can solve most problems related to authentication by careful study of this file. Other files in this directory provide detailed information for all the services of Access Manager.

Isolating Errors

When you encounter problems, you can isolate the source of errors by testing the module and the authentication client separately.

To test the JDBC authentication module separately, do the following:

1. Log in to the Access Manager Administration Console by entering the URL http://server_name.domain_name:port_number/amserver/UI/Login?org=orgName
   
   For example, http://lionet.prc.sun.com:8000/amserver/UI/Login?org=mde
   
   A login page similar to the example's login page is displayed.
   
   
2. Enter your user name and password to log in to the Access Manager Administration Console.
   
   Success or failure of the login demonstrates the accessibility of the authentication client.

In a production environment, you can improve the performance of the database connection by using the JDBC connection pool in Java 2 Platform, Enterprise Edition (J2EE) containers rather than using a dedicated database connection obtained with the process() method.

To use a pooled connection from the pool:

1. Look up the pool's Java Naming and Directory Interface (JNDI) name.
   
   The JNDI lookup uses the JNDI name of the deployed JDBC connection pool in the Web container to obtain a resource manager connection factory.
   
   
2. Replace the database connection code in init() of the JDBC.java class with the following code.
   
   

   InitialContext ic = new InitialContext(); DataSource ds = (javax.sql.DataSource) ic.lookup("java:comp/env/jdbc/JDBCAuthModulePool"); Connection conn = ds.getConnection();

   

   You can then retrieve and cache the data source with the init() method.

Note - Access Manager 2004Q2 contains an excellent JDBC authentication example that includes support for pooled connections.

Many users, particularly ISVs, want to be able to smoothly switch the user information repository from the database to an LDAP server. In effect, they want two separate user information repositories to contain the same user information data and to remain synchronized. That way, ISVs can develop new applications entirely based on Access Manager's network identity solution, meanwhile having their deployed applications still run as advertised.

Here's how you can help.

• First, implement AMPostAuthProcessInterface, contained in the Access Manager SDK package com.sun.identity.authentication.sp, to do some postauthentication processing. Name the class, for example, JDBCAMPostAuthProcessIMPL. Execute the implementation on successful or failed authentication or on logout.
  
  
• Next, after a successful authentication, use the onLoginSuccess() method to retrieve from the database all the attributes you want to duplicate to Access Manager, and create a profile with the Access Manager SDK.
  
  
• Then, if the user information will change frequently, add code to onLoginSuccess() to check any modification and to synchronize the two user information repositories.

To add the postauthentication processing class to the Access Manager services, do the following:

1. Log in to the Access Manager Administration Console as amadmin at
   http://server_name.domain_name:port_number/console_deploy_URI.
   
   For example, http://lionet.prc.sun.com:8000/amconsole
   
   
2. Select the Identity Management tab view and select your organization.
   
   
3. Select Services from the View drop-down list.
   
   
4. In the navigation frame under Authentication, click Core.
   
   
5. Enter the class name of your implementation.
   
   In our example, this is JDBCAMPostAuthProcessIMPL.
   
   
6. To the J2EE container's Java Classpath setting, add the path that locates the class.

• Sun Java System Access Manager:
  • Main page
  • Developer home
  • Collection of documentation
        Service Management
        Defining a Custom Service
        J2EE Policy Agents Guide
  
• Sun Java System Application Server:
  • Main page
  • Developer home
  
• A Brief Introduction to Liberty
  
  
• Security Assertion Markup Language (SAML)
  
  
• JAAS (Java Authentication and Authorization Service)

We are indebted to the following people:

• Bin Lu from the Sun Java System Access Manager product team for his valuable input
  
  
• Chuck Mortimore for his advice, comments, and suggestions while reviewing and re-reviewing the article
  
  
• Cherry Shu for testing and improving the procedure steps
  
  
• Marina Sum and Mary Lou Nohr for their editorial assistance

Jie Shen and David Zhu Zansong are senior technical staff in the Market Development Engineering at Sun. Jie has eight years of experience in software development and technical consulting. He puts his five years of IT experience (the last two at Sun) toward assisting Chinese ISVs in the financial service industry with their adoption of Solaris Operating System and Sun Java Enterprise System. David has more than 12 years of IT experience, the last two at Sun providing technical consultation to Sun's partner software vendors in the China energy and power industry.