The role of the API exit and the API-crossing exit in security

 

Overview

There are many possible uses of API exits. For example, you can use them to log messages, monitor the use of queues, log failures in MQI calls, maintain audit trails for accounting purposes, or collect statistics for planning purposes.

API exits can also provide the security services described in the following sections.

 

Identification and authentication

At the level of an individual message, identification and authentication is a service that involves two users, the sender and the receiver of the message. The basic requirement is for the user of the application that receives the message to be able to identify and authenticate the user of the application that sent the message. Note that the requirement is for one way, not two way, authentication.

Depending on how it is implemented, the users and their applications might need to interface, or even interact, with the service. In addition, when and how the service is used might depend on where the users and their applications are located, and on the nature of the applications themselves. It is therefore natural to consider implementing the service at the application level rather than at the link level.

If you consider implementing this service at the link level, you might need to resolve issues such as the following:

  • On a message channel, how do you apply the service only to those messages that require it?

  • How do you enable users and their applications to interface, or interact, with the service, if this is a requirement?

  • In a multi-hop situation, where a message is sent over more than one message channel on the way to its destination, where do you invoke the components of the service?

Here are some examples of how the identification and authorization service can be implemented at the application level:

  • When an application puts a message on a queue, an API exit can acquire an authentication token from a trusted authentication server such as DCE or Kerberos. The API exit can add this token to the application data in the message. When the message is retrieved by the receiving application, a second API exit can ask the authentication server to authenticate the sender by checking the token.

  • When an application puts a message on a queue, an API exit can append the following items to the application data in the message:

    If different algorithms for generating a message digest are available for use, the API exit can include the name of the algorithm it has used.

    When the message is retrieved by the receiving application, a second API exit can perform the following checks:

    • The API exit can validate the digital certificate by working through the certificate chain to the root CA certificate. To do this, the API must have access to a key repository that contains the remaining certificates in the certificate chain. This check provide assurance that the sender, identified by the Distinguished Name, is the genuine owner of the public key contained in the certificate.

    • The API exit can check the digital signature using the public key contained in the certificate. This check authenticates the sender.

    The Distinguished Name of the sender can be sent instead of the whole digital certificate. In this case, the key repository must contain the sender's certificate so that the second API exit can find the public key of the sender. Another possibility is to send all the certificates in the certificate chain.

    Tivoli Access Manager for Business Integration uses Public Key Infrastructure (PKI) techniques similar to the ones just described. For more information about how Access Manager for Business Integration implements this and other application level security services, see Chapter 9, Access Manager for Business Integration.

  • When an application puts a message on a queue, the UserIdentifier field in the message descriptor contains a user ID associated with the application. The user ID can be used to identify the sender. To enable authentication, an API exit can append some data, such as an encrypted password, to the application data in the message. When the message is retrieved by the receiving application, a second API exit can authenticate the user ID by using the data that has travelled with the message.

    This technique might be considered sufficient for messages that originate in a controlled and trusted environment, and in circumstances where a trusted authentication server or PKI support is not available.

 

Access control

An API exit can provide access controls to supplement those provided by WebSphere MQ. In particular, an API exit can provide access control at the message level. An API exit can ensure that an application puts on a queue, or gets from a queue, only those messages that satisfy certain criteria.

Consider the following examples:

  • A message contains information about an order. When an application attempts to put a message on a queue, an API exit can check that the total value of the order is less that some prescribed limit.

  • Messages arrive on a destination queue from remote queue managers. When an application attempts to get a message from the queue, an API exit can check that the sender of the message is authorized to send a message to the queue.

 

Confidentiality

The application data in a message can be encrypted by an API exit when the message is put by the sending application and decrypted by a second API exit when the message is retrieved by the receiving application.

For performance reasons, a symmetric key algorithm is normally used for this purpose. However, at the application level, where many users might be sending messages to each other, the problem is how to ensure that only the intended receiver of a message is able to decrypt the message. One solution is to use a different symmetric key for each pair of users that send messages to each other. But this solution might be difficult and time consuming to administer, particularly if the users belong to different organizations. A standard way of solving this problem is known as digital enveloping and uses PKI technology.

When an application puts a message on a queue, an API exit generates a random symmetric key and uses the key to encrypt the application data in the message. The API exit encrypts the symmetric key with the public key of the intended receiver. It then replaces the application data in the message with the encrypted application data and the encrypted symmetric key. In this way, only the intended receiver can decrypt the symmetric key and therefore the application data. If an encrypted message has more than one possible intended receiver, the API exit can encrypt a copy of the symmetric key for each intended receiver.

If different algorithms for encrypting and decrypting the application data are available for use, the API exit can include the name of the algorithm it has used.

 

Data integrity

A message can be digitally signed by an API exit when the message is put by the sending application. The digital signature can then be checked by a second API exit when the message is retrieved by the receiving application. This can detect whether the message has been deliberately modified.

As discussed in Data integrity, some protection can be provided by using a message digest instead of a digital signature.

 

Non-repudiation

Consider an API exit that checks the digital signature of each message that is retrieved from a queue by the receiving application. If the API exit logs sufficient evidence to enable the digital signature to be checked at any time in the future, this can form the basis of a non-repudiation service with proof of origin.

The evidence that is logged might include:

The API exit can also prepare a delivery report on behalf of the receiver of the message and send it to the reply-to queue specified in the message descriptor of the message. The delivery report might include :

  • The date and time of delivery of the message
  • The digital certificate of the receiver
  • The digital signature of the receiver
  • The original message, a subset of the original message, or some means of identifying the original message

When the delivery report is retrieved from the reply-to queue, another API exit can check the digital signature to authenticate the receiver of the original message. If the API exit also logs sufficient evidence to enable the digital signature to be checked at any time in the future, this can form the basis of a non-repudiation service with proof of delivery.

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.

 

Tivoli is a trademark of the IBM Corporation in the United States, other countries, or both.