test

Oracle OpenSSO Update 2-Versionsinformationen

Kapitel 3 Verwenden des Sicherheitstoken-Diensts

Als vertrauenswürdiger Autoritätsdienst gibt der OpenSSO-Sicherheitstoken-Dienst Sicherheits-Token aus und validiert sie. Als Webdienste-Sicherheitsanbieter kommuniziert der Sicherheitstoken-Dienst gesichert zwischen dem Webdienst-Client und dem OpenSSO STS-Dienst selbst. Seit Open SSO 8.0 Update 2 sind zahlreiche Verbesserungen am Sicherheitstoken-Dienst erfolgt.

In diesem Kapitel werden die folgenden Themen behandelt.

Hinzufügen eines WSSAuth-Authentifizierungsmoduls

Das Webdienst-Sicherheitsauthentifizierungsmodul ermöglicht es OpenSSO, einen Benutzernamen mit einem gesammelten Passwort zu validieren, das als Authentifizierungs-Token erhalten wurde und in einer Dienstanforderung vom Webdienst-Client an einen Webdienstanbieter enthalten war.

ProcedureSo fügen Sie eine neue Instanz eines Webdienst-Sicherheitsauthentifizierungsmoduls hinzu:

  1. Klicken Sie in der Registerkarte Access Manager auf die Unterregisterkarte Authentication (Authentifizierung).

  2. Im Abschnitt Module Instances (Modulinstanzen) klicken Sie auf New (Neu).

  3. Geben Sie im Feld Name einen Namen für diese Instanz des WSSAuth-Authentifizierungsmoduls ein.

  4. Wählen Sie als Typ WSSAuth aus.

  5. Konfigurieren Sie die Instanz des WSSAuth-Authentifizierungsmoduls.

Procedure So konfigurieren Sie eine Instanz des WSSAuth-Authentifizierungsmoduls:

  1. Klicken Sie in der Registerkarte Access Manager auf die Unterregisterkarte Authentication (Authentifizierung).

  2. Klicken Sie im Abschnitt Module Instances (Modulinstanzen) auf den Namen der WSSAuth-Authentifizierungsinstanz, die Sie konfigurieren möchten.

  3. Geben Sie Werte für die Attribute WSSAuth Authentication Module Instance Realm (WSSAuth-Authentifizierungsmodul-Instanzbereich) ein.

    In der folgenden Tabelle werden eine Liste und Beschreibungen der Attribute dargestellt, die Sie konfigurieren können.

    Benutzersuchattribut

    Wird noch entwickelt

    Benutzerbereich

    Wird noch entwickelt

    Benutzerpasswortattribut

    Wird noch entwickelt

    Authentication Level

    Wird noch entwickelt

Hinzufügen eines OAMAuth-Authentifizierungsmoduls

Das Oracle-Authentifizierungsmodul ermöglicht es OpenSSO, einen Administrator in OpenSSO zu authentifizieren und einmalig anzumelden, der sich zuvor bei Oracle Access Manager authentifiziert hat. Der Administrator muss keine Berechtigungsnachweise in OpenSSO angeben.

ProcedureSo fügen Sie eine neue Instanz eines Oracle-Authentifizierungsmoduls hinzu:

  1. Klicken Sie in der Registerkarte Access Manager auf die Unterregisterkarte Authentication (Authentifizierung).

  2. Klicken Sie im Abschnitt Modules Instances auf New.

  3. Geben Sie im Feld Name einen Namen für diese Oracle-Authentifizierungsmodulinstanz ein.

  4. Wählen Sie als Typ OAMAuth aus.

  5. Klicken Sie auf „OK“.

  6. Konfigurieren Sie die Instanz des OAMAuth-Authentifizierungsmoduls.

ProcedureSo konfigurieren Sie eine Instanz eines Oracle-Authentifizierungsmoduls:

  1. Klicken Sie in der Registerkarte Access Manager auf die Unterregisterkarte Authentication (Authentifizierung).

  2. Klicken Sie im Abschnitt Module Instances (Modulinstanzen) auf den Namen der OAMAuth-Authentifizierungsinstanz, die Sie konfigurieren möchten.

  3. Geben Sie Werte für die Attribute Oracle Authentication Module Instance Realm (Oracle-Authentifizierungsmodul-Instanzbereich) ein.

    In der folgenden Tabelle werden eine Liste und Beschreibungen der Attribute dargestellt, die Sie konfigurieren können.

    Kopzeilenname des Remote-Benutzers

    Wird noch entwickelt

    Zugelassene Kopfzeilenwerte

    Die Liste Current Values (Aktuelle Werte) zeigt To Be Developed (Wird noch entwickelt) an.

    • Zum Hinzufügen eines Kopfzeilenwerts in der Liste geben Sie im Feld New Value (Neuer Wert) To Be Developed ein und klicken auf Add (Hinzufügen).

    • Um einen Eintrag aus der Liste Current Values zu entfernen, wählen Sie den Eintrag aus und klicken auf Remove (Entfernen).

    Authentifizierungsebene

    Wird noch entwickelt

