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 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:
- The digital certificate of the sender
- The digital signature of the sender
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 exit 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(R) 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 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.