Overview

Universal Broker is designed to be a secure system. As the level of security rises, so does the administrative complexity of the system. Universal Broker has balanced the two to avoid the administrative complexity with a minimum sacrifice to security.

Universal Broker security concerns are:

Access to Universal Broker files, directories, and configuration options.
Account with which Universal Broker executes.
Privacy and integrity of transmitted network data.

File Permissions

At a minimum, only trusted user accounts should have write access to the Universal Broker installation data sets. This most likely means only the administrators should have write access. For maximum security, only trusted accounts should have read access to these data sets.

IBM i	At a minimum, limit non-trusted user accounts to object authority of use to the Universal Broker product library, UNVPRD510; the product temporary library, UNVTMP510; the command reference library, UNVCMDREF; the universal spool library, UNVSPL510; and all objects within these libraries. For maximum security, only trusted accounts (administrators and the UNVUBR510 profile) should have management, existence, alter, add, update, or delete authority to these objects. As a reminder, the system value QCRTAUT controls public access authority to created objects unless overridden by specific commands. User profiles that use Stonebranch products require CHANGE authority to the UNVTMP510* library.
HP NonStop	All files that the Broker creates or updates are located in either $SYSTEM.UNVLOG or $SYSTEM.UNVTRACE. The Broker does not need write access to its installation subvolume.
UNIX	All files that the Broker creates or updates are located in the /var/opt/universal directory. This means that the Broker does not need write access to its installation directory or subdirectories. Universal Broker requires full control (read, write, remove, and add) of the /var/opt/universal directory and its subdirectories. The Broker creates spool files, trace files, and log files in this directory. Only the account used to execute the Broker requires full access to this directory. The Broker configuration options can be changed to use directories other then /var/opt/universal. If this is the case, the same permissions must be set up for these specified directories.
Windows	Universal Broker requires write access to its primary install directory (that is, .\Universal\UBroker), which serves as its default trace file location. The Broker requires full control over the database directory (that is, .\Universal\spool), along with all subdirectories and files under that location. When the Broker executes as a console application with its message destination set to logfile, the Broker requires full control over the .\Universal\Broker\log directory and all .log files within it. The Universal Broker Windows service always writes its message to the Windows event log, which means that it requires no write access to a log directory or any other of its installation subdirectories and files.
z/OS	Universal Broker requires update access to its database files, which exist as HFS- or zFS-allocated datasets mounted on the z/OS Unix System Services (z/OS USS) file system. The Broker accesses HFS-allocated datasets using the UNVDB and UNVSPOOL ddnames in its STC JCL. The Broker accesses zFS-allocated datasets via its UNIX_DB_DATA_SET and UNIX_SPOOL_DATA_SET configuration options.

Configuration Files

Only trusted user accounts should have write, create or delete access to the Broker configuration files or any of the directories in the configuration file directory search list.

Windows

Although you can edit Universal Agent configuration files with any text editor (for example, Notepad), we recommend using the Universal Configuration Manager Control Panel application set configuration options.

The Universal Configuration Manager provides a graphical interface and context-sensitive help, and helps protect the integrity of the configuration file by validating all changes to configuration option values. It also directs the Broker to refresh its cache of Universal Agent component configuration settings, making it unnecessary to issue a separate configuration REFRESH request via the Universal Control utility.

Universal Access Control List

Universal Broker uses the Universal Access Control List (UACL) as an extra layer of security. The UACL contains entries (that is, rules) that permit or deny access to the Universal Broker (see Universal Access Control List (UACL) for details).

Universal Broker reads the UACL entries when the program is started. If the UACL file is changed, the new entries can be activated either by:

Stopping and starting Universal Broker.
Sending Universal Broker a Universal Control configuration refresh request, which instructs Universal Broker to reread all of its configuration files, including the UACL file (see Configuration Refresh).

Windows	Although you can edit the UACL file with any text editor (for example, Notepad), we recommend that you maintain UACL entries using the Universal Configuration Manager Control Panel application. The Universal Configuration Manager sends a configuration refresh request to the Universal Broker. Updated values take effect immediately, making it unnecessary to recycle the Broker to apply UACL changes.

Universal Broker User Account

Each Universal Agent component that the Universal Broker spawns inherits the Broker's account credentials. Occasionally, components must perform privileged operations, such as establishing a process execution environment using a local user account's credentials.

On some platforms, this means that the Broker must execute with an account whose inherited credentials allow the spawned components to perform these operations. On other platforms, the Broker may be executed with a lesser-privileged user, provided that the components are configured in way that permits them to elevate their privileges when necessary.

The section contains platform-specific requirements to consider when setting the Broker's user account.

