Object Authority Manager guidelines on IBM i

Additional hints and tips for using the object authority manager (OAM)


Limit access to sensitive operations

Some operations are sensitive; limit them to privileged users. For example,

  • Accessing some special queues, such as transmission queues or the command queue SYSTEM.ADMIN.COMMAND.QUEUE
  • Running programs that use full MQI context options
  • Creating and copying application queues


Queue manager directories

The directories and libraries containing queues and other queue manager data are private to the product. Do not use standard operating system commands to grant or revoke authorizations to MQI resources.


Queues

The authority to a dynamic queue is based on, but is not necessarily the same as, that of the model queue from which it is derived.

For alias queues and remote queues, the authorization is that of the object itself, not the queue to which the alias or remote queue resolves. It is possible to authorize a user profile to access an alias queue that resolves to a local queue to which the user profile has no access permissions.

Limit the authority to create queues to privileged users. If we do not, users can bypass the normal access control by creating an alias.


Alternate-user authority

Alternate-user authority controls whether one user profile can use the authority of another user profile when accessing an IBM MQ object. This technique is essential where a server receives requests from a program and the server wants to ensure that the program has the required authority for the request. The server might have the required authority, but it needs to know whether the program has the authority for the actions it has requested.

For example:

  • A server program running under user profile PAYSERV retrieves a request message from a queue that was put on the queue by user profile USER1.
  • When the server program gets the request message, it processes the request and puts the reply back into the reply-to queue specified with the request message.
  • Instead of using its own user profile (PAYSERV) to authorize opening the reply-to queue, the server can specify some other user profile, in this case, USER1. In this example, we can use alternate-user authority to control whether PAYSERV is allowed to specify USER1 as an alternate-user profile when it opens the reply-to queue.

The alternate-user profile is specified on the AlternateUserId field of the object descriptor.

Note: We can use alternate-user profiles on any IBM MQ object. Use of an alternate-user profile does not affect the user profile used by any other resource managers.


Context authority

Context is information that applies to a particular message and is contained in the message descriptor, MQMD, which is part of the message.

For descriptions of the message descriptor fields relating to context, see MQMD overview.

For information about the context options, see Message context.


Remote security considerations

For remote security, consider:

    Put authority
    For security across queue managers, we can specify the put authority that is used when a channel receives a message sent from another queue manager. This parameter is valid only for RCVR, RQSTR, or CLUSRCVR channel types. Specify the channel attribute PUTAUT as follows:

      DEF
      Default user profile. This is the QMQM user profile under which the message channel agent is running.

      CTX
      The user profile in the message context.

    Transmission queues
    Queue managers automatically put remote messages on a transmission queue; no special authority is required. However, putting a message directly on a transmission queue requires special authorization.

    Channel exits
    Channel exits can be used for added security.

    Channel authentication records
    Use to exercise more precise control over the access granted to connecting systems at a channel level.

For more information about remote security, see Channel authorization.


Protecting channels with SSL/TLS

The Transport Layer Security (TLS) protocol provide channel security, with protection against eavesdropping, tampering, and impersonation. IBM MQ support for TLS enables you to specify, on the channel definition, that a particular channel uses TLS security. We can also specify details of the security you want, such as the encryption algorithm you want to use.

TLS support in IBM MQ uses the queue manager authentication information object and various CL and MQSC commands and queue manager and channel parameters that define the TLS support required in detail.

The following CL commands support TLS:

    WRKMQMAUTI
    Work with the attributes of an authentication information object.

    CHGMQMAUTI
    Modify the attributes of an authentication information object.

    CRTMQMAUTI
    Create an authentication information object.

    CPYMQMAUTI
    Create an authentication information object by copying an existing one.

    DLTMQMAUTI
    Delete an authentication information object.

    DSPMQMAUTI
    Displays the attributes for a specific authentication information object.

For an overview of channel security using TLS, see

For details of PCF commands associated with TLS, see