Connector Security

The security information used by the connector to connect to the database or EIS system can be provided in three ways:

  1. By the Container, using information in the deployment of the Connector
  2. By the Container, using a separate Security Domain
  3. By the Application

Specifying Container Authentication in the Connector

This the simplest configuration mechanism and is commonly used where all applications use the same set of credentials to authenticate to the back-end system. One disadvantage though is that the credentials are stored in plain text in the Connector configuration file; care should be take to secure access to this file.

To authenticate in this manner, the and elements should be provided in the configuration. For example, the following configuration connects to an Oracle database as user "scott" with password "tiger":



MyOracleDS
jdbc:oracle:thin:@host:1521:sid
oracle.jdbc.driver.OracleDriver
scott
tiger

Specifying Container Authentication using a Security Domain

Using a Security Domain removes the authentication mechanism from the Connector definition and places it under the control of the Container's security system. This allows different mechanisms to be used in production and development configurations, and moves credentials from the Connector configuration files to a central security store.

Which Security Domain to use is defined using a element in the connector configuration. For example, the following configuration connects to an Oracle database using credentials supplied by the OracleRealm domain:



MyOracleDS
jdbc:oracle:thin:@host:1521:sid
oracle.jdbc.driver.OracleDriver
OracleRealm

The Security Domain must be able to generate credentials that are compatible with the JCA specification. This primarily involves including a reference to the JCA ManagedConnectionFactory in the PasswordCredential used. Two domains are included in the standard distribution that provide this functionality:

  • The ConfiguredIdentityLoginModule returns the same identity and credentials every time and can be used where all applications connect to this resource with the same identity.
  • The CallerIdentityLoginModule returns the identity of the current caller and can be used for applications that wish to pass this through to the resource.

These are configured in /conf/login-config.xml

Authenticating with Container Supplied Identity

Using the ConfiguredIdentityLoginModule, all applications and application users connect to a back-end resource using a common identity. This is often used where system level authorization is not needed within the database and where all users share a common database account; this avoids the need to create database level accounts for application users.

An example of such a configuration which connects the datasource defined above with username "scott" and password "tiger" would be:



flag="required">
scott
scott
tiger

jboss.jca:service=LocalTxCM,name=MyOracleDS



Authenticating with Current Caller's Identity

Using the CallerIdentityLoginModule, the identity of the current user can be passed through to the back-end system. This is often used where system level authorization is needed within the database and where all users have database accounts.

An example of such a configuration which connects the datasource defined above would be:



CallerIdentityLoginModule"
flag="required">

jboss.jca:service=LocalTxCM,name=MyOracleDS



Specifying Container Authentication in the Application

Some applications need to supply the credentials used to connect to the resource themselves rather than relying on values configured into the container. This can be specified using an in the connector configuration.

For example, the following configuration allows the application to supply the authentication information used to connect to an Oracle database:



MyOracleDS
jdbc:oracle:thin:@host:1521:sid
oracle.jdbc.driver.OracleDriver


The application must specify the credentials every time it requests a connection by using the getConnection(String, String) method.

Although this is flexible, it requires that the application have knowledge of the security mechanism used by the connector. An alternative approach which may offer greater portability is to allow the container to authenticate using the current caller's identity.