WebLogic Event Server Administration and Configuration Guide

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Configuring Security for WebLogic Event Server

This section contains information on the following subjects:

 


Overview of Security in WebLogic Event Server

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.

 


Configuring Security With the File-Based Provider

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.

Table 6-1 Available WebLogic Event Server Roles and Groups
Role
Description
Associated Group Name
Admin
WebLogic Event Server Administrator. Can perform all WebLogic Event Server tasks: start a server instance, deploy applications, and execute all commands of the wlevs.Admin utility.
By default, all domains and examples include an administrator called wlevs with password wlevs.
wlevsAdministrators
Monitor
Can perform only monitoring tasks, such as the read-only commands of the wlevs.Admin utility.
wlevsMonitors

Configuring File-Based Security: Main Steps

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:

To configure security:

  1. Open a command window and set your environment as described in Setting Up Your Development Environment.
  2. Add the 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:
  3. prompt> set PATH=d:\beahome\wlevs20\bin;%PATH%  (Windows)
    prompt> PATH=/beahome/wlevs20/bin:$PATH (UNIX)
  4. Change to the DOMAIN_DIR/config directory, where DOMAIN_DIR refers to the main directory of your domain, such as d:\beahome\user_projects\wlevs20_domain
  5. prompt> cd d:\beahome\user_projects\domains\wlevs20_domain
  6. Execute the secgen.cmd (Windows) or secgen.sh (UNIX) script to generate a unique key for your installation:
  7. prompt> secgen -k -o security-key.dat

    See The secgen Command Line Utility for additional information.

  8. Create a new security configuration file that uses the new key by executing the following secgen command:
  9. prompt> secgen -F -o security.xml

    See The secgen Command Line Utility for additional information.

  10. Execute the 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.
  11. 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.

  12. Using your favorite text editor, edit the file atnstore.txt following these guidelines:
    • For each new user you want to configure, add two lines at the beginning of the file. Start each line with the 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.

    • To assign a user to the Admin role, add a member: user entry below the group: wlevsAdministrators entry, where user refers to the username.
    • To assign a user to the Monitor role, add a 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
  13. Update the startwlevs.cmd (Windows) or startwlevs.sh (UNIX) start script by adding the following two arguments to the java command that starts WebLogic Event Server:
  14. -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.

  15. Restart WebLogic Event Server for the security to take effect. See Stopping and Starting the Server.

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.

Avoiding Cleartext Passwords in the startwlevs Script

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:

Being Prompted for a Password at Server Startup

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

Putting the Encrypted Password in a Security XML file

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.

  1. Open a command window and set your environment as described in Setting Up Your Development Environment.
  2. Change to the DOMAIN_DIR/config directory, where DOMAIN_DIR refers to the main directory of your domain, such as d:\beahome\user_projects\wlevs20_domain
  3. Using your favorite XML editor, edit the 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:
  4. <?xml version="1.0" encoding="UTF-8"?>
    <config>
    <css-realm>
    ...
    <msa-security>
    <boot-user-name-encrypted>jane</boot-user-name-encrypted>
    <password>secret</password>
    </msa-security>
    </config>
  5. Execute the following java command to encrypt the cleartext password in the security-config.xml file:
  6. 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>
    </msa-security>
    </config>

  7. Copy the file .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:
  8. prompt> copy d:\beahome\user_projects\wlevs20_domain\config\.msaInternal.dat d:\beahome\user_projects\wlevs20_domain

Disabling File-Based Security

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

 


The passgen Command Line Utility

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:

passgen Syntax

  prompt> passgen [-a algorithm] [-s saltsize] [-h] [-?] [password]*

where:

Option
Description
Default Value
-a
algorithm specifies the hash algorithm to use:
  • SHA-1
  • MD2
  • MD5
  • SSHA
  • SHA-256

Note: The actual list of algorithms that can be set depends on the security providers plugged into the JDK.

If not specified, the default is SHA-1.
-s
saltsize is the number of salt characters added to ensure a unique hash string.

If not specified, the default is 4.

-h, -?
Displays command line options and exits.
 
password

If passwords are specified on the command line they shall be hashed and printed out one per line in order from left to right. If no passwords are specified on the command line, then the tool shall prompt for passwords to hash interactively.

 

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.

Examples of Using passgen

The following sections provide examples that use the passgen utility:

Using passgen interactively

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.

Providing a Password on the Command Line

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:

 


The secgen Command Line Utility

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:

Generating a File-Based Provider Configuration File

Use the following command line options to generate a file-based security provider configuration file.

  prompt> secgen -F [-o outputfile] [-i inputkeyfile] [-e] [-P PropertyFilePath]

where:

Option
Description
Comments
-F
Generate a file-based security provider file; mutually exclusive with the -k option.
If not present, -k is assumed.
-o
outputfile is the name for the generated file.
Default output file name is security.xml.
-i
inputkeyfile is the fully qualified name of the input key file.
If not present, a default input key file named security-key.dat is expected.
-e
Enables unanimous adjudication during authorization.
 
-P
PropertyFilePath is the fully qualified path to a secgen property file which you can use to customize provider configurations.
A SecGenTemplate.properties template file is located at WLEVS_HOME/bin where WLEVS_HOME is the main installation directory of WebLogic Event Server, such as /beahome/wlevs20.

Generating a Key File

Use the following command line options to generate a security key file.

 prompt> secgen [-k] [-o outputfile] 

where:

Option
Description
Comments
-k
Generate a key file; mutually exclusive with the -F option.
If not present, -k is assumed.
-o
outputfile is the name for the generated file.
Default output file name is security-key.dat.

Using the secgen Properties File

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:

Examples of Using secgen

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

Limitations of secgen

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.


  Back to Top       Previous  Next