Trusted-ID-Evaluator

Ein Trusted-ID-Evaluator ist das Verfahren, das prüft, ob ein bestimmter ID-Name vertrauenswürdig ist.

Trusted-ID-Evaluator mit dem Programmiermodell JAX-RPC verwenden

Im Programmiermodell JAX-RPC stellt der Trusted-ID-Evaluator (com.ibm.wsspi.wssecurity.id.TrustedIDEvaluatorImpl) eine Abstraktion des Verfahrens dar, das prüft, ob eine angegebene ID vertrauenswürdig ist. Es gibt zwei Trustmodi, mit denen die Vertrauenswürdigkeit des übergeordneten Servers bei Verwendung von JAX-RPC geprüft werden kann:
Basisauthentifizierung (Benutzernamenstoken)
Der übergeordnete Server sendet ein Benutzernamenstoken mit einem Benutzernamen und einem Kennwort an einen Downstream-Server. Der Konsument oder Empfänger der Nachricht authentifiziert das Benutzernamenstoken und prüft die Vertrauenswürdigkeit auf der Basis der TrustedIDEvaluator-Implementierung. Die TrustedIDEvaluator-Implementierung muss die Java™-Schnittstelle "com.ibm.wsspi.wssecurity.id.TrustedIDEvaluator" implementieren.
Signatur
Der übergeordnete Server signiert die Nachricht, wobei es sich um einen beliebigen Nachrichtenabschnitt handeln kann, beispielsweise um den SOAP-Nachrichtenhauptteil. Der übergeordnete Server sendet das X.509-Token an einen Downstream-Server. Der Konsument oder Empfänger der Nachricht verifiziert die Signatur und prüft das X.509-Token. Die Identität oder der definierte Name aus dem X.509-Token, das in der digitalen Signatur verwendet wird, wird auf der Basis der TrustedIDEvaluator-Implementierung geprüft. Die TrustedIDEvaluator-Implementierung muss die Java-Schnittstelle "com.ibm.wsspi.wssecurity.id.TrustedIDEvaluator" implementieren. Für das X.509-Zertifikat verwendet WebSphere Application Server den definierten Namen (Distinguished Name) im Zertifikat als Identität des Anforderers.

Die folgende Abbildung demonstriert den gesicherten Prozess der Identitätszusicherung für beide Programmiermodelle:

Trustvalidierung bei der Identitätszusicherung für JAX-RPC

Trustvalidierung bei der Identitätszusicherung für JAX-WS

In dieser Abbildung ist Server s1 der übergeordnete Server und die Identitätszusicherung wird zwischen Server s1 und Server s2 festgelegt. Server s1 authentifiziert die Identität mit dem Namen bob. Server s1 möchte bob mit einem Kennwort an Server s2 senden. Der Trustmodus ist ein s1-Identitätsnachweis, der die Identität und ein Kennwort enthält. Server s2 empfängt die Anforderung, authentifiziert den Benutzer mithilfe eines JAAS-Anmeldemoduls (Java Authentication and Authorization Service) und ermittelt mit dem Trusted-ID-Evaluator, ob die Identität vertrauenswürdig ist. Ist die Identität vertrauenswürdig, ruft bob den Service auf. Ist eine Berechtigung erforderlich, ist bob die Identität, deren Berechtigung verifiziert wird.

Die Identität kann als RunAs-Identität (Aufruf) des aktuellen Sicherheitskontexts festgelegt werden. Beispielsweise authentifiziert das Web-Service-Gateway einen Anforderer mittels einer sicheren Methode, z. B. der Kennwortauthentifizierung, und sendet die Identität des Anforderers anschließend nur an einen Back-End-Server. Sie könnten die Identitätszusicherung auch für die Interoperabilität mit einer anderen Implementierung von Web Services Security verwenden.

Je nach Implementierung von JAX-RPC können Sie verschiedene Arten von Infrastrukturen verwenden, um eine Liste der vertrauenswürdigen IDs (Trusted IDs) zu speichern. Beispiele:
  • Textdatei
  • Datenbank
  • LDAP-Server (Lightweight Directory Access Protocol)

Der Trusted-ID-Evaluator wird in der Regel vom endgültigen Empfänger in einer Multi-Hop-Umgebung verwendet. Die Implementierung von Web Services Security ruft den Trusted-ID-Evaluator auf und übergibt die ID der Zwischenstation als Parameter. Wenn die ID geprüft ist und vertrauenswürdig erscheint, wird die Prozedur fortgesetzt. Andernfalls wird eine Ausnahme ausgelöst und die Prozedur wird gestoppt.