IBM i	Universal Broker for IBM i runs with the UNVUBR510 user profile, which is created at product installation time. Any component started by Universal Broker inherits this user profile. By default, the UNVUBR510 user profile has ALLOBJ, JOBCTL, and SPLCTL authority. Unless the user profile is modified as described in the following section, ALLOBJ authority is required for a component to switch its user profiles based on the request it is servicing. JOBCTL authority is required for internal control and should not be removed. The UNVUBR510* user profile requires SPLCTL authority to provide Universal Submit Job job logs in specific, limited situations. Any other product or user should not use the UNVUBR510* user profile. By default, users cannot access the system with the UNVUBR510 profile. Removing ALLOBJ Authority from UNVUBR510 User Profile Given the extensive authority allowed by ALLOBJ special authority, it is desirable to avoid its use when possible. As of PTF 0UC0126 for V1R2M1, it is possible to remove ALLOBJ special authority from the UNVUBR510* user profile. However, by removing ALLOBJ from the UNVUBR510* user profile, the administrative complexity is increased. The following steps are required to use Universal Command with ALLOBJ special authority removed from the UNVUBR510* user profile. 1. If the following objects do not have USE Public Authority, the UNVUBR510* user profile must be given USE authority: QSYS/QSYGETPH QSYS/QWTSETP QSYS/QWCRJBST QSYS/QUSRMBRD This can be accomplished with the following command: ===> EDTOBJAUT OBJ(QSYS/object_name) OBJTYPE(PGM) From the resulting screen, use F6 to add user UNVUBR510 and give it USE authority. 2. UNVUBR510* user profile must be given USE authority to the user profile objects of all user profiles that will be using the universal command server on the IBM i. This can be accomplished with the following command: ===> EDTOBJAUT OBJ(QSYS/user_profile_name) OBJTYPE(USRPRF) From the resulting screen, use F6 to add user UNVUBR510 and give it USE authority. 3. Use the following command to remove the UNVUBR510* user profile ALLOBJ authority: ===> CHGUSRPRF USRPRF(UNVUBR510) SPCAUT(JOBCTL SPLCTL) Removing SPLCTL Authority from UNVUBR510 User Profile Use the following command to remove the UNVUBR510 user profile SPLCTL authority: ===> CHGUSRPRF USRPRF(UNVUBR510) SPCAUT(JOBCTL ALLOBJ) Removing ALLOBJ and SPLCTL Authorities from UNVUBR510 User Profile Use the following command to remove all special authority from the UNVUBR510* user profile: ===> CHGUSRPRF USRPRF(UNVUBR510) SPCAUT(*JOBCTL) (Please refer to the previous two sections for additional information.)
HP NonStop	Universal Broker itself does not require super.super privileges. For example, Universal Command (UCMD) Server may require super.super authority. Since the component inherits its user ID from the Broker, either the Broker must be running as super.super or the UCMD Server program must be owned by super.super and ProgID must be set for the server program file. If the Broker is started as a daemon at system startup time, it is started with a user ID of super.super. The Broker and all its components will then have sufficient authority.
UNIX	Although Universal Broker itself does not require superuser privileges, some Universal Agent server components (for example, UCMD Server and UEM Server) may require superuser authority to switch execution context to another user account, initialize group membership, or perform other privileged operations. Since the component inherits its user ID from Universal Broker, one of the following is required: Universal Broker must execute as root. root must own the Universal Agent Server application file (for example, ucmsrv or uemsrv), and the Universal Agent Server application file must have its "set user ID on execution" bit (setuid on exec) set (for example, chmod u+s ucmsrv). By default, the Universal Broker is owned and started with a user ID of ubroker. root will own the server components that need superuser authority and these components will have their "set user ID on execution" bit set. Note Universal Agent server components typically only invoke the privileged operations mentioned above when that component is configured to run with security enabled (that is, its security configuration option is set to a value other than none). When security is disabled in a Universal Agent server component's configuration, that component may not attempt to invoke any privileged operations, but relies completely upon the security context it inherits from the Broker.
Windows	The Universal Broker Windows service can be configured to execute with the Local System account or with a specially-configured Administrative account (see Windows Service).
z/OS	The Universal Broker started task may execute with any OMVS user ID provided that account has read access to the BPX.DAEMON, BPX.SUPERUSER, and BPX.JOBNAME resources in the FACILITY class. The Broker user account is typically configured at install time (see Started Task Configuration). Note Starting with Universal Broker 5.1.0.1, the Broker USER ID no longer requires READ access to the BPX.SUPERUSER resource. Starting with Universal Broker 6.5.0.0, the Broker USER ID no longer requires READ access to the BPX.DAEMON resource. See z/OS Configuration - Started Tasks for more information.

Browser not supported