Wire listener authentication

The wire listener supports an authenticated mode. It uses an MD5-hash mechanism to authenticate those users. Roles and trusted context can be used to also manage authorizations.

The wire listener is started in one of the following two modes
Mode Description
Unauthenticated mode In unauthenticated mode, the wire listener is started without a registry file or with authentication turned off by use of a command parameter. Users have access to JSON documents in the Db2® database with the authorization of a Db2 database proxy user. Use unauthenticated mode in very limited scenarios.
Authenticated mode In authenticated mode, the wire listener is started with a registry file and authentication that is turned on, which is the default for starting with a registry file. This mode allows the use of user roles and context definitions that are registered for the listener.
The wire listener registry file is stored on the wire listener host and contains a list of authorized application users with tokens that are used to verify authentication, and optional role and context information. It is maintained by the JSON user administrator by using a registration function. Access to the registry file is controlled by operating system security.

If trusted context is enabled and no context user is specified either directly or indirectly, the registered application userid must be a valid Db2 database user. Otherwise, any userid can be registered by the user administrator.

A user ID can be registered on listener instance level, which is the associated authorization then applies to all dbs (schemas) in the Db2 database. A user ID can also be registered on the db (schema) level and can be associated with different roles or context for different schemas.

Process flow:
  1. The wire listener is started by providing the registry file together with the connection information of a valid Db2 database user. This user serves as a proxy user for all subsequent database operations.
  2. The client application establishes a session by connecting to the wire listener with the host and port information of the listener. If the listener requires authentication, the client application uses the MD5-token exchange mechanism to establish an authenticated session for the application user.
  3. After a successful authentication, the user submits requests to the wire listener. If the registry file contains a role association for the user, these requests are validated against the assigned roles. If the request is accepted, it is submitted for processing to the Db2 database server.
  4. To run the request, a connection is established to the Db2 database by the wire listener proxy user. If no context user is specified, the authorization of the proxy user is used to process the request. The proxy user must have the appropriate authorizations on the Db2 database for all the incoming requests.
  5. If the registry file contains a context user association for the application user, the proxy user establishes the connection. Then, the proxy user sets trusted context for the user ID with the context information. In this case, the authorization of the context is applied to run the request in the Db2 database.
Malicious users can snoop message exchanges between application and wire listener, appropriate measures must be taken to prevent access.