Generieren von Sicherheitstoken

Oracle OpenSSO Security Token Service (OpenSSO STS) stellt eine Vertrauensstellung zwischen einem Webdienst-Client und einem Webdienstanbieter her und vermittelt anschließend das Vertrauen zwischen ihnen. Kann der Webdienst Tokens vertrauen, die von lediglich einer Entität ausgegeben wurden? OpenSSO STS? Statt mit mehreren Clients kommunizieren zu müssen. Auf diese Weise reduziert OpenSSO STS den Aufwand zur Vertrauenspunktverwaltung.

In den folgenden Abschnitten werden Anweisungen zum Ermitteln Ihrer Sicherheitstoken-Anforderungen und zum entsprechenden Konfigurieren des Sicherheitstoken-Dienstes zum Generieren und Validieren von Sicherheitstoken dargestellt.

Registrieren eines Webdienstanbieters in OpenSSO STS

Wenn Sie ein neues Webdienstanbieter-Sicherheitsagentenprofil hinzufügen, wird der Webdienstanbieter automatisch in OpenSSO STS registriert. In den folgenden Abschnitten werden mehr Details dargestellt:

Wenn Sie einen Webdienstanbieter in OpenSSO STS registriert haben, können Sie OpenSSO STS dazu konfigurieren, Webclient-Sicherheitstokens zu generieren, die der Webdienstanbieter akzeptieren kann.

Anfordern eines Webdienst-Clientsicherheits-Tokens von OpenSSO STS

Bevor Sie den Sicherheitstoken-Dienst zum Generieren von Webclient-Sicherheitstoken konfigurieren, müssen Sie ermitteln, welche Art von Sicherheitstoken der Webdienstanbieter benötigt. OpenSSO STS unterstützt Liberty Alliance Project-Sicherheitstoken und Web Services-Interoperability Basic Security Profile-Sicherheitstoken.

Prozessablauf beim Generieren von Sicherheitstokens

Wenn Sicherheit mithilfe von Liberty Alliance Project-Tokens aktiviert ist, sendet der HTTP-Client oder der Browser über den Webdienst-Client eine Zugriffsanforderung an den Webdienstanbieter. Ein Webdienste-Sicherheitsagent leitet die Anforderung an den OpenSSO STS-Authentifizierungsdienst weiter. Wenn der Liberty Alliance Project-Sicherheitsmechanismus aktiv ist, gibt ein HTTP-Sicherheitsagent die Weiterleitung aus. Wenn WS-IBS-Sicherheit verwendet wird, gibt ein SOAP-Sicherheitsagent die Weiterleitung aus.

Der OpenSSO STS-Authentifizierungsdienst ermittelt den Sicherheitsmechanismus, der beim Webdienstanbieter registriert ist, und ruft die entsprechenden Sicherheitstoken ab. Nach der erfolgreichen Authentifizierung stellt der Webdienst-Client einen SOAP-Nachrichtentext bereit, während der SOAP-Sicherheitsagent auf Seite des Webdienst-Clients die Sicherheitskopfzeilen und ein Token einfügt. Die Nachricht wird anschließend entfernt, bevor die Anforderung an den WSP gesendet wird.

Der SOAP-Sicherheitsagent auf Seite des Webdienstanbieters überprüft die Signatur und den Sicherheitstoken in der SOAP-Anforderung, bevor er die Anforderung an den Webdienstanbieter selbst weiterleitet. Der Webdienstanbieter verarbeitet sie anschließend und gibt eine vom SOAP-Sicherheitsagenten signierte Antwort an den Webdienst-Client zurück. Der SOAP-Sicherheitsagent auf Seite des Webdienst-Clients überprüft anschließend die Signatur, bevor er die Antwort an den Webdienst-Client weiterleitet.

In der folgenden Tabelle werden eine Liste und kurze Beschreibungen von Tokens dargestellt, die für Liberty Alliance Project-Transaktionen unterstützt werden.

Tabelle 3–1 Requestor Tokens - Liberty Alliance Project

Token

Erfüllt diese Anforderungen

X.509 

  • Der gesicherte Webdienst verwendet eine Public Key Infrastructure (Infrastruktur mit öffentlichen Schlüsseln), in der der Webdienst-Client einen öffentlichen Schlüssel als Mittel zum Ermitteln des Anforderers zur Verfügung stellt, und mit der der Webdienstanbieter authentifiziert wird.

  • Der gesicherte Webdienst verwendet eine Public Key Infrastructure (Infrastruktur mit öffentlichen Schlüsseln), in der der Webdienst-Client einen öffentlichen Schlüssel als Mittel zum Ermitteln des Anforderers zur Verfügung stellt, und mit der der Webdienstanbieter authentifiziert wird.

