Skip Headers

Oracle Application Server Containers for J2EE Services Guide
10g (9.0.4)
Part Number B10326-01
Go To Documentation Library
Home		 Go To Product List
Solution Area		Go To Table of Contents
Contents		 Go To Index
Index

Go to previous page Go to next page

8
J2EE Connector Architecture

This chapter describes how to use the J2EE Connector Architecture (JCA) 1.0 in an Oracle Application Server Containers for J2EE (OC4J) application. This chapter covers the following topics:

Introduction

The J2EE Connector Architecture defines a standard architecture for connecting the J2EE platform to heterogeneous Enterprise Information Systems (EISs). Typical EISs include Enterprise Resource Planning (ERP), database systems, mainframe transaction processing, and legacy applications that are not written in the Java programming language. Figure 8-1 shows the J2EE Connector Architecture.

Figure 8-1 J2EE Connector Architecture

Text description of o_1035.gif follows

Text description of the illustration o_1035.gif

Resource Adapters

A resource adapter is a driver that an application server or an application client uses to connect to a specific EIS. Examples of resource adapters are a JDBC driver to connect to a relational database, an ERP resource adapter to connect to an ERP system, and a transaction processing (TP) resource adapter to connect to a TP monitor. The J2EE 1.3 specification requires application servers to support both standalone and embedded resource adapters.

Standalone Resource Adapters

A resource adapter module that can be deployed directly into an application server independent of other applications is called a standalone resource adapter. These adapters, which are stored in standalone resource adapter archive (RAR) files, are available to all applications that are deployed in the application server instance. See "Example of RAR File Structure" for an example of the contents and structure of an RAR archive.

Embedded Resource Adapters

A resource adapter module that is deployed as part of a J2EE application that also contains one or more J2EE modules, is called an embedded resource adapter. These adapters are available only to the J2EE applications with which they are bundled in an enterprise application archive (EAR) file.

Example of RAR File Structure

Here is an example of the contents and structure of an RAR archive: 

/META-INF/ra.xml
/META-INF/oc4j-ra.xml
/howto.html
/images/icon.jpg
/ra.jar
/cci.jar
/win.dll
/solaris.so

Note:

The JAR files that are referred to in the RAR file can be located in any directory within the archive.

Note:

The file /META-INF/oc4j-ra.xml is not generally part of the RAR archive provided by the RAR vendor, and is typically generated by OC4J during deployment. But a deployer can choose to add the file oc4j-ra.xml to the RAR archive before deployment. Alternatively, the deployer can edit the generated file.

Depending on the resource adapter, applications or application modules might need to access adapter-specific classes that are bundled with the RAR. In the case of standalone resource adapters, these custom classes are available to all applications that are deployed within OC4J. In the case of embedded resource adapters, they are available only to modules that are part of the same application as the embedded adapter.

The ra.xml Descriptor

The ra.xml descriptor is the standard J2EE deployment descriptor for resource adapters. For details, see the J2EE Connector Architecture 1.0 specification.

Application Interface

The client API furnished by a resource adapter can be either a client API that is specific to the type of a resource adapter and its underlying EIS, or the standard Common Client Interface (CCI). For more information on CCI, see the J2EE Connector 1.0 Specification. An example of a client API is JDBC, the client API that is specific to relational database accesses.

You can determine what client interface a resource adapter supports. The client interface is specified in the <connection-interface> element in the ra.xml file bundled in the RAR archive.

Quality of Service Contracts

J2EE Connector Architecture also defines three Quality of Service (QoS) contracts between an application server and an EIS.

All resource adapters must support their side of the QoS contracts to be pluggable into application servers.

Deploying and Undeploying Resource Adapters

This section discusses the details of deploying and undeploying resource adapters.

Deployment Descriptors