Trusted-ID-Evaluator mit dem Programmiermodell JAX-WS verwenden

Im Programmiermodell JAX-WS werden dieselben Konzepte für den Trusted-ID-Evaluator unterstützt, obwohl eine andere Implementierung verwendet wird. Verwenden Sie für die JAX-WS-Laufzeit die Administrationskonsole, um die Option Zusicherung der Identität verwenden in der Bindungsanzeige des Callers auszuwählen. Damit wird der Tokentyp für anerkannte Identität definiert, und anschließend wird eine Liste mit einer oder mehreren anerkannten Identitäten definiert. Der Trusted-ID-Evaluator validiert den Token für anerkannte Identität anhand einer Liste mit anerkannten Identitäten. Nähere Informationen zur Liste der anerkannten Identitäten finden Sie im Artikel über die Änderung der Reihenfolge der Caller für ein Token oder einen Nachrichtenabschnitt.

Für WebSphere Application Server Version 6.1 und höher werden die Elemente "Caller" und "TrustMethod" zur Unterstützung der Logik des Anforderers verwendet. Der Anforderer sendet eine Nachricht an einen Vermittler, und die Nachricht wird an den Service gesendet. Der Service führt auf der Basis der Sicherheitsinformationen eine Anmeldung für den Anforderer durch. Manchmal sind mehrere Sicherheitstoken vorhanden, sodass der Service entscheiden muss, welchen er verwendet. Wenn die Anforderer-ID als zugesicherte Identität angegeben ist, kann der Service festlegen, in welcher Weise die Vertrauenswürdigkeit des Vermittlers geprüft wird. Die folgenden Szenarien für Vermittler werden unterstützt:

<BasicAuth, null, null>
Der Benutzername und das Kennwort des Anforderers werden für die Authentifizierung verwendet. In diesem Fall wird die Authentifizierung mit den Eigenschaften des Anforderers ausgeführt, daher ist ein Kennwort für die Authentifizierung erforderlich.
<Signature, null, null>
Die Signatur des Anforderers wird für die Authentifizierung verwendet.
<IDAssertion, Username, null>
Der Benutzername (ohne Kennwort) wird zum Identifizieren des Anforderers verwendet. Das Benutzernamenstoken wird als Identitätszusicherung verwendet, daher ist kein Kennwort zum Benutzernamen erforderlich. In diesem Fall vertraut der Service dem Vermittler bedingungslos.
<IDAssertion, Username, Username>
Der Benutzername des Anforderers (ohne Kennwort) wird zum Identifizieren des Anforderers verwendet, und Benutzername und Kennwort des Vermittlers werden zum Authentifizieren des Vermittlers verwendet. Wird das Benutzernamenstoken verwendet, um eine anerkannte Identität herzustellen, muss immer ein Kennwort angegeben werden, da das Ziel des Tokens darin besteht, Vertrauen zwischen Vermittler und Service herzustellen.
<IDAssertion, Username, X509>
Der Benutzername des Anforderers (ohne Kennwort) wird zum Identifizieren des Anforderers verwendet, und die Signatur des Vermittlers wird zum Authentifizieren des Vermittlers verwendet. In diesem Fall muss die anerkannte Identität für die Signatur des Vermittlers mithilfe eines X.509-Zertifikats hergestellt werden.
<IDAssertion, X509, null>
Die Identität des Anforderers wird über ein X.509-Zertifikat festgelegt. In diesem Fall enthält das X.509-Zertifikat vom Anforderer keine Signatur, um den Besitz des Zertifikats zu bestätigen, daher vertraut der Service dem Vermittler bedingungslos.
<IDAssertion, X509, Username>
Der Identität des Anforderers wird mit einem X.509-Zertifikat festgelegt, und Benutzername und Kennwort des Vermittlers werden zum Authentifizieren des Vermittlers verwendet. Wird das Benutzernamenstoken verwendet, um eine anerkannte Identität herzustellen, muss immer ein Kennwort angegeben werden, da das Ziel des Tokens darin besteht, Vertrauen zwischen Vermittler und Service herzustellen.
<IDAssertion, X509, X509>
Der Identität des Anforderers wird mit einem X.509-Zertifikat festgelegt, und die Signatur des Vermittlers wird zum Authentifizieren des Vermittlers verwendet.

Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwbs_trustidevalv6
Dateiname:cwbs_trustidevalv6.html