12 Creating and Managing Oracle Wallet
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.
Parent topic: Creating and Managing Oracle Wallet
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.
Parent topic: Creating and Managing Oracle 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
andpassword
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.
Parent topic: Creating and Managing Oracle Wallet
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.
Parent topic: Creating and Managing Oracle 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.
Parent topic: Define a WebLogic Server Data Source Using a Wallet
Update the Data Source Configuration
Use the following steps to configure a WebLogic data source to use Oracle wallet:
Parent topic: Define a WebLogic Server Data Source Using a Wallet
Use a TNS Alias Instead of a DB Connection String
tnsnames.ora
file with an associated alias name. The alias name is then used both in the URL and the wallet.
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.
Parent topic: Creating and Managing Oracle Wallet
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
- Why Use DBClientData Modules
- Manage DBClientData Modules
- Configure a Data Source to Use DBClientData Modules
Parent topic: Creating and Managing Oracle Wallet
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.
Parent topic: Use DBClientData Modules for Portability
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.
Parent topic: Use DBClientData Modules for Portability
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.
Parent topic: Use DBClientData Modules for Portability
Deploy DBClientData Modules
- 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');
Parent topic: Manage DBClientData Modules
Distribute DBClientData Modules
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.
Parent topic: Manage DBClientData Modules
Redeploy DBClientData Modules
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');
Parent topic: Manage DBClientData Modules
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 thedbClientDataDir
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.
Parent topic: Use DBClientData Modules for Portability