OC4J supports three deployment descriptors: ra.xml, oc4j-ra.xml, and oc4j-connectors.xml. The ra.xml descriptor is always supplied with the resource adapter. Whenever you deploy a resource adapter, OC4J generates oc4j-ra.xml if the file doesn't already exist in the archive. In addition, for an embedded resource adapter, OC4J generates oc4j-connectors.xml if it doesn't exist in the archive.

The oc4j-ra.xml Descriptor

The oc4j-ra.xml descriptor provides OC4J-specific deployment information for resource adapters. The file contains one or more <connector-factory> elements.

You can do the following using oc4j-ra.xml:

The oc4j-connectors.xml Descriptor

The resource adapters that are deployed to OC4J can be configured through the oc4j-connectors.xml descriptor. There is one oc4j-connectors.xml file for all of the standalone adapters (as a group) as well as one per application.

Note:

The file /META-INF/oc4j-connectors.xml is not generally part of the EAR archive provided by the EAR vendor, and is typically generated by OC4J during deployment. But a deployer can choose to add the file oc4j-connectors.xml to the EAR archive before deployment. Alternatively, the deployer can edit the generated file.

The root element is <oc4j-connectors>. Each individual connector is represented by a <connector> element that specifies the name and path name for the connector. Each <connector> element contains the following elements:

Standalone Resource Adapters

During deployment of standalone resource adapters, give each a unique name for future operations, such as undeployment of the resource adapter. OC4J does not permit deployment of two standalone resource adapters that have the same name.

The deployment descriptors and decompressed RAR files are located as shown in Table 8-2.

Deployment

During deployment, OC4J decompresses the RAR file and creates OC4J-specific deployment descriptor files if they do not exist already. The deployment process automatically adds <connector> entries in the oc4j-connectors.xml file. Skeleton entries for <connector-factory> elements are created as well in oc4j-ra.xml. The deployer can edit these two files for further configuration. For more information, see the Oracle Application Server 10g Administrator's Guide.

You deploy standalone resource adapters in one of the following ways:

Deploying and Undeploying Using dcmctl

To deploy a standalone resource adapter to an Oracle Application Server instance, use the command-line tool dcmctl with the deployApplication option. Here is the syntax: 

dcmctl deployApplication -f example.rar -a example

The deployApplication switch is supported by additional command-line switches:

To remove a deployed resource adapter, dcmctl with the undeployApplication option. Here is the syntax: 

dcmctl undeployApplication -a example

The required -a argument specifies which adapter is being removed.

dcmctl supports RAR files, as well as WAR and EAR files. For more information, see the Oracle Application Server 10g Administrator's Guide.

Deploying and Undeploying Using admin.jar

To deploy a standalone resource adapter to an OC4J standalone instance, use the command-line tool admin.jar with the -deployconnector switch. Here is the syntax: 

-deployconnector -file mypath.rar -name myname -nativeLibPath libpathname 
-grantAllPermissions

The -deployconnector switch is supported by additional command-line switches:

Example: 

java -jar admin.jar ormi://localhost admin welcome -deployconnector -file 
./myRA.rar -name myRA

Note:

For more information about admin.jar, see the Oracle Application Server Containers for J2EE Stand Alone User's Guide. You can download this document when you download the OC4J standalone product from OTN.

To remove a deployed resource adapter, use the -undeployconnector switch of admin.jar. Here is the syntax: 

-undeployconnector -name myname

The required -name argument specifies which adapter is being removed. This command removes all <connector> entries that use the specified resource adapter from oc4j-connectors.xml and deletes the directories and files that were created during deployment.

Embedded Resource Adapters

Embedded resource adapters cannot be deployed or undeployed independent of the application of which they are a part. The name of the adapter can be specified in the oc4j-connectors.xml file; if not specified in this file, the name used for the adapter is that of the RAR archive.

The deployment descriptors and decompressed RAR files are located as shown in Table 8-2.

Deployment

As part of deploying the EAR file that contains the embedded resource adapter, OC4J decompresses the RAR file and creates OC4J-specific deployment descriptor files if they do not exist already. The deployment process automatically adds <connector> entries in the oc4j-connectors.xml file. Skeleton entries for <connector-factory> elements are created as well in oc4j-ra.xml. The deployer can edit these two files for further configuration.

