HTTP-Clients sind Clients, die mit PTYPE=SOCKET generiert wurden, und über das HTTP-Protokoll kommunizieren.
Damit sich ein HTTP-Client an die UTM-Anwendung anmelden kann, muss er die Adresse des Transportsystem-Endpunkts der UTM-Anwendung kennen. Bei HTTP-Clients geht die Initiative zum Verbindungsaufbau immer vom Client aus, dabei sendet ein HTTP-Client einen HTTP-Request an den Transportsystem-Endpunkt.
Nach einem erfolgreichen Verbindungsaufbau wird ein HTTP-Client in zwei Schritten angemeldet:
Implizites Anmelden über eine Verbindungs-Benutzerkennung
Eine Verbindungs-Benutzerkennung ist dem LTERM-Partner eines HTTP-Clients fest zugeordnet und wird bei der UTM-Generierung explizit oder implizit erzeugt:
Explizit durch die Angabe bei USER= in der LTERM-Anweisung.
Für eine so definierte Verbindungs-Benutzerkennung können mit der KDCDEF-Anweisung USER weitere Eigenschaften festgelegt werden.Implizit durch openUTM, wenn in der LTERM-Anweisung kein USER angegeben wurde oder wenn es sich um einen LTERM-Pool handelt (TPOOL-Anweisung). Als Name der Verbindungs-Benutzerkennung wird dann der LTERM-Name genommen; bei einem LTERM-Pool setzt sich der LTERM-Name aus dem generierten Präfix und einer laufenden Nummer zusammen, z.B. HTTP0025. Für LTERM-Pools können der Verbindungs-Benutzerkennung mit TPOOL ...USER-KSET= spezielle Keycodes zugeordnet werden. Damit lassen sich die Zugriffsmöglichkeiten der Verbindungs-Benutzerkennung einschränken.
Folgt keine Anmeldung unter einer echten Benutzerkennung, wird die vorläufige Anmeldung der Verbindungs-Benutzerkennung zu einer endgültigen. Dies wird mit einer Meldung protokolliert.
Explizites Anmelden über eine echte Benutzerkennung (optional)
Ein HTTP-Client kann in einem HTTP-Request im Header-Feld Authorization Authentifizierungsdaten an die UTM-Anwendung senden. Ist dieser Header angegeben, dann muss der Wert mit “basic “ beginnen und <userid>:<password> muss base64 codiert sein. Andernfalls wird der Request mit Status-Code "400 invalid http header format“ zurückgewiesen.
openUTM prüft die übergebenen Authentifizierungsdaten. Schlägt die Prüfung fehl, dann lehnt openUTM die Anmeldung mit "401 user not authorized" ab. Ansonsten wird der Benutzer angemeldet und kann die Services der Anwendung aufrufen, siehe "Vorgänge vom HTTP-Client aus starten".
Die UTM-Anwendung kann auch verlangen, dass der HTTP-Client Authentifizierungsdaten sendet. Dies kann entweder für alle HTTP-Requests, die über einen Transportsystem-Endpunkt empfangen werden, konfiguriert werden, indem der Parameter USER-AUTH im KDCDEF-Statement BCAMAPPL auf den Wert *BASIC gesetzt oder für die Path-Angabe eines HTTP-Requests, indem der Parameter USER-AUTH im KDCDEF-Statement HTTP-DESCRIPTOR auf den Wert *BASIC gesetzt wird. In diesem Fall fordert openUTM die Authentifizierungsdaten vom Client an, wenn der Client keine Authentifizierungsdaten mitgesendet hat.