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
- Create 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 we want, such as the encryption algorithm we 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
- Change, Copy, and Create Authentication Information Object
- Delete Authentication Information Object
- Inquire Authentication Information Object
Parent topic: Set up security on IBM i