Deploy applications that include embedded resource adapters in one of the following ways:

Deploying Using dcmctl

For information on using dcmctl, see the Oracle Application Server 10g Administrator's Guide.

Deploying Using admin.jar

For more information about admin.jar, see the Oracle Application Server Containers for J2EE Stand Alone User's Guide.

Locations of Relevant Files

Table 8-1 shows the paths to various deployment directories that OC4J creates during deployment that are referenced throughout the guide. The paths are relative to the root directory of your OC4J installation. The deployment directories can be customized within server.xml by setting the attributes shown in the table. These attributes belong to the <application-server> element.

Table 8-1 Directory Locations 
Attribute Description of Attribute Default Value

connectors_dir

connector-directory

The root directory for all standalone resource adapters.

connectors

applications_dir

applications-directory

The root directory for all applications.

applications

application_deployments_dir

deployment-directory

The root directory for all files generated at deployment.

application-deployments

Table 8-2 shows the paths to various files produced during deployment that are referenced throughout the guide. The paths are relative to the root directory of your OC4J installation. In Table 8-2, appname is the name under which the application is deployed.

Table 8-2 File Locations 
Standalone Resource Adapter Embedded Resource Adapter

Location of decompressed RAR archive

connectors_dir/deployment_name

applications_dir/appname/rar_name

oc4j-connectors.xml

config

or

as defined in the <connectors> tag in application.xml.

application_deployments_dir/appname/META-INF

or

as defined in the <connectors> tag in orion-application.xml.

oc4j-ra.xml

application_deployments_dir/default/deployment_name

application_deployments_dir/appname/rar_name

or

application_deployments_dir/appname/connector_name if an oc4j-connectors.xml file is included in the EAR and you have specified a connector element with a name attribute.

Specifying Quality of Service Contracts

You can configure connection pooling and authentication mechanisms on a per-connection basis at deployment time. This section describes the different ways to accomplish this.

Configuring Connection Pooling

Connection pooling is a J2EE 1.3 feature that allows a set of connections to be reused within an application. Because the J2EE Connector 1.0 specification is intended to be general rather than database-specific, the J2EE Connector connection-pooling interface differs significantly from the JDBC interface.

To set a connection pooling property in oc4j-ra.xml, specify a <property> element within the optional <connection-pooling> element. If you don't specify this element, whenever the application requests a connection, a new connection is created. Here is the syntax:

<property name="propname" value="propvalue" />.

The value for propname must be one of:

Here is an example of a <connection-pooling> element configuration: 

<connection-pooling>
    <description>my pooling configuration </description>
    <property name="waitTimeout" value="60" />
    <property name="scheme" value="fixed_wait" />
    <property name="maxConnections" value="3" />
    <property name="minConnections" value="1" />
</connection-pooling>

The example defines a connection pool with a minimum of one connection (OC4J tries to create one connection during start up) and a maximum of three connections. When all three connections are in use and a request for connection is issued, the pool with a fixed_wait scheme tries to wait a maximum of 60 seconds for a connection to be returned to the pool. If there is still no connection available after 60 seconds, an exception is thrown to the caller of the API that requested a new connection.

Managing EIS Sign-On

As part of extending the end-to-end security of the J2EE mode to cover integration to EISs, J2EE Connector architecture allows application components to associate a security context with connections established to the EIS.

Application components can either sign on to the EIS by themselves, or have OC4J manage the sign-on. Component-managed sign-on must be implemented programmatically, while container-managed sign-on can be specified either declaratively or programmatically. Specify the type of sign-on using the <res-auth> deployment descriptor element for EJB or Web components.

Note:

The remainder of this section assumes that you are familiar with chapter 7 of the J2EE Connector Architecture 1.0 specification. The specification uses the terms initiating principal, caller principal, and resource principal. As used in this section, the incoming security context refers to either initiating principal or caller principal, and the outgoing security context refers to resource principal.

