In dieser Konfiguration authentifiziert der Lastausgleicher die Endbenutzer durch Bestätigung des Clientzertifikats. Das Clientzertifikat muss jedoch weiterhin an alle anderen MSS-Systeme gesendet werden, um den eingehenden Benutzer zu identifizieren.
Wenn der Lastausgleicher zum Beenden der TLS-Verbindung konfiguriert ist, kann das Zertifikat des Benutzers zu einem HTTP-Header hinzugefügt, vom Sitzungsserver extrahiert und dann zur Autorisierung an MSS weitergeleitet werden. Um das Zertifikat in einen Header zu übertragen, legen Sie zuerst in der container.properties-Datei des Host Access for the Cloud-Sitzungsservers den Headernamen fest:
So übertragen Sie das Zertifikat an einen Header:
Legen Sie den Headernamen in der Datei container.properties des Host Access for the Cloud-Sitzungsservers fest:
x509.header.client.cert=X-SSL-Client-Cert
Legen Sie den Headerwert auf das Benutzerzertifikat in der Lastausgleicherkonfiguration fest. Beispiel mit Verwendung einer BIG-IP-iRule:
HTTP::header insert X-SSL-Client-Cert [URI::encode $client_cert]
Dies setzt voraus, dass $client_cert auf das Benutzerzertifikat im PEM-Format festgelegt wurde. Wenn das Benutzerzertifikat im DER-Format vorliegt, verwenden Sie die Base64-Kodierung:
HTTP::header insert X-SSL-Client-Cert [b64encode $client_cert]
Durch das Kodieren des Zertifikats wird gewährleistet, dass der Headerwert eine Zeile ASCII-Text darstellt. Dies ist erforderlich, damit der Host Access for the Cloud-Sitzungsserver den Wert lesen kann.
HINWEIS:Die Authentifizierung mit dem Clientzertifikat muss weiterhin zwischen dem Lastausgleicher und dem Sitzungsserver stattfinden. Der Lastausgleicher muss so konfiguriert sein, dass er sein Zertifikat an den Sitzungsserver sendet, und die Zertifizierungsstelle des Lastausgleichers muss im Truststore des Sitzungsservers vorhanden sein.
Nachdem Sie den Lastausgleicher zum Senden des Zertifikats an den Host Access for the Cloud-Sitzungsserver konfiguriert haben und das Hinzufügen des Benutzerzertifikats zum Header konfiguriert haben, starten Sie den Sitzungsserver neu.
Bei der Verbindung mit einem Zertifikat oder einer Smartcard über den Lastausgleicher wird der vom Zertifikat dargestellte Benutzer erfolgreich authentifiziert und autorisiert. Um den Vorgang zu überprüfen, legen Sie den Protokollierumfang des Sitzungsservers auf „DEBUG“ (Fehlersuche) fest und untersuchen Sie die Datei sessionserver.log auf Einträge der folgenden Art:
Attempting to extract certificate from X-SSL-Client-Cert header. User <DN-Wert> has been preauthenticated from <IP-Adresse> (Es wird versucht, das Zertifikat vom X-SSL-Client-Cert-Header abzurufen. Der Benutzer <DN-Wert> wurde von <IP-Adresse> vorauthentifiziert.)
Standardmäßig enthält der Truststore des Host Access for the Cloud-Sitzungsservers die Java-ZS-Zertifikate. Deshalb akzeptiert der Host Access for the Cloud-Sitzungsserver jedes Clientzertifikat, das von einer bekannten Zertifizierungsstelle signiert ist. Um sicherzustellen, dass nur die gewünschten Lastausgleicher eine Verbindung zum Sitzungsserver herstellen können, müssen Sie die Java-ZS-Zertifikate aus dem Truststore entfernen und sicherstellen, dass nur die erforderlichen Zertifikate im Truststore installiert sind.
Um die zulässigen Clientzertifikate nach Aussteller-DN zu filtern, legen Sie in der Datei container.properties des Host Access for the Cloud-Sitzungsservers die folgenden Eigenschaften fest:
X509.client.cert.issuer=<DN-Wert> X509.client.cert.subject=<Subject-DN-Wert> X509.client.cert.serial=<Seriennummer> X509.client.cert.sha1=<SHA1-Fingerabdruck> X509.client.cert.sha256=<SHA256-Fingerabdruck>
Die DN-Werte müssen genau mit dem Lastausgleich-Zertifikataussteller bzw. Subject-DN übereinstimmen. Die Seriennummer muss einen Dezimalwert (Zehnersystem) annehmen. Die Werte für den SHA1- und den SHA256-Fingerabdruck müssen im Hexadezimalformat eingegeben werden. Wenn beliebige dieser Attribute festgelegt sind, wird überprüft, ob die Attribute des eingehenden Zertifikats mit den angegebenen Eigenschaftenwerten übereinstimmen. Wenn beliebige Werte nicht übereinstimmen, erfolgt keine Autorisierung.