BearerToken 

  • Der gesicherte Webdienst verwendet die SAML-Bearer-Token-Bestätigungsmethode von Security Assertion Markup Language (SAML).

  • Der Webdienst-Client stellt eine SAML-Behauptung mit Informationen zum öffentlichen Schlüssel zur Verfügung, um den Anforderer gegenüber dem Webdienstanbieter zu authentifizieren.

  • Eine zweite Signatur bindet die Behauptung an die SOAP-Nachricht.

  • Die zweite Signaturbindung verwendet Regeln, die vom Liberty Alliance Project verwendet wurden.

SAML-Token 

  • Der gesicherte Webdienst verwendet die SAML-Schlüsselinhaber-Bestätigungsmethode.

  • Der Webdienst-Client fügt eine SAML-Behauptung und eine digitale Signatur in eine SOAP-Kopfzeile ein.

  • Ein Absenderzertifikat oder öffentlicher Schlüssel wird ebenfalls mit der Signatur zur Verfügung gestellt.

  • Der Versand wird mithilfe von Regeln verarbeitet, die vom Liberty Alliance Project definiert wurden.

In den folgenden Tabellen werden eine Liste und kurze Beschreibungen von Tokens dargestellt, die für WS-IBS-Transaktionen unterstützt werden.

Tabelle 3–2 Anforderer-Tokens - WS-IBS

Token

Erfüllt diese Anforderungen

Benutzername 

  • Der gesicherte Webdienst erfordert einen Benutzernamen, ein Passwort und optional eine Signierung für die Anforderung.

  • Der Webdienst-Verbraucher stellt ein Benutzernametoken als Mittel zum Identifizieren des Anforderers zur Verfügung.

  • Der Webdienstverbraucher stellt ein Passwort, gemeinsames Geheimnis oder ein Passwortäquivalent zum Authentifizieren der Identität gegenüber dem Webdienstanbieter zur Verfügung.

X.509 