Component-Managed Sign-On

When deploying applications that manage EIS sign-on by themselves, set <res-auth> to Application. The application component is responsible for providing explicit security information for the sign-on.

Figure 8-2 shows the steps involved in component-managed sign-on. The steps are detailed following the diagram.

Figure 8-2 Component-Managed Sign-On

Text description of o_1078.gif follows

Text description of the illustration o_1078.gif

  1. The client makes a request, which is associated with an incoming security context.

  2. As part of servicing the request, the application component maps the incoming security context to an outgoing security context and then uses the outgoing security context to request a connection to the EIS.

  3. As part of the connection acquisition, the resource adapter logs on to the EIS using the outgoing security context provided by the application component.

  4. Once the connection is acquired, the application component can interact with the EIS under the established outgoing security context.

The following example is an excerpt from an application that performs component-managed sign-on.

Example: 

Context initctx = new InitialContext();
// perform JNDI lookup to obtain a connection factory
javax.resource.cci.ConnectionFactory cxf =
        (javax.resource.cci.ConnectionFactory)initctx.lookup("java:com/env/eis/MyEIS");

// If component-managed sign-on is specified, the code 
// should instead provide explicit security
// information in the getConnection call

// We need to get a new ConnectionSpec implementation 
// instance for setting login attributes
com.myeis.ConnectionSpecImpl connSpec = ...
connSpec.setUserName("EISuser");
connSpec.setPassword("EISpassword");
javax.resource.cci.Connection cx = cxf.getConnection(connSpec);

Container-Managed Sign-On

When deploying applications that depend on the container for EIS sign-on, set <res-auth> to Container. The container is responsible for providing security information for the sign-on. Additionally, the container uses deployment descriptors or pluggable authentication classes to determine outgoing security context.

Figure 8-3 shows the steps involved in container-managed sign-on. The steps are detailed following the diagram.

Figure 8-3 Container-Managed Sign-On

Text description of o_1079.gif follows

Text description of the illustration o_1079.gif

  1. The client makes a request, which is associated with an incoming security context.

  2. As part of servicing the request, the application component requests a connection to the EIS.

  3. As part of the connection acquisition, the container (the OC4J security context manager shown in Figure 8-3) maps the incoming security context to outgoing security context, based on deployment descriptor elements (not shown in the figure) or authentication class provided.

  4. The resource adapter logs on to the EIS using the outgoing security context provided by the container.

  5. Once the connection is acquired, the application component can interact with the EIS under the established outgoing security context.

The following example is an excerpt from an application that depends on container-managed sign-on.

Example: 

Context initctx = new InitialContext();

// perform JNDI lookup to obtain a connection factory
javax.resource.cci.ConnectionFactory cxf =
        (javax.resource.cci.ConnectionFactory)initctx.lookup("java:com/env/eis/MyEIS");

// For container-managed sign-on, no security information is passed in the
// getConnection call
javax.resource.cci.Connection cx = cxf.getConnection();

Declarative Container-Managed Sign-On

You can create principal mappings in the oc4j-ra.xml file. To employ the principal mappings mechanism, use the <principal-mapping-entries> subelement under the <security-config> element.

Each <principal-mapping-entry> element contains a mapping from initiating principal to resource principal and password.

Use the <default-mapping> element to specify the user name and password for the default resource principal. This principal is used to log on to the EIS if there is no <principal-mapping-entry> element whose initiating user corresponds to the current initiating principal. If the element <principal-mapping-entries> is not specified, OC4J may not be able to log in to the EIS.

For example, if the OC4J principal scott should be logged in to the EIS as user name scott and password tiger, while all other OC4J users should be logged in to the EIS using user name guest with password guestpw, the <connector-factory> element in oc4j-ra.xml should look like this: 

