Sign-on process for HTTP clients

HTTP clients are clients that were generated with PTYPE=SOCKET and communicate using the HTTP protocol.

For an HTTP client to be able to log on to the UTM application, it must know the address of the transport system endpoint of the UTM application. With HTTP clients, the initiative to establish a connection always comes from the client, and an HTTP client sends an HTTP request to the transport system endpoint.

Once the connection has been successfully established, an HTTP client is logged on in two steps:

1. Implicit logon using a connection user ID
   A connection user ID is permanently assigned to the LTERM partner of an HTTP client and is generated explicitly or implicitly during UTM generation:
   • Explicitly by specifying USER= in the LTERM statement.
     Additional properties can be defined for a connection user ID defined in this way using the KDCDEF statement USER.
   • Implicitly by openUTM, if no USER was specified in the LTERM statement or if it is a LTERM pool (TPOOL statement). The LTERM name is then used as the name of the connection user ID; for a LTERM pool, the LTERM name is made up of the generated prefix and a sequential number, for example, HTTP0025. For LTERM pools, special key codes can be assigned to the connection user ID with TPOOL ...USER-KSET=. This allows you to restrict the access options of the connection user ID.
     
   If no login under a real user ID follows, the temporary login of the connection user ID becomes a final one. This is logged with a message.
   
2. Explicit logon using a real user ID (optional)
   In an HTTP request, an HTTP client can send authentication data to the UTM application in the Authorization header field. If this header is specified, the value must begin with "basic " and <userid>:<password> must be base64 encoded. Otherwise the request will be rejected with status code "400 invalid http header format".
   openUTM checks the passed authentication data. If the check fails, openUTM rejects the login with "401 user not authorized". Otherwise the user is logged on and can call the services of the application, see "Starting services from the HTTP client".

   The UTM application may also require the HTTP client to send authentication data. This can be configured either for all HTTP requests received via a transport system endpoint by setting the USER-AUTH parameter in the KDCDEF statement BCAMAPPL to *BASIC, or for the path specification of an HTTP request by setting the USER-AUTH parameter in the KDCDEF statement.