Der gesicherte Webdienst verwendet eine PKI (Public Key Infrastructure, in der der Webdienst-Verbraucher einen öffentlichen Schlüssel als Mittel zum Ermitteln des Anforderers und Abschließen des Authentifizierung gegenüber dem Webdienstanbieter. 

SAML-Schlüsselinhaber 

  • Der gesicherte Webdienst verwendet die SAML-Schlüsselinhaber-Bestätigungsmethode.

  • Der Webdienst-Client stellt eine SAML-Behauptung mit Informationen zum öffentlichen Schlüssel zur Verfügung, um den Anforderer gegenüber dem Webdienstanbieter zu authentifizieren.

  • Eine zweite Signatur bindet die Behauptung an die SOAP-Payload.

SAML-SenderVouches 

  • Der gesicherte Webdienst verwendet die SAML-Sender-Vouches-Bestätigungsmethode.

  • Der Webclient-Verbraucher fügt eine SAML-Behauptung und eine digitale Signatur in eine SOAP-Kopfzeile ein. Ein Absenderzertifikat oder öffentlicher Schlüssel wird ebenfalls mit der Signatur zur Verfügung gestellt.

Verwenden der Matrix zum Generieren von Sicherheitstokens

Verwenden Sie die Matrix zum Generieren von Sicherheitstoken als Hilfe beim Konfigurieren von OpenSSO STS zum Generieren von Webdienst-Client-Sicherheitstokens, die der Webdienstanbieter benötigt. Machen Sie zuerst in der letzten Spalte mit dem Titel OpenSSO STS Output Token (OpenSSO STS Ausgabetoken) eine Beschreibung ausfindig, die den Anforderungen des Webdienstanbieter-Tokens entspricht. Verwenden Sie anschließend die Parameterwerte in der gleichen Zeile, wenn Sie den Sicherheitstoken-Dienst konfigurieren. Die "Legende der Matrix zum Generieren von Tokens" enthält Informationen zu den Tabellenkopfzeilen und den verfügbaren Optionen. Im Abschnitt 5.2.3 "So konfigurieren Sie den Sicherheitstoken-Dienst" finden Sie detaillierte Konfigurationsanweisungen. Allgemeine Informationen zur Webdienstsicherheit und die entsprechende Terminologie finden Sie unter:

In der Matrix zum Generieren von Sicherheitstoken werden häufig verwendete Sicherheitstokendienst-Parametereinstellungen und die Typen der Sicherheitstoken zusammengefasst, die OpenSSO STS auf Basis dieser Einstellungen generiert.

Tabelle 3–3 Matrix zum Generieren von Sicherheitstokens

Zeile

Sicherheitsbindung auf Nachrichtenebene

Webdienst-Clienttoken

KeyType

OnBehalfOf Token

Use Key

OpenSSO STS-Ausgabetoken

1 

Asymmetrisch  

X509  

Inhaber  

Ja  

Nein  

SAML-Inhaber, kein Beweisschlüssel 

2 

Asymmetrisch  

Benutzername  

Inhaber  

Ja  

Nein  

SAML-Inhaber, kein Beweisschlüssel 

3 

Asymmetrisch  

X509  

Inhaber  

Nein  

Nein  

SAML-Inhaber, kein Beweisschlüssel 

4 

Asymmetrisch  

Benutzername  

Inhaber  

Nein  

Nein  

SAML-Inhaber, kein Beweisschlüssel 

5 

Asymmetrisch  

X509  

Symmetrisch  

Ja  

Nein  

SAML-Schlüsselinhaber, symmetrischer Beweisschlüssel 

6 

Asymmetrisch  

Benutzername  

Symmetrisch  

Ja  

Nein  

SAML-Schlüsselinhaber, symmetrischer Beweisschlüssel 

7 

Asymmetrisch  

X509  

Symmetrisch  

Nein  

Nein  

SAML Schlüsselinhaber, Symmetrisch 

8 

Asymmetrisch  

Benutzername  

Symmetrisch  

Nein  

Nein  

SAML-Schlüsselinhaber, symmetrischer Beweisschlüssel 

9 

Asymmetrisch  

X509  

Asymmetrisch  

Nein  

Öffentlicher Schlüssel des Webdienstclients  

SAML-Schlüsselinhaber, asymmetrischer Beweisschlüssel 

10 

Asymmetrisch  

X509  

Oracle-herstellereigen für SAML-Absendernachweise  

Ja  

Nein  

SAML-Absendernachweise, kein Beweisschlüssel 

11 

Asymmetrisch  

Benutzername  

Oracle-herstellereigen für SAML-Absendernachweise  

Ja  

Nein  

SAML-Absendernachweise, kein Beweisschlüssel 

12 

Asymmetrisch  

X509  

Oracle-herstellereigen für SAML-Absendernachweise  

Nein  

Nein  

FEHLER 

13 

Asymmetrisch  

Benutzername  

Oracle-herstellereigen für SAML-Absendernachweise  

Nein  

Nein  

FEHLER 

14 

Transport  

Benutzername  

Inhaber  

Ja  

Nein  

SAML-Inhaber, kein Beweisschlüssel 

15 

Transport  

Benutzername  

Inhaber  

Nein  

Nein  

SAML-Inhaber, kein Beweisschlüssel 

16 

Transport  

Benutzername  

Symmetrisch  

Ja  

Nein  

SAML-Schlüsselinhaber, Symmetrisch 

17 

Transport  

Benutzername  

Symmetrisch  

Nein  

Nein  

SAML-Schlüsselinhaber, symmetrischer Beweisschlüssel 

18 

Transport  

Benutzername  

Oracle-herstellereigen für SAML-Absendernachweise  

Ja  

Nein  

SAML-Absendernachweise, kein Beweisschlüssel 

19 

Transport  

Benutzername  

Oracle-herstellereigen für SAML-Absendernachweise  

Nein  

Nein  

FEHLER 

20 

Asymmetrisch  

Benutzername  

Asymmetrisch  

Nein  

Öffentlicher Schlüssel des Webdienstclients  

FEHLER 

21 

Transport  

Benutzername  

Asymmetrisch  

Nein  

Öffentlicher Schlüssel des Webdienstclients  

FEHLER 

22 

Asymmetrisch  

X509  

Asymmetrisch  

Ja  

Nein  

FEHLER 

23 

Asymmetrisch  

Benutzername  

Asymmetrisch  

Ja  

Nein  

FEHLER 

24 

Transport  

Benutzername  

Asymmetrisch  

Ja  

Nein  

FEHLER 

25 

Asymmetrisch  

X509  

Asymmetrisch  

Nein  

Nein  

SAML-Schlüsselinhaber, asymmetrischer Beweisschlüssel 

26 

Asymmetrisch  

X509  

Nein  

Nein  

Nein  

SAML-Schlüsselinhaber, asymmetrischer Beweisschlüssel 

27 

Asymmetrisch  

Benutzername  

Nein  

Nein  

Nein  

SAML-Schlüsselinhaber, symmetrischer Beweisschlüssel 

28 

Transport  

Benutzername  

Nein  

Nein  

Nein  

SAML-Schlüsselinhaber, symmetrischer Beweisschlüssel 

Probleme und Problemumgehungen im Sicherheitstoken-Dienst

Wird noch entwickelt

Probleme und Problemumgehungen in der Konfiguration

Wird noch entwickelt

Dokumentations-Errata

Wird noch entwickelt