Ein SAML-Bearer-Token ist ein SAML-Token, das die Konfigurationsmethode für Bearer-Subjekte
verwendet.
In einer Bestätigungsmethode für Bearer-Subjekte ist kein SOAP-Nachrichtenabsender erforderlich, um
eine Korrespondenz herzustellen, die ein SAML-Token mit dem Inhalt der übergeordneten SOAP-Nachricht bindet.
Sie können
Client- und Providerrichtliniensatzzuordnungen und -bindungen für das SAML-Bearer-Token konfigurieren.
Vorbereitende Schritte
WebSphere Application Server mit
SAML stellt eine Vielzahl von Anwendungsrichtliniensätzen für
SAML-Standardtoken bereit sowie mehrere allgemeine Beispiele für Client- und Providerbindungen.
Bevor Sie Client- und Providerbindungen für das SAML-Bearer-Token
erstellen können, müssen Sie folgende Schritte ausführen:
- Ein oder mehrere neue Serverprofile mit SAML-Konfigurationseinstellungen erstellen oder einem vorhandenen Profil
SAML-Konfigurationseinstellungen hinzufügen.
Angaben darüber, wie Sie einem Profil SAML-Konfigurationseinstellungen
hinzufügen finden Sie in den
Informationen zum Festlegen der SAML-Konfiguration.
- Einen oder mehrere der folgenden Standardrichtliniensätze importieren:
- SAML20 Bearer WSHTTPS default
- SAML20 Bearer WSSecurity default
- SAML11 Bearer WSHTTPS default
- SAML11 Bearer WSSecurity default
Die
SAML11-Richtliniensätze sind beinahe identisch mit
den SAML20-Richtliniensätzen, mit der Einschränkung, dass
die SAML20-Richtliniensätze
den SAML-Tokentyp der Version 2.0 unterstützen, während die SAML11-Richtliniensätze
den Tokentyp der Version 1.1 unterstützen.
Es sind zwei Standardrichtliniensätze erforderlich. Daher müssen Sie
den Richtliniensatz
"Username WSHTTPS default" und einen der folgenden Bearer-Richtliniensätze importieren.
Stellen Sie sicher, dass der importierte
Bearer-Richtliniensatz ihrem Szenario entspricht, z. B.
SAML 1.1
oder 2.0 und HTTPS oder Nicht-HTTPS.
- SAML11 Bearer WSHTTPS default für SAML-1.1-Token mit Verwendung von HTTPS
- SAML20 Bearer WSHTTPS default für SAML-1.1-Token mit Verwendung von HTTPS
- SAML20 Bearer WSSecurity default für SAML-2.0-Token mit Verwendung von HTTP
- SAML11 Bearer WSSecurity default für SAML-2.0-Token mit Verwendung von HTTP
Gehen Sie wie folgt vor, um diese Richtliniensätze über die Administrationskonsole zu importieren:
- Klicken Sie auf Services > Richtliniensätze > Anwendungsrichtliniensätze.
- Klicken Sie auf Importieren.
- Wählen Sie Aus Standardrepository aus.
- Wählen Sie die beiden gewünschten Standardrichtliniensätze aus.
Der in diesem Schritt ausgewählte
SAML-Standardrichtliniensatz wird in den folgenden Prozedurschritten als passende SAML-Richtlinie
genannt.
- Klicken Sie auf OK, um die Richtliniensätze zu importieren,
und klicken Sie anschließend auf Speichern, um Ihre Änderungen zu speichern.
- Wenn die SAML-Zusicherungen vom STS signiert werden und die Vertrauenswürdigkeit
des Ausstellers (Unterzeichners) bewertet werden muss,
muss eine Keystoredatei verfügbar sein, die verwendet werden kann, um die Vertrauenswürdigkeit
des X.509-Zertifikats des Ausstellers zu bewerten.
Dieser Keystore kann entweder das öffentliche Zertifikat
des Ausstellers enthalten oder alle Angaben, die erforderlich sind, um den Zertifikatspfad zu erstellen.
Unterstützte Keystoretypen sind jks, jceks und pkcs12.
Diese Datei wird im Folgenden als Truststoredatei bezeichnet.
- Die Richtlinie "Username WSHTTPS default" wird für die Kommunikation mit dem STS verwendet.
Wenn das
STS-Ausstellerzertifikat, das mit SSL verwendet werden soll, nicht in
"NodeDefaultSSLSettings" importiert wurde, lesen Sie die Beschreibung zum Import dieses Zertifikats im Artikel
Unterzeichner von einem fernen SSL-Port abrufen.
Außerdem finden Sie allgemeine Informationen zu STS-Ausstellerzertifikaten im Artikel
Sichere Installation zum Abrufen des Clientunterzeichners in SSL.
Informationen zu diesem Vorgang
Eine SAML-Tokenrichtlinie wird durch eine
Erweiterung des Typs "CustomToken" im Anwendungsserver definiert.
Zum Erstellen der Erweiterung
"CustomToken" müssen Sie die
SAML-Tokenkonfigurationsparameter
als angepasste Eigenschaften im Dokument mit den Client- und Providerbindungen definieren.
Die Beispiele für allgemeine Bindungen,
"Saml Bearer Client sample" und
"Saml Bearer Provider sample",
enthalten die erforderliche Konfiguration für die angepassten Eigenschaften.
Die Client- und Providerbeispielbindungen enthalten Konfigurationsinformationen
sowohl für den SAML11- als auch für den SAML20-Tokentyp und können daher sowohl mit
SAML11- als auch mit
SAML20-Richtliniensätzen verwendet werden.
Die Eigenschaftswerte in den installierten Bindungsbeispielen müssen je nach Art der Implementierung, die für die
SAML-Token geplant ist, geändert werden.
Beispiele für Eigenschaften und Eigenschaftswerte werden in der folgenden Prozedur bereitgestellt.
Die Prozedur zum Ändern des Bindungsbeispiels beginnt
mit der Konfiguration der Richtliniensatzzuordnung des Web-Service-Clients
und ändert dann die Richtliniensatzzuordnung des Web-Service-Providers.
Das in der Prozedur enthaltene Beispiel verwendet die
Web-Service-Anwendung "JaxWSServicesSamples".
Vorgehensweise
- Konfigurieren Sie den Trust-Client.
Wenn Sie allgemeine Bindungen für den Zugriff auf den externen STS verwenden,
fahren Sie direkt mit dem
Schritt "Ordnen Sie Richtliniensatz und Bindungen der Clientanwendung zu" fort.
Wenn Sie anwendungsspezifische Bindungen für den Zugriff auf den externen STS verwenden,
führen sie die folgenden untergeordneten Schritte aus.
- Ordnen Sie einen Richtliniensatz für den Trust-Client temporär der Web-Service-Clientanwendung zu, damit die Bindungen konfiguriert werden können.
Wenn Sie einen Richtliniensatz einem Trust-Client
zuordnen, können Sie die Administrationskonsole zum Erstellen oder Ändern des Clientbindungsdokuments
zu verwenden.
Sie müssen diese Aktion nur dann ausführen, wenn eine anwendungsspezifische Bindung für den Zugriff
auf den externen STS (Security Token Service) verwendet wird.
- Klicken Sie in der Administrationskonsole auf Anwendungen > Anwendungstypen > WebSphere-Unternehmensanwendungen >JaxWSServicesSamples>
Richtliniensätze und Bindungen für Service-Clients.
- Wählen Sie die Web-Service-Clientressource (JaxWSServicesSamples) aus.
- Klicken Sie auf Clientrichtliniensatz zuordnen.
- Wählen Sie den Richtliniensatz Username WSHTTPS default aus.
- Erstellen Sie die Trust-Client-Bindung.
- Wählen Sie die Web-Service-Clientressource (JaxWSServicesSamples) erneut aus.
- Klicken Sie auf Bindung zuweisen.
- Klicken Sie auf Neue anwendungsspezifische Bindung, um eine anwendungsspezifische
Bindung zu erstellen.
- geben Sie einen Bindungskonfigurationsnamen für die neue anwendungsspezifische Bindung an.
In diesem Beispiel ist der Bindungsname SamlTCSample.
- Fügen Sie der Bindung den SSL-Transport-Richtlinientyp hinzu.
Klicken Sie auf Hinzufügen > SSL-Transport und anschließend auf OK.
- Fügen Sie der Bindung den WS-Security-Richtlinientyp hinzu, und ändern Sie anschließend
die Authentifizierungseinstellungen für den Trust-Client.
- Wenn der WS-Security-Richtlinientyp noch nicht in der
Bindungsdefinition "SamlTCSample" enthalten ist,
klicken Sie auf Anwendung > Anwendungstypen
> WebSphere-Unternehmensanwendungen > JaxWSServicesSamples > Richtliniensätze und Bindungen für Service-Clients > SamlTCSample.
- Klicken Sie auf Hinzufügen > WS-Security > Authentifizierung und Zugriffsschutz
> request:uname_token.
- Klicken Sie auf Anwenden.
- Wählen Sie Callback-Handler aus.
- Geben Sie einen Benutzernamen und ein Kennwort für die Authentifizierung des
Web-Service-Clients beim externen STS ein.
- Klicken
Sie auf OK und anschließend auf Speichern.
- Nachdem Sie die Bindungseinstellungen gespeichert haben, kehren Sie in die Anzeige Richtliniensätze und Bindungen für Service-Clients
zurück, um die Zuordnung des Richtliniensatzes und der Bindungen aufzuheben.
- Klicken Sie entweder auf
Richtliniensätze und Bindungen für Service-Clients oder auf Anwendungen > Anwendungstypen
> WebSphere-Unternehmensanwendungen > JaxWSServicesSamples >
Richtliniensätze und Bindungen für Service-Clients.
- Wählen Sie die Web-Service-Clientressource (JaxWSServicesSamples) aus und klicken Sie anschließend
auf Zuordnung des Clientrichtliniensatzes aufheben.
Die anwendungsspezifische Bindungskonfiguration, die Sie gerade
erstellt haben, wird nicht aus dem Dateisystem gelöscht, wenn die Zuordnung des Richtliniensatzes aufgehoben wird.
Daher können Sie die anwendungsspezifische Bindung, die Sie erstellt haben, weiterhin für den Zugriff
auf den STS verwenden können.
- Ordnen Sie Richtliniensatz und Bindungen der Clientanwendung zu.
- Ordnen Sie den gewünschten
SAML-Richtliniensatz der Web-Service-Clientanwendung zu.
- Falls die SAML-Richtlinie noch nicht auf der Seite mit den Richtliniensätzen
und den Bindungen für Service-Clients für JaxWSServicesSamples enthalten ist, klicken Sie auf
Anwendungen > Anwendungstypen > WebSphere-Unternehmensanwendungen
> JaxWSServicesSamples > Richtliniensätze und Bindungen für Service-Clients
- Wählen Sie die Web-Service-Clientressource aus.
- Klicken Sie auf Clientrichtliniensatz zuordnen.
- Wählen Sie die passende SAML-Richtlinie für den Web-Service-Client aus.
- Ordnen Sie dem Client
die allgemeine Bindung "Bearer Client sample" zu.
- Wählen Sie die Web-Service-Clientressource erneut aus.
- Klicken Sie auf Bindung zuweisen.
- Wählen Sie Saml Bearer Client sample aus.
- Konfigurieren Sie die Web-Service-Clientbindungen.
Konfigurieren Sie den
STS-Endpunkt-URL in der Beispielbindung (sample).
- Klicken Sie auf Anwendungen > Anwendungstypen >
WebSphere-Unternehmensanwendungen >JaxWSServicesSamples>
Richtliniensätze und Bindungen für Service-Client > Saml Bearer Client sample
> WS-Security > Authentifizierung und Zugriffsschutz.
- Klicken Sie in der Tabelle mit den Authentifizierungstoken auf
gen_saml11token oder auf gen_saml20token.
- Klicken Sie auf Callback-Handler.
- Ändern Sie die Eigenschaft
"stsURI" in der Weise, dass diese
den STS-Endpunkt angibt.
Diese Eigenschaft ist für
Self-Issuer
in einem zwischengeschalteten Server
nicht erforderlich.
Wird sie dennoch für
Self-Issuer
in einem zwischengeschalteten Server
angegeben, wird sie auf www.websphere.ibm.com/SAML/Issuer/Self gesetzt.
- Überprüfen Sie, ob die folgenden Eigenschaften auf die erforderlichen Werte
gesetzt sind.
Ist eine dieser Eigenschaften auf einen anderen Wert gesetzt, müssen Sie
die Eigenschafteneinstellung in den erforderlichen Wert ändern.
- Die Eigenschaft "confirmationMethod" muss auf Bearer gesetzt sein.
- Die Eigenschaft "keyType" muss auf http://docs.oasis-open.org/ws-sx/ws-trust/200512/Bearer gesetzt sein.
- Die Eigenschaft
"wstrustClientPolicy" muss auf Username
WSHTTPS default gesetzt sein.
- Der für die Eigenschaft "wstrustClientBinding" angegebene Wert muss mit dem Namen der anwendungsspezifischen Bindung
des Trust-Clients übereinstimmen, der im vorherigen Schritt erstellt wurde.
Im vorherigen Schritt könnte z. B. eine anwendungsspezifische Bindung
mit dem Namen "SamlTCSample" erstellt worden sein. In diesem Fall muss
SamlTCSample als Wert für die Eigenschaft
"wstrustClientBinding" angegeben werden.
- Optional: Wenn Sie die Art und Weise ändern möchten, in der der Anwendungsserver nach der Bindung sucht,
können Sie die Eigenschaft "wstrustClientBindingScope" angeben und ihren Wert auf
"application" oder "domain" setzen.
Wird die Eigenschaft auf den Wert
"domain" (Domäne) gesetzt, sucht der Anwendungsserver die Bindung
"wstrustClientBinding" in der Dateisystemposition, die die Dokumente mit allgemeinen Bindungen enthält.
Wenn Sie den Wert auf "application" (Anwendung) setzen, sucht der Anwendungsserver die Eigenschaft
"wstrustClientBinding" an der Dateisystemposition, die anwendungsspezifische Bindungsdokumente
enthält.
Wird die Eigenschaft
"wstrustClientBindingScope" nicht angegeben, ist das Standardverhalten für den Anwendungsserver
wie folgt festgelegt: zunächst sucht der Anwendungsserver nach anwendungsspezifischen Bindungen und anschließend nach allgemeinen Bindungen.
Wenn die Bindung
"wstrustClientBinding" nicht lokalisiert werden kann, verwendet der Anwendungsserver die Standardbindungen.
- Optional: Wenn Sie die SOAP-Version des Standard-Trust-Clients ändern möchten,
die der des Anwendungsclients entspricht, geben Sie für die angepasste Eigenschaft
"wstrustClientSoapVersion" einen neuen Wert an.
Setzen Sie die angepasste Eigenschaft "wstrustClientSoapVersion" auf 1.1, um zur
SOAP-Version 1.1 zu wechseln.
Setzen Sie die angepasste Eigenschaft "wstrustClientSoapVersion" auf 1.2, um zur
SOAP-Version 1.2 zu wechseln.
- Klicken Sie auf Anwenden und anschließend auf Speichern.
Wenn weitere Änderungen an der "wstrustClientBinding"-Konfiguration
erforderlich sind und die Eigenschaft
"wstrustClientBinding" auf eine anwendungsspezifische Bindung zeigt, in diesem Fall z. B.
"SamlTCSample", müssen Sie die anwendungsspezifische
Bindung dem Web-Service-Client zuordnen, bevor Sie die Änderungen vornehmen können.
Die Zuordnung ist temporär.
Wie im vorherigen Schritt erläutert, können Sie die Zuordnung der geänderten anwendungsspezifischen Bindung
zum Web-Service-Client aufheben, nachdem die Änderungen abgeschlossen sind.
Bevor Sie mit dem nächsten Schritt fortfahren, überprüfen Sie, ob das SSL-Zertifikat vom externen STS
im "NodeDefaultTrustStore" enthalten ist. Weitere Informationen finden Sie im Abschnitt "Vorbereitungen".
- Starten Sie die Web-Service-Clientanwendung erneut, damit die Änderungen, die an der Richtliniensatzzuordnung
vorgenommen wurden, wirksam werden.
Die Informationen zur Zuordnung von Richtliniensatz und Bindungen
werden beim Neustart der Anwendung
aktualisiert. Die aktualisierten Informationen in den allgemeinen Bindungen werden
jedoch erst dann in der Laufzeit widergespiegelt,
wenn alle allgemeinen Bindungen aktualisiert wurden.
Die Anwendung muss nach dem Laden von allgemeinen Bindungen erneut gestartet werden, damit alle Aktualisierungen genutzt werden.
Weitere Informationen finden Sie im Schritt "Laden Sie die allgemeinen Client- und Providerbindungen erneut und starten Sie die Anwendung erneut".
- Ordnen Sie Richtliniensatz und Bindungen der Provideranwendung zu.
- Ordnen Sie die passende
SAML-Richtliniensatz dem Web-Service-Provider zu.
- Klicken Sie in der Administrationskonsole auf
Anwendungen
> Anwendungstypen > WebSphere-Unternehmensanwendungen > JaxWSServicesSamples
> Richtliniensätze und Bindungen für Service-Provider.
- Wählen Sie die Web-Service-Provider-Ressource (JaxWSServicesSamples) aus.
- Klicken Sie auf Richtliniensatz zuordnen.
- Wählen Sie die passende SAML-Richtlinie für den Web-Service-Provider aus.
- Weisen Sie die allgemeine Bindung
"Saml Bearer Provider sample" zu.
- Wählen Sie die Web-Service-Provider-Ressource erneut aus.
- Klicken Sie auf Bindung zuweisen.
- Wählen Sie Saml Bearer Provider sample aus.
- Konfigurieren Sie die Web-Service-Providerbindungen.
- Wenn die
Web-Service-Provider-Bindungen
noch nicht auf der Seite mit den Richtliniensätzen und Bindungen für Service-Provider für
JaxWSServicesSamples enthalten sind,
klicken Sie auf
WebSphere-Unternehmensanwendungen > JaxWSServicesSamples
> Richtliniensätze und Bindungen für Service-Provider > Saml Bearer Provider
sample.
- Klicken Sie auf WS-Security > Authentifizierung und Zugriffsschutz.
- Klicken Sie in der Tabelle "Authentifizierungstoken" auf con_saml11token oder auf con_saml20token.
- Klicken Sie auf Callback-Handler.
Die Seite "Callback-Handler" der Administrationskonsole wird dazu verwendet,
die Bindungsdaten für die Validierung der digitalen Signatur
des SAML-Tokenausstellers für den STS zu konfigurieren.
- Optional: Setzen Sie die angepasste Eigenschaft
"signatureRequired" auf
false, wenn die Prüfung der digitalen Signatur nicht ausgeführt werden soll.
Sie können die angepasste Eigenschaft
"signatureRequired"
auf false setzen, wenn die Prüfung der digitalen Signatur nicht ausgeführt werden soll.
Es hat sich jedoch aus Sicherheitsgründen bewährt,
dass SAML-Zusicherungen signiert werden und immer eine Validierung der digitalen Signatur des Ausstellers erforderlich ist.
"False" ist der Standardwert für diese Eigenschaft.
- Optional: Setzen Sie die angepasste Eigenschaft
"trustAnySigner" auf
true, wenn keine Validierung von Unterzeichnerzertifikaten ausgeführt sein soll.
Die Konfigurationseinstellung "Jedes Zertifikat anerkennen" wird für die Validierung der SAML-Signatur ignoriert.
Diese Eigenschaft ist nur dann gültig, wenn die angepasste Eigenschaft
"signatureRequired" auf
true, den Standardwert für diese Eigenschaft, gesetzt ist.
- Führen Sie die folgenden Aktionen aus, wenn Zusicherungen vom STS signiert werden,
die angepasste Eigenschaft "signatureRequired" auf den Standardwert
true gesetzt ist
und die angepasste Eigenschaft
"trustAnySigner" auf den Standardwert
false gesetzt ist.
- Nehmen Sie ein entsprechendes Zertifikat in den
Truststore für den Provider auf, damit
das Signaturzertifikat des externen STS als vertrauenswürdig validiert wird,
z. B. das STS-Signaturzertifikat selbst oder das Stammzertifikat der Zertifizierungsstelle.
- Setzen Sie die angepasste Eigenschaft
"trustStorePath" auf einen Wert, der einen Truststoredateinamen angibt.
Dieser kann ein vollständig qualifizierter Dateipfad sein oder
Schlüsselwörter wie ${USER_INSTALL_ROOT}.
- Setzen Sie die angepasste Eigenschaft
"trustStoreType" auf einen Wert, der den Keystoretyp angibt.
Unterstützte Keystoretypen sind jks, jceks und pkcs12.
- Setzen Sie die angepasste Eigenschaft
"trustStorePassword" auf einen Wert, der das Truststorekennwort angibt.
Das Kennwort wird als angepasste Eigenschaft in der Administrationskonsole gespeichert und verschlüsselt.
- Optional: Setzen Sie die angepasste Eigenschaft "trustedAlias " auf einen Wert wie
"samlissuer". Wenn diese Eigenschaft angegeben wird,
ist das durch den Alias dargestellte
X.509-Zertifikat das einzige STS-Zertifikat das für die SAML-Signaturprüfung anerkannt wird.
Wird diese angepasste Eigenschaft nicht angegeben,
verwendet die Web-Service-Laufzeitumgebung das Signaturzertifikat in den SAML-Zusicherungen, um
die SAML-Signatur zu prüfen und verifiziert das Zertifikat
anschließend anhand des konfigurierten Truststore.
- Optional: Konfigurieren Sie den Empfänger in der Weise, dass er den Namen des Ausstellers und/oder
den registrierten Name des Zertifikatsinhabers ("SubjectDN"), der
für den Aussteller in der SAML-Zusicherung angegeben ist, prüft.
Sie können Sie eine Liste mit Namen von anerkannten Ausstellern oder eine Liste mit anerkannten SubjectDNs für Zertifikate
oder beide Arten von Listen erstellen
Wenn Sie sowohl Listen mit Namen der Aussteller als auch Listen mit SubjectDNs
erstellen, werden sowohl die Namen der Aussteller als auch die SubjectDNs geprüft.
Wenn der empfangene Name des SAML-Ausstellers oder SubjectDN des Unterzeichners
nicht in den Listen der anerkannten Namen enthalten ist, scheitert die SAML-Validierung und eine Ausnahme wird ausgegeben.
Dieses Beispiel zeigt, wie eine Liste mit anerkannten Ausstellern und anerkannten
SubjectDNs erstellt wird.
Verwenden Sie für jeden Namen eines anerkannten Ausstellers "trustedIssuer_n", wobei n eine positive ganze Zahl ist. Verwenden Sie für jeden anerkannten SubjectDN
"trustedSubjectDN_n", wobei
n eine positive ganze Zahl ist. Wenn Sie beide Arten von Listen erstellen, muss die ganze Zahl
n in beiden Listen für dieselbe SAML-Zusicherung identisch sein.
Die ganze Zahl n beginnt bei
1 und steigt um jeweils 1.
In diesem Beispiel wird eine SAML-Zusicherung mit dem Ausstellernamen
"WebSphere/samlissuer", unabhängig von
dem SubjectDN
des Unterzeichners. Daher wird die
folgende angepasste Eigenschaft hinzugefügt:
<properties value="WebSphere/samlissuer" name="trustedIssuer_1"/>
Außerdem wird eine von
"IBM/samlissuer" ausgestellte SAML-Zusicherung anerkannt, wenn der
SubjectDN des Unterzeichners
"ou=websphere,o=ibm,c=us" ist. Daher werden die
folgenden angepassten
Eigenschaften hinzugefügt:
<properties value="IBM/samlissuer" name="trustedIssuer_2"/>
<properties value="ou=websphere,o=ibm,c=us" name="trustedSubjectDN_2"/>
- Entschlüsseln Sie die SAML-Zusicherung.
Wenn die SAML-Zusicherung vom STS mit dem öffentlichen Schlüssel verschlüsselt ist,
erscheint das SAML-Token im SOAP-Sicherheitsheader
als Element "EncryptedAssertion" anstatt als Element
"Assertion". Zum Entschlüsseln der SAML-Zusicherung
müssen Sie den privaten Schlüssel
konfigurieren, der dem öffentlichen Schlüssel entspricht, mit dem die Zusicherung auf dem STS verschlüsselt wurde.
Damit der Empfänger die SAML-Zusicherung entschlüsseln kann, müssen für die
folgenden angepassten Eigenschaften des Callback-Handlers
die in der folgenden Tabelle beschriebenen Werte festgelegt werden.
Angepasste Eigenschaft |
Wert |
keyStorePath |
Position des Keystore. |
keyStoreType |
Passender Keystoretyp. Unterstützte Keystoretypen sind
jks, jceks und pkcs12.
|
keyStorePassword |
Kennwort für den Keystore. |
keyAlias |
Der Alias des für die SAML-Verschlüsselung verwendeten privaten Schlüssels. |
keyName |
Der Name des für die SAML-Verschlüsselung verwendeten privaten Schlüssels. |
keyPassword |
Das Kennwort für den Schlüsselnamen. |
- Optional: Sie können die Caller-Bindung so konfigurieren, dass
ein SAML-Token ausgewählt wird, das die Identität des Anforderers darstellt. Die WS-Security-Laufzeitumgebung verwendet die angegebene JAAS-Anmeldekonfiguration,
um mit dem SAML-Token "NameId" oder "NameIdentifier" als Benutzernamen
den Benutzersicherheitsnamen und die Gruppenzuordnungsdaten aus der Benutzerregistry abzurufen.
- Klicken Sie auf
.
- Klicken Sie auf Neu, um die Caller-Konfiguration zu erstellen.
- Geben Sie einen
Namen an, z. B.
Caller.
- Geben Sie für Lokaler Abschnitt der Caller-Identität einen Wert ein,
Geben Sie für SAML-1.1-Token Folgendes ein:
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1Geben Sie für SAML-2.0-Token Folgendes ein:
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0
- Klicken Sie auf Anwenden und Speichern.
- Laden Sie die allgemeinen Client- und Providerbindungen erneut und starten Sie die Anwendung erneut.
Wenn die Informationen in den allgemeinen Bindungen aktualisiert wurden,
werden die neuen Einstellungen nicht sofort zur Ausführungszeit widergespiegelt.
Eine aktualisierte allgemeine Bindung muss vom Richtliniensatzmanager im Anwendungsserver erneut geladen werden, damit die Aktualisierungen in Kraft treten.
Sie können aktualisierte Richtliniensätze und allgemeine Bindungen erneut laden, indem Sie den Anwendungsserver stoppen und erneut starten oder indem Sie in wsadmin den
Befehl "refresh" für die MBean
"PolicySetManager" verwenden. Weitere Informationen zum Aktualisieren des Richtliniensatzmanagers finden Sie im Artikel
Richtliniensatzkonfigurationen mit
wsdamin-Scripting aktualisieren.
Führen Sie eine der folgenden Aktionen aus, um
die allgemeinen
Client- und Providerrichtlinien erneut zu laden und die Anwendungen erneut zu starten:
- Starten Sie den Anwendungsserver.
- Aktualisieren Sie
die MBean "PolicySetManager", und führen Sie anschließend einen Neustart der Client- und Provider-Web-Service-Anwendungen aus.
Ergebnisse
Wenn Sie die Prozedur abgeschlossen haben,
kann die Web-Service-Anwendung "JaxWSServicesSamples" den Richtliniensatz
"SAML Bearer default" und die Beispiele für allgemeine Bindungen,
"Saml Bearer Client sample" und "Saml Bearer Provider sample", verwenden.