12 Creating and Managing Oracle Wallet

Use Oracle wallet to store database credentials for WebLogic Server data source definition.

What Is Oracle Wallet

Oracle wallet provides an easy method to manage database credentials across multiple domains. It lets you update database credentials by updating the wallet instead of potentially changing many data source definitions. You accomplish updates by using a database connection string in the data source definition that is resolved by an entry in the wallet.

In addition, this feature can be made even easier by also using an Oracle TNS (Transparent Network Substrate) administrative file to hide the details of the database connection string (host name, port number, and service name) from the data source definition and instead use an alias. If the connection information changes, it is simply a matter of changing the tnsnames.ora file.

By using this approach, you remove the encrypted password from the data source descriptor so that it is portable across domains and the same wallet and tnsnames.ora file can be shared across multiple domains: that includes two different WebLogic Server domains or sharing credentials between WebLogic Server and the database. When used correctly, it makes having passwords in the data source configuration unnecessary.

Where to Keep Your Wallet

Oracle recommends that you create and manage the location of the wallet in a database environment. There, you'll have all the necessary commands and libraries, including the $ORACLE_HOME/oracle_common/bin/mkstore command. Often the storage of the wallet is managed by a database administrator and provided for use by the client. A configured wallet consists of two files, cwallet.sso and ewallet.p12, stored in a secure wallet directory.

Note:

Alternatively, you can install the Oracle Client Runtime package to provide the necessary commands and libraries to create and manage the wallet.

How to Create an External Password Store

Oracle wallet has an auto login feature that allows client access to the wallet contents without supplying a password. Use of this feature prevents exposing a clear text password on the client.

On the client, create a wallet by using the following syntax:

mkstore -wrl <wallet_location> -create

Where wallet_location is the path to the directory where you want to create and store the wallet.

This command creates a wallet with the auto login feature enabled at the location specified. Auto login lets the client access the wallet contents without supplying a password and prevents exposing a clear text password on the client.

The mkstore command prompts for a password that is used for subsequent commands. Passwords must have a minimum length of eight characters and contain alphabetic characters combined with numbers or special characters. For example:

mkstore -wrl /tmp/wallet –create 
Enter password: mysecret 
PKI-01002: Invalid password. 
Enter password: mysecret1  (not echoed) 
Enter password again: mysecret1 (not echoed)

Note:

Using a wallet moves the security vulnerability from a clear text password in the data source configuration file to an encrypted password in the wallet file. Make sure that the wallet file is stored in a secure location.

You can store multiple credentials for multiple databases in one client wallet. You cannot store multiple credentials (for logging in to multiple schemas) for the same database in the same wallet. If you have multiple login credentials for the same database, then they must be stored in separate wallets.

To add database login credentials to an existing client wallet, enter the following command:

mkstore -wrl <wallet_location> -createCredential <db_connect_string> <username> <password>

Where:

  • The wallet_location is the path to the directory where you created the wallet.

  • The db_connect_string must be identical to the connection string that you specify in the URL used in the data source definition (the part of the string that follows the @). It can be either the short form or the long form of the URL. For example:

    myhost:1521/myservice OR

    (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=myhost-scan)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=myservice)))

    Note:

    You should enclose this value in quotation marks to escape any special characters from the shell. Because this name is generally a long and complex value, an alternative is to use a TNS alias. See Use a TNS Alias instead of a DB Connect String.

  • The username and password are the database login credentials.

Repeat this procedure for each database you want to use in a WebLogic data source.

For more information about using auto login and maintaining wallet passwords, see the Oracle Database Advanced Security Administrator's Guide.

Define a WebLogic Server Data Source Using a Wallet

To configure a WebLogic Server data source to use an Oracle wallet, copy the wallet files to a secure directory on the client machine and update the data source configuration files.

Use the following procedures to configure a WebLogic Server data source to use a wallet.

Copy the Wallet Files

Copy the wallet files, cwallet.sso and ewallet.p12, from the database machine to the client machine and locate them in a secure directory.

Update the Data Source Configuration

Use the following steps to configure a WebLogic data source to use Oracle wallet:

  1. Do not enter a user or password in the WebLogic Remote Console when creating a data source or deleting them from an existing data source. If a user, password, or encrypted password appears in the configuration, it overrides the Oracle wallet values.
  2. Add the value oracle.net.wallet_location=wallet_directory to Connection Properties.

    Where wallet_directory is the secure directory location described in Copy the Wallet Files. An alternative method is use the -Doracle.net.wallet_location system property and add it to the JAVA_OPTIONS.

    NOTE: Oracle recommends using the connection property.