<connector-factory name="..." location="...">
    ...
  <security-config>
    <principal-mapping-entries>
      <default-mapping>
        <res-user>guest</res-user>
        <res-password>guestpw</res-password>
      </default-mapping>
      <principal-mapping-entry>
        <initiating-user>scott</initiating-user>
        <res-user>scott</res-user>
        <res-password>tiger</res-password>
      </principal-mapping-entry>
    </principal-mapping-entries>
  </security-config>
    ...
</connector-factory>

Note:

The <res-password> element supports password indirection. For more information, refer to the Oracle Application Server Containers for J2EE Security Guide.

Programmatic Container-Managed Sign-On

OC4J supports the use of programmatic authentication--either through the use of an OC4J-specific mechanism or a standard mechanism like the Java Authentication and Authorization Service (JAAS). See the Sun JAAS specification for more information.

OC4J-Specific Authentication Classes

OC4J provides the oracle.j2ee.connector.PrincipalMapping interface for principal mapping. Its methods appear in Table 8-3.

To use OC4J-specific programmatic container-managed sign-on, an implementation of this interface must be provided.

Table 8-3 Method Description for oracle.j2ee.connector.PrincipalMapping Interface
Method Signature Description

public void init(java.util.Properties prop)

Called by OC4J to initialize the settings for the PrincipalMapping implementation class. OC4J passes the properties specified in the <config-property> elements in oc4j-ra.xml to this method. The implementation class can use the properties for setting default user name and password, LDAP connection information, or default mapping.

public void setManagedConnectionFactory (ManagedConnectionFactory mcf)

Used by OC4J to provide the implementation class with the ManagedConnectionFactory instance that is needed to create a PasswordCredential.

public void setAuthenticationMechanisms (java.util.Map authMechanisms)

Called by OC4J to pass the authentication mechanisms supported by the resource adapter to the PrincipalMapping implementation class. The key of the map passed is a string containing the supported mechanism type, such as BasicPassword or Kerbv5. The value is a string containing the corresponding credentials interface as declared in ra.xml, such as javax.resource.spi.security.PasswordCredential. The map can contain multiple elements if the resource adapter supports multiple authentication mechanisms.

public javax.security.auth.Subject mapping (javax.security.auth.Subject initiatingSubject)

Used by OC4J to allow the implementation class to perform the principal mapping. An application user subject is passed, and the implementation of this method should return a subject for use by the resource adapter to log in to the EIS resource per the JCA 1.0 specifications. The implementation may return null if the proper resource principal cannot be determined.

When a connection to the EIS is created, OC4J invokes the mapping method with the initiating user as the initiatingPrincipal. The mapping method must return a Subject containing the resource principal and credential. The Subject that is returned must adhere to either option A or option B in section 8.2.6 of the Connector Architecture 1.0 specification.

OC4J also provides the abstract class oracle.j2ee.connector.AbstractPrincipalMapping. This class furnishes a default implementation of the setManagedConnectionFactory() and setAuthenticationMechanism() methods, as well as utility methods to determine whether the resource adapter supports the BasicPassword or Kerberos version 5 (Kerbv5) authentication mechanisms, and a method for extracting the Principal from the application server user Subject. By extending the oracle.j2ee.connector.AbstractPrincipalMapping class, developers need only implement the init and mapping methods.

The methods exposed by the oracle.j2ee.connector.AbstractPrincipalMapping class appear in Table 8-4.

Table 8-4 Method Description for oracle.j2ee.connector.AbstractPrincipalMapping Class
Method Signature Description

public abstract void init (java.util.Properties prop)

This method must be implemented by the subclasses. See PrincipalMapping interface, described in Table 8-3, for details.

public void setManagedConnectionFactory (ManagedConnectionFactory mcf)

Stores the ManagedConnectionFactory instance that is passed in. Subclasses need not implement this method, and can make use of the getManagedConnectionFactory object saved by this method.

public void setAuthenticationMechanisms (java.util.Map authMechanisms)

Stores the map of authentication mechanisms. Subclasses need not implement this mechanism. Instead, they can make use of the isBasicPasswordSupported or isKerbv5Supported methods to determine which authentication mechanism is supported by the resource adapter. The method getAuthenticationMechanisms can be used to retrieve the authentication mechanisms as well.

public javax.security.auth.Subject mapping (javax.security.auth. Subject initiatingSubject)

Used by OC4J to allow the implementation class to perform the principal mapping. An application user subject is passed, and the implementation of this method should return a subject for use by the resource adapter to log in to the EIS resource per the J2EE Connector Architecture specifications. The implementation may return null if the proper resource principal cannot be determined.

public abstract javax.security.auth.Subject mapping (javax.security.auth. Subject initiatingSubject)

This method must be implemented by the subclasses. See PrincipalMapping interface, described in Table 8-3, for details.

public ManagedConnectionFactory getManagedConnectionFactory()

Utility method provided by this abstract class to return the ManagedConnectionFactory instance that might be required to create a PasswordCredentials object.

public java.util.Map getAuthenticationMechanisms()

Utility method to return the map of all authentication mechanisms supported by this resource adapter, as provided by OC4J. The key of the map returned is a string containing the supported mechanism type, such as BasicPassword or Kerbv5. The value is a string containing the corresponding credentials interface as declared in ra.xml, such as javax.resource.spi.security.PasswordCredential.

public boolean isBasicPasswordSupported()

Utility method to allow subclass to determine whether the BasicPassword authentication mechanism is supported by this resource adapter.

public boolean isKerbv5Supported()

Utility method to allow subclass to determine whether the Kerbv5 authentication mechanism is supported by this resource adapter.

public java.security.Principal getPrincipal (javax.security.auth. Subject subject)

Utility method provided to extract the Principal object from the given application server user subject passed from OC4J.
Extending AbstractPrincipalMapping

This simple example demonstrates how to extend the oracle.j2ee.connector.AbstractPrincipalMapping abstract class to provide a principal mapping that always maps the user to the default user and password. Specify the default user and password by using properties under the <principal-mapping-interface> element in oc4j-ra.xml.

The PrincipalMapping class is called MyMapping. It is defined as follows: 

package com.acme.app;

import java.util.*;
import javax.resource.spi.*;
import javax.resource.spi.security.*;
import oracle.j2ee.connector.AbstractPrincipalMapping;
import javax.security.auth.*;
import java.security.*;

public class MyMapping extends AbstractPrincipalMapping
{
  String m_defaultUser;
  String m_defaultPassword;

  public void init(Properties prop)
  {
    if (prop != null)
    {
      // Retrieves the default user and password from the properties
      m_defaultUser = prop.getProperty("user");
      m_defaultPassword = prop.getProperty("password");
    }
  }
  public Subject mapping(Subject initiatingSubject)
  {
    // This implementation only supports BasicPassword authentication
    // mechanism. Return if the resource adapter does not support it.
    if (!isBasicPasswordSupported())
      return null;
    // Use the utility method to retrieve the Principal from the
    // OC4J user. This code is included here only as an example.
    // The principal obtained is not being used in this method.
    Principal principal = getPrincipal(initiatingSubject);
    char[] resPasswordArray = null;    
    if (m_defaultPassword != null)
      resPasswordArray = m_defaultPassword.toCharArray();
    // Create a PasswordCredential using the default user name and
    // password, and add it to the Subject per option A in section
    // 8.2.6 in the Connector 1.0 spec.
    PasswordCredential cred =
      new PasswordCredential(m_defaultUser, resPasswordArray);
    cred.setManagedConnectionFactory(getManagedConnectionFactory());
    initiatingSubject.getPrivateCredentials().add(cred);
    return initiatingSubject;
  }
}

After you create your implementation class, copy a JAR file containing the class into the directory containing the decompressed RAR file. See Table 8-2 for the location of the RAR file. After copying the file, edit oc4j-ra.xml to contain a <principal-mapping-interface> element for the new class.

For example: 

<connector-factory name="..." location="...">
  ...
  <security-config>
    <principal-mapping-interface>
      <impl-class>com.acme.app.MyMapping</impl-class>
      <property name="user" value="scott" />
      <property name="password" value="tiger" />
    </principal-mapping-interface>
  </security-config>
  ...
</connector-factory>

JAAS Pluggable Authentication Classes

You can also manage sign-on to the EIS programmatically with JAAS. OC4J furnishes a JAAS pluggable authentication framework that conforms to Appendix C in the Connector Architecture 1.0 specification. With this framework, an application server and its underlying authentication services remain independent from each other, and new authentication services can be plugged in without requiring modifications to the application server.

Some examples of authentication modules are:

The JAAS login modules can be furnished by the customer, the EIS vendors, or the resource adapter vendors. Login modules must implement the javax.security.auth.spi.LoginModule interface, as documented in the Sun JAAS specification.

OC4J provides initiating user subjects to login modules by passing an instance of javax.security.auth.Subject containing any public certificates and an instance of an implementation of java.security.Principal representing the OC4J user. OC4J can pass a null Subject if there is no authenticated user (that is, an anonymous user). The initiating user subject is passed to the initialize method of the JAAS login module.

The JAAS login module's login method must, based on the initiating user, find the corresponding resource principal and create new PasswordCredential or GenericCredential instances for the resource principal. The resource principal and credential objects are then added to the initiating Subject in the commit method. The resource credential is passed to the createManagedConnection method in the javax.resource.spi.ManagedConnectionFactory implementation that is provided by the resource adapter.

If a null Subject is passed, the JAAS login module is responsible for creating a new javax.security.auth.Subject containing the resource principal and the appropriate credential.

JAAS and the <connector-factory> Element

Each <connector-factory> element in oc4j-ra.xml can specify a different JAAS login module. Specify a name for the connector factory configuration in the <jaas-module> element. Here is an example of a <connector-factory> element in oc4j-ra.xml that uses JAAS login modules for container-managed sign-on: 

  <connector-factory connector-name="myBlackbox" location="eis/myEIS1"> 
    <description>Connection to my EIS</description>
    <config-property name="connectionURL"
        value="jdbc:oracle:thin:@localhost:5521:orcl" />
    <security-config>
      <jaas-module>
        <jaas-application-name>JAASModuleDemo</jaas-application-name>
      </jaas-module>
    </security-config>
  </connector-factory>

In JAAS, you must specify which LoginModule to use for a particular application, and in what order to invoke the LoginModules. JAAS uses the value that are specified in the <jaas-application-name> element to look up LoginModules. See the Oracle Application Server Containers for J2EE Security Guide for more information.

Special Features Accessible Via Programmatic Interface

In addition to mapping from OC4J users to EIS users, login modules and OC4J-specific authentication classes can also map from OC4J groups to EIS users.

The the oracle.j2ee.connector package contains the InitiatingPrincipal class that represents OC4J users and the InitiatingGroup class that represents OC4J groups. OC4J creates instances of InitiatingPrincipal and incorporates them into the Subject that is passed to the initialize method of the login modules as well as to the mapping method of the OC4J-specific authentication class.

The the oracle.j2ee.connector package also contains the InitiatingPrincipal class that implements the java.security.Principal interface and adds the method getGroups(). The getGroups method returns a java.util.Set of oracle.j2ee.connector.InitiatingGroup objects, representing the OC4J groups or JAZN roles that this OC4J user belongs to. The group membership is defined in OC4J-specific descriptor files such as principals.xml or jazn-data.xml, depending on the user manager. The oracle.j2ee.connector.InitiatingGroup class implements but does not extend the functionality of the java.security.Principal interface.

Go to previous page Go to next page
Oracle
Copyright © 1996, 2003 Oracle Corporation.
All Rights Reserved.
Go To Documentation Library
Home		 Go To Product List
Solution Area		Go To Table of Contents
Contents		 Go To Index
Index