![]() ![]() ![]() ![]() ![]() ![]() |
This section contains information on the following subjects:
WebLogic Event Server security can be configured to use one of several types of security providers. As initially installed, it is configured to use the file-based providers for authentication and authorization, with an administrator user with username wlevs
and password wlevs
. You can add your own users to this configuration, or you can configure the system to authenticate users from an LDAP or DBMS provider. The file-based authorization provider gives you a pre-configured mapping of roles to permissions. You can use one of the other authorization providers to create your own mappings instead.
The type of file-based provider security you can enable for WebLogic Event Server is basic authentication. Authentication is a process whereby the identity of users is proved or verified. Authentication typically involves username/password combinations.
All WebLogic Event Server examples and domains are configured to have an administrator with username wlevs
and password wlevs
.
By default, security is disabled in the HelloWorld example and in the template user domain located in the BEA_HOME
/user_projects/domains/wlevs20_domain
directory. This means that any user can start the server, deploy applications, and run all commands of the administration tool (wlevs.Admin
) without providing a password.
Security is enabled in the FX and AlgoTrading examples. In both examples, the user wlevs
, with password wlevs
, is configured to be the WebLogic Event Server administrator with full administrator privileges. The scripts to start the server for these examples use the appropriate arguments to pass this username and password to the java
command. If you use the Deployer or wlevs.Admin
utility, you must also pass this username/password pair using the appropriate arguments.
The following table describes the available WebLogic Event Server security roles, as well as the name of the groups that are assigned to these roles.
The following procedure describes the steps to enable file-based provider security for your Weblogic Event Server domain. The procedure also shows how to add two users, one in the Admin role and the other in the Monitor role; this step is not required if the pre-configured wlevs
username (with password wlevs
) is adequate. For clarity, it is assumed that:
WLEVS_HOME
/bin
directory to your PATH
environment variable, where WLEVS_HOME
is the main WebLogic Event Server installation directory, such as d:\beahome\wlevs20
:prompt> set PATH=d:\beahome\wlevs20\bin;%PATH% (Windows)
prompt> PATH=/beahome/wlevs20/bin:$PATH (UNIX)
DOMAIN_DIR
/config
directory, where DOMAIN_DIR
refers to the main directory of your domain, such as d:\beahome\user_projects\wlevs20_domain
prompt> cd d:\beahome\user_projects\domains\wlevs20_domain
secgen.cmd
(Windows) or secgen.sh
(UNIX) script to generate a unique key for your installation:prompt> secgen -k -o security-key.dat
See The secgen Command Line Utility for additional information.
prompt> secgen -F -o security.xml
See The secgen Command Line Utility for additional information.
passgen.cmd
(Windows) or passgen.sh
(UNIX) script to generate encrypted passwords for the new users; pass as the single argument the cleartext password. Use the output of the script to copy and paste the encrypted password. prompt> passgen.cmd secret
{SHA-1}C19+kCHEcB1ZQ/ZjuiQxNsNbFGoQZYw=
prompt> passgen.cmd supersecret
{SHA-1}LoLDn/H1aC2qSoExZ+yNBnl1Tbqys/8=
See The passgen Command Line Utility for additional information.
atnstore.txt
following these guidelines:user:
and password:
keywords, then enter the value. Be sure you enter the encrypted password you generated in a preceding step.You must also add a blank line between each user entry, as shown in the example below.
member:
user
entry below the group: wlevsAdministrators
entry, where user
refers to the username.member:
user
entry below the group: wlevsMonitors
entry, where user
refers to the username.
The following sample atnstore.txt
file shows configurations for the wlevs
, jane
, and bob
users:
user: wlevs
password: {SHA-1}8MHYCQlzyh/S7TAbEC+fU34o4rf7GVM=
user: jane
password: {SHA-1}C19+kCHEcB1ZQ/ZjuiQxNsNbFGoQZYw=
user: bob
password: {SHA-1}LoLDn/H1aC2qSoExZ+yNBnl1Tbqys/8=
group: wlevsAdministrators
member: wlevs
member: jane
group: wlevsMonitors
member: bob
startwlevs.cmd
(Windows) or startwlevs.sh
(UNIX) start script by adding the following two arguments to the java
command that starts WebLogic Event Server:-Dcom.bea.core.security.username=username
-Dcom.bea.core.security.password=password
where username
and password
refer to the administrator user you have configured for WebLogic Event Server, wlevs
by default. The server start scripts are located in the main directory of your domain, such as BEA_HOME
/user_projects/domains/wlevs20_domain
.
The following snippet from the Windows startwlevs.cmd
script shows in bold how to specify the administrator username and password:
%JAVA_HOME%\bin\java -Dwlevs.home=%USER_INSTALL_DIR% -Dbea.home=%BEA_HOME% -Dcom.bea.core.security.username=jane -Dcom.bea.core.security.password=secret
-jar "..\..\..\bin\wlevs_2.0.jar" %1 %2 %3 %4 %5 %6
If you do not want to put cleartext passwords in the startwlevs.cmd
script, see Avoiding Cleartext Passwords in the startwlevs Script.
After you have enabled security, you must use the -username
and -password
arguments to the Deployer and wlevs.Admin tool to specify the administrator user.
The procedure in Configuring File-Based Security: Main Steps describes how to update the startwlevs
server start script with the cleartext password of the administrator user. Cleartext passwords, however, are typically not allowed in a production environment. There are two ways to not use cleartext passwords when starting the server:
If you want the server start script to prompt you for the administrator password, then update the script by adding the following argument to the java
command that starts WebLogic Event Server:
-Dcom.bea.core.security.prompt=true
In this case do not specify the com.bea.core.security.username
or com.bea.core.security.password
arguments in the script.
When the script prompts you for a password, the password field will not be echoed to the screen on platforms where this is supported.
The following snippet from the Windows startwlevs.cmd
script shows in bold how to specify that you be prompted for a password when starting the server:
%JAVA_HOME%\bin\java -Dwlevs.home=%USER_INSTALL_DIR% -Dbea.home=%BEA_HOME% -Dcom.bea.core.security.prompt=true
-jar "..\..\..\bin\wlevs_2.0.jar" %1 %2 %3 %4 %5 %6
Follow these steps if you want to put the encrypted administrator password in an XML file that will then be accessed by the server start script.
DOMAIN_DIR
/config
directory, where DOMAIN_DIR
refers to the main directory of your domain, such as d:\beahome\user_projects\wlevs20_domain
security-config.xml
file by adding an <msa-security>
child element to the <config>
root element. Use the two child elements of <msa-security>
shown below to specify the administrator’s username and cleartext password:<?xml version="1.0" encoding="UTF-8"?>
<config>
<css-realm>
...
<msa-security>
</config>
<boot-user-name-encrypted>jane</boot-user-name-encrypted>
<password>secret</password>
</msa-security>
java
command to encrypt the cleartext password in the security-config.xml
file:prompt> java -jar BEA_HOME
/modules/com.bea.core.bootbundle_3.0.1.0.jar . security-config.xml
where BEA_HOME
refers to the main BEA directory into which you installed WebLogic Event Server, such as d:\beahome
. The second argument refers to the directory that contains the security-config.xml
file; because this procedure directs you to change to the directory, the example shows "."
.
After you run the command, the security-config.xml
file will use encrypted passwords, such as the following:
<?xml version="1.0" encoding="UTF-8"?>
<config>
<css-realm>
...
<msa-security>
<boot-user-name-encrypted>{Salted-3DES}dBcBdaoemdY=</boot-user-name-encrypted>
<password>{Salted-3DES}X86x/+El2/s=</password>
</config>
</msa-security>
.msaInternal.dat
, generated by the java
command in the preceding step, from the directory in which you ran the java
command to the main domain directory. For example:prompt> copy d:\beahome\user_projects\wlevs20_domain\config\.msaInternal.dat d:\beahome\user_projects\wlevs20_domain
To disable file-based security in a domain, add the -disablesecurity
flag to the java
command that starts WebLogic Event Server in the startwlevs.cmd
(Windows) or startwlevs.sh
(UNIX) start script. This script is located in the main directory of your domain, such as BEA_HOME
/user_projects/domains/wlevs20_domain
.
The following snippet from the Windows startwlevs.cmd
script shows in bold how to disable security:
%JAVA_HOME%\bin\java -Dwlevs.home=%USER_INSTALL_DIR% -Dbea.home=%BEA_HOME% -jar "%USER_INSTALL_DIR%\bin\wlevs_2.0.jar" -disablesecurity
%1 %2 %3 %4 %5 %6
Use the passgen
command line utility to hash user passwords for addition to a security database.
The passgen
utility is located in the WLEVS_HOME
/bin
directory, where WLEVS_HOME
is the main WebLogic Event Server installation directory, such as d:\beahome\wlevs20
. The utility comes in two flavors:
prompt> passgen [-a
algorithm
] [-s
saltsize
] [-h] [-?] [password]*
Note: | Windows operating systems must use the .cmd version of this utility, Unix platforms should use the .sh version. |
Note: | The Unix version of this utility starts with the #!/bin/ksh directive. On most Unix systems, this forces the Korn Shell program to be used when using the utility. If the ksh program is not present in the bin directory or if the shell language used cannot properly execute the utility, run the utility as shown below: |
Note: | $ PATH_TO_KSH_BIN /ksh -c passgen.sh |
Note: | where PATH_TO_KSH_BIN is the fully qualified path to the ksh program. |
The following sections provide examples that use the passgen
utility:
The following is an example of using the passgen
utility interactively:
$ passgen
Password ("quit" to end): maltese
{SHA-1}LOtYvfQZj++4rV50AKpAvwMlQjqVd7ge
Password ("quit" to end): falcon
{SHA-1}u7NPQfgkHISr0tZUsmPrPmr3U1LKcAdP
Password ("quit" to end): quit
{SHA-1}2pPo4ViKsoNct3lTDoLeg9gHYZwQ47sV
In this mode, a password is entered and the resulting hashed version of the password is displayed. The hashed version of the password can then be entered into the password field of a security database.
Note: | In example, the passwords are shown to be echoed to the screen for demonstration purposes. In most situations, the password would not be displayed unless your platform does not support invisible passwords. |
The following is an example using the passgen
utility when providing the passwords to be hashed on the command line:
$ passgen maltese falcon
{SHA-1}g0PNXmJW0OBtp/GkHrhNAhpbjM+capNe
{SHA-1}2ivZnjnKD9fordC1YFkrVGf0DHL6SVP1
When multiple passwords are provided, they are hashed from left to right:
Use the secgen
command line utility generates a security key or a security configuration file that uses encrypted passwords.
The secgen
utility is located in the WLEVS_HOME
/bin
directory, where WLEVS_HOME
is the main WebLogic Event Server installation directory, such as d:\beahome\wlevs20
. The utility comes in two flavors:
Use the following command line options to generate a file-based security provider configuration file.
prompt> secgen -F [-ooutputfile
] [-iinputkeyfile
] [-e] [-PPropertyFilePath
]
PropertyFilePath is the fully qualified path to a secgen property file which you can use to customize provider configurations.
See Using the secgen Properties File for details.
|
Use the following command line options to generate a security key file.
prompt> secgen [-k] [-o outputfile
]
When running secgen, you can use the -P
option to specify a property file to customize provider configurations. A SecGenTemplate.properties
template file is located in WLEVS_HOME
/bin
where WLEVS_HOME
is the main installation directory of WebLogic Event Server, such as /beahome/wlevs20
.
You specify cleartext passwords the property file; however, these passwords will be stored encrypted in the generated configuration file.
The following example shows a property file used for file based provider customization:
#File based provider related
file.atn.file.store.path=myfileatnstore.txt
file.atn.file.store.password=firewall
file.atn.user.password.style=HASHED
file.atn.file.store.encrypted=true
file.atz.file.store.path=filatz
file.atz.file.store.password=firewall
file.rm.file.store.path=filerm
file.rm.file.store.password=firewall
file.cm.file.store.path=filecm
file.cm.file.store.password=firewall
The legal values for file.atn.user.password.style
are:
The following example shows how to use the secgen
utility to generate a key file with the name myKeyFile.dat
:
prompt> secgen -k -o myKeyFile.dat
The following example shows how to use the secgen
utility to generate a file-based security provider configuration file named myConfigFile.xml
which also uses the previously generated key file, myKeyFile.dat
, and a properties file named mySecGen.properties
:
prompt> secgen -F -i myKeyFile.dat -o myConfigFile.xml -P c:\msa\myMSAConfig\mySecGen.properties
Windows operating systems must use the .cmd
version of this utility, Unix platforms should use the .sh
version.
The Unix version of this utility starts with the #!/bin/ksh
directive. On most Unix systems, this forces the Korn Shell program to be used when using the utility. If the ksh
program is not present in the bin
directory or if the shell language used cannot properly execute the utility, run the utility as shown below:
prompt> $
PATH_TO_KSH_BIN
/ksh -c secgen.sh
where PATH_TO_KSH_BIN
is the fully qualified path to the ksh
program.
![]() ![]() ![]() |