Use a TNS Alias Instead of a DB Connection String

Instead of specifying a matching database connection string in the URL and in the Oracle wallet, you can create an alias to map the URL information. The connection string information is stored in the tnsnames.ora file with an associated alias name. The alias name is then used both in the URL and the wallet.
Use the following steps to create a TNS alias:
  1. Specify oracle.net.tns_admin=tns_directory to Connection Properties, where tns_directory is the directory location of the tnsnames.ora file. Alternatively, if all the data sources in the server have the same value, use the -Doracle.net.tns_admin=<tns_directory> with the location of a tnsnames.ora file.
  2. Create or modify the tnsnames.ora file in the directory location specified by tns_directory. The entry has the form:

    alias=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=host)(PORT=port))(CONNECT_DATA=(SERVICE_NAME=service)))

    Where host is the URL of a database listener, port is the port of a database listener, and service is the service name of the database to which you want to connect.

    For additional attributes that you can configure, see Local Naming Parameters (tnsnames.ora) in the Database Net Services Reference. Oracle recommends that the string be entered on a single line.

  3. Use the alias in the data source definition URL by replacing the connection string with the alias. For example, change the URL attribute on the Connection Pool page in the Remote Console to jdbc:oracle:thin:@alias.

After the alias is created, it should not be necessary to modify the alias or the data source definition again. To change the user credential, update the wallet. To change the connection information, update the tnsnames.ora file. In either case, the data source must be redeployed. The simplest way to redeploy a data source is to untarget and target the data source in the WebLogic Remote Console. This configuration is supported for Oracle release 10.2 and later drivers.

Use DBClientData Modules for Portability

As of 14.1.2.0.0, you can use DBClientData modules, which enhance the integration of WLS on OCI and make it simple to connect to OCI Database services.

DBClientData modules provide a way to transfer the tnsnames.ora and Oracle wallet files, downloaded from OCI, to the machine or Kubernetes Pod where a WebLogic domain is running.

What Are DBClientData Modules

DBClientData modules are tnsnames.ora files, wallet files, keystore and truststore files, basically all the database client connection data used by a data source, collocated in a new type of deployment module.

DBClientData modules are standalone deployment modules that are independent of the configuration of the data source instances that are going to use those data. A single DBClientData module can be referenced by multiple data sources and a single DBClientData module can be used by multiple domains.

Why Use DBClientData Modules

DBClientData modules make it easy to manage and move database client data, including the tnsnames.ora file and Oracle wallet files, into the file system of all servers in a domain.

In maximum availability architecture (MAA) environments (which provide disaster recovery and high availability in multi data center architectures) and in migration scenarios, it is important to include these files with the domain so that the domain can move; there is no requirement to make configuration changes even when the databases are different.

Using WebLogic deployment tools, you can deploy, distribute, undeploy, and redeploy DBClientData modules. Updates to DBClientData module files on the WebLogic Server Administration Server will be propagated to all servers in the domain. DBClientData module files reside under the config directory of the domain home directory, which ensures that the database client data goes with the domain when you use pack and unpack operations to move the domain.

Manage DBClientData Modules

You can manage DBClientData modules using existing WebLogic deployment tools, such as weblogic.Deployer, WLST online, REST APIs, WebLogic Remote Console, as well as WebLogic Deploy Tooling (WDT). The source of DBClientData modules can be a ZIP file or an exploded archive directory that contains the tnsnames.ora and wallet files.

Note:

To manage DBClientData modules, a new option, dbClientdata, has been added to the existing deploy, redeploy, distribute, and undeploy APIs. If specified for DBClientData modules, the targets parameter is ignored because they are always deployed, redeployed, distributed, and undeployed to all servers in a domain.

See the following sections for detailed information and examples of each management task using WLST. For weblogic.Deployer examples, see Deploying Oracle Wallet Files for JDBC Modules in Deploying Applications to Oracle WebLogic Server.

Deploy DBClientData Modules

Deploying a DBClientData module performs the following actions.
  • Uploads or copies the DBClientData files (for example, tnsnames.ora and Oracle wallet files) into a directory under $DOMAIN_HOME/config/dbclientdata/<mydbclientdata> on the Administration Server.
    • The source can be a ZIP file or an exploded archive directory.
    • If the source is a ZIP file, then it will be exploded after it is uploaded or copied.
  • Generates a DBClientDataDirectoryMBean, which has its sourcePath attribute pointing to $DOMAIN_HOME/config/dbclientdata/<mydbclientdata>.
  • Optionally, propagates the files to the same directory on all Managed Servers.
    • If Managed Servers are running when the deployment operation is performed, then the propagation happens right away.
    • If Managed Servers are down when the deployment operation is performed, then the propagation happens when the servers start.

Syntax:

deploy(name,path,[options])

The following example uses WLST to upload and deploy a DBClientData module in the default location, $DOMAIN_HOME/config/dbclientdata. As a result, Users/joesmith/myWallet.zip will be deployed to the $DOMAIN_HOME/config/dbclientdata/myDBData directory.

Example:

deploy('myDBData', '/Users/joesmith/myWallet.zip', upload='true', dbClientData='true');

Use the -dbClientDataUploadPath option to upload and deploy a DBClientData module in a custom location relative to the domain configuration directory.

The following example commands will deploy /Users/joesmith/myWallet.zip to the $DOMAIN_HOME/config/myDBClientData/myDBData directory and $DOMAIN_HOME/config/myClientData/myDBClientData/myDBData directory, respectively.

deploy('myDBData', '/Users/joesmith/myWallet.zip', upload='true', dbClientDataUploadPath='myDBClientData', dbClientData='true');
deploy('myDBData', '/Users/joesmith/myWallet.zip', upload='true', dbClientDataUploadPath='myClientData/myDBClientData', dbClientData='true');
Distribute DBClientData Modules

If the DBClientData module files already exist in the Administration Server's dbClientDataDir, then you can use any one of the WLS deployment tools to distribute those files to all Managed Servers in the domain.
  • If Managed Servers are not running when the distribute operation is performed, then the propagation will happen when the servers start.
  • If the dbClientDataDir for a deployment is not empty on the Managed Servers, then the existing contents are fully replaced by the new contents when the distribute operation is performed.

Syntax:

distributeApplication(path,[options])

The following example uses WLST to propagate a DBClientData module to Managed Servers when the files are already available in the expected directory on the Administration Server.

Example:

distributeApplication('/mydomain/config/dbclientdata/demoDBCD/myWallet.zip', dbClientData='true');

The following example uses WLST to upload a DBClientData module to the Administration Server and propagate it to Managed Servers.

Example:

distributeApplication('/Users/joesmith/myWallet.zip', upload='true', dbClientData='true');

Note:

For a DBClientData module, thedistributeApplication WLST command derives the application name from the application path. In the two preceding examples, the derived application name is "demoDBCD" and "myWallet", respectively.
Redeploy DBClientData Modules

DBClientData modules are not versioned, therefore a redeploy operation is the same as an undeploy operation followed by a deploy operation. Upon redeploy, the content of the current dbClientDataDir on all servers is replaced by the content of the new DBClientData module source.

Syntax:

redeploy(name,[options])

The following example uses WLST to redeploy a DBClientData module.

Example:

redeploy('demoDBCD', dbClientData='true')

Use the -dbClientDataUploadPath option to upload and redeploy a DBClientData module in a custom location under the domain configuration directory.

redeploy('demoDBCD', upload='true', dbClientDataUploadPath='myDBClientData', dbClientData='true');

Configure a Data Source to Use DBClientData Modules

After you Deploy DBClientData Modules, configure a WebLogic Server data source to use DBClientData modules using the same steps as described in the following sections:

Note:

You need to point to the dbClientDataDir where the corresponding tnsnames.ora and wallet files are located.
  • The default file system location is$DOMAIN_HOME/config/dbclientdata/<dbclientDatamodulename>.
  • However, if the DBClientData module is included in a domain that was created or updated using WebLogic Deploy Tooling, then its default location will be different:
    • $DOMAIN_HOME/config/wlsdeploy/dbWallets/<dbclientmodulename>
    • NOTE: The WDT default location may change. For detailed information, see Archive File in the WebLogic Deploy Tooling documentation.
  • Remember that if any of the data in a DBClientData module or data source configuration has been changed, then a data source must be restarted for the updated data to be used.