AuthnRequest-Einstellungen in OAM und SP
In diesem Artikel werden die verschiedenen OAM/SP-Einstellungen aufgeführt, die sich darauf auswirken, wie eine AuthnRequest-Nachricht in OAM in einem Federation-SSO-Ablauf erstellt wird. Die Nachricht AuthnRequest wird von einem SP verwendet, um einen Federation-SSO-Vorgang zu starten und der IdP anzugeben, wie der Vorgang ausgeführt werden soll:
- Wie der Benutzer unter IdP herausgefordert werden soll
- Gibt an, ob der Benutzer bei IdP eine Challenge ausführen soll, selbst wenn bereits eine Session bei IdP für diesen Benutzer vorhanden ist
- Welches
NameID-Format in der SAML-Assertion angefordert werden soll - Welches Binding (Artefakt oder HTTP-POST) muss vom IdP angefordert werden, um die Assertion zu senden
- Welches Profil von OAM/SP zum Senden der AuthnRequest-Nachricht verwendet werden soll
Protokolle
Die Protokolle SAML 2.0, SAML 1.1 und OpenID 2.0 definieren verschiedene Nachrichtenelemente und Regeln, mit denen ein Administrator die Federation-SSO-Abläufe auf unterschiedliche Weise beeinflussen kann, wenn der SP einen SSO-Vorgang auslöst:
- SAML 2.0 ermöglicht eine umfassende Anpassung über die AuthnRequest-Nachricht
- SAML 1.1 lässt keine Anpassung zu, da die Spezifikationen keine Authentifizierungsanforderungsnachricht definieren
- OpenID 2.0 ermöglicht einige Anpassungen, hauptsächlich über die OpenID 2.0-Erweiterungen wie PAPE oder UI
SAML 2.0
OAM/SP ermöglicht die Anpassung der SAML 2.0 AuthnRequest-Nachricht für die folgenden Elemente:
ForceAuthn:
- Boolescher Wert, der angibt, ob IdP den Benutzer für die erneute Authentifizierung erzwingen soll, selbst wenn der Benutzer noch eine gültige Session hat
- Standardmäßig auf "false" gesetzt
IsPassive
- Boolescher Wert, der angibt, ob IdP im Rahmen des Federation-SSO-Vorgangs mit dem Benutzer interagieren darf.
- Wenn dieser Wert auf "false" gesetzt ist, kann der Federation-SSO-Vorgang zu einem Fehler mit dem NoPassive-Fehlercode führen, da IdP den Benutzer nicht identifizieren kann
- Standardmäßig auf "false" gesetzt
RequestedAuthnContext
- Element, das angibt, wie der Benutzer unter IdP herausgefordert werden soll
- Wenn der SP eine Federation-Authentifizierungsmethode anfordert, die der IdP unbekannt ist oder für die IdP nicht konfiguriert ist, führt der Federation-SSO-Ablauf zu einem Fehler mit dem
NoAuthnContext-Fehlercode - Standardmäßig fehlt
NameIDPolicy
- Element, das angibt, welches
NameID-Format IdP in die SAML-Assertion aufnehmen soll - Wenn der SP ein
NameID-Format anfordert, das der IdP unbekannt ist oder für das die IdP nicht konfiguriert ist, führt der Federation-SSO-Ablauf zu einem Fehler mit demInvalidNameIDPolicy-Fehlercode - Wenn sie fehlt, verwendet IdP im Allgemeinen das Standardformat NameID, das für diesen SP-Partner unter IdP konfiguriert ist
- Standardmäßig fehlt
ProtocolBinding
- Element, das angibt, welches SAML-Binding von der IdP verwendet werden soll, um den Benutzer mit der SAML-Assertion an den SP umzuleiten
- Auf Artefakt oder HTTP-POST setzen
- Standardmäßig auf HTTP-POST gesetzt
Mit OAM/SP kann der Administrator den Server auch so konfigurieren, dass er:
- Legen Sie fest, welches Binding von OAM/SP verwendet werden soll, um den Benutzer mit der SAML 2.0-Nachricht AuthnRequest an IdP umzuleiten:
- Redirect oder HTTP-POST
- Standardmäßig auf "Umleiten" gesetzt
- Legen Sie fest, welches Binding von OAM/SP verwendet werden soll, um den Benutzer während der Abmeldung mit SAML 2.0-Abmeldemeldungen an IdP umzuleiten:
- Redirect oder HTTP-POST
- Standardmäßig auf "Umleiten" gesetzt
SAML 1.1
Die SAML 1.1-Spezifikationen definieren keine Nachricht, die der SP an IdP senden soll, wenn ein Federation-SSO-Vorgang gestartet wird. Daher ist es nicht möglich, OAM/SP zu konfigurieren, wie sich dies auf den Start des Federation-SSO-Ablaufs auswirkt.
OpenID 2.0
OpenID 2.0 definiert mehrere Erweiterungen, die vom SP/RP verwendet werden können, um die Funktionsweise des Federation-SSO-Vorgangs zu beeinflussen:
OpenID-Anforderung:
mode: Zeichenfolge, die angibt, ob der IdP/OP visuell mit dem Benutzer interagieren kanncheckid_immediatelässt nicht zu, dass der IdP/OP mit dem Benutzer interagiertcheckid_setupermöglicht die Benutzerinteraktion- Standardmäßig auf
checkid_setupgesetzt
PAPE-Erweiterung:
max_auth_age: Ganzzahl, die den maximalen Zeitraum in Sekunden angibt, seit dem sich der Benutzer bei IdP authentifiziert hat. WennMaxAuthnAgegrößer ist als die Zeit, seit der sich der Benutzer zuletzt bei IdP authentifiziert hat, muss der Benutzer erneut herausgefordert werden.- OAM/SP setzt dieses Attribut auf 0, wenn der Administrator
ForceAuthnauf "true" konfiguriert hat. Andernfalls wird dieses Attribut nicht festgelegt - Standardwert fehlt
preferred_auth_policies
- Enthält eine Federation-Authentifizierungsmethode
- Element, das angibt, wie der Benutzer unter IdP herausgefordert werden soll
- Standardmäßig fehlt
- Nur in der OpenID-Anforderung angegeben, wenn der IdP/OP PAPE in XRDS unterstützt, wenn die OpenID-Discovery verwendet wird.
UI-Erweiterung
- Popup-Modus
- Boolescher Wert, der angibt, dass der Popup-Modus für das Federation-SSO aktiviert ist
- Standardmäßig fehlt
Sprachvoreinstellung
- Zeichenfolge mit der bevorzugten Sprache, die basierend auf den Sprachvoreinstellungen des Browsers festgelegt wird.
- Standardmäßig fehlt
Symbol:
- Boolescher Wert, der angibt, ob die Symbolfunktion aktiviert ist. In diesem Fall prüft der IdP/OP den SP/RP-XRDS, um zu bestimmen, wie das Symbol abgerufen wird
- Standardmäßig fehlt
- Nur in der OpenID-Anforderung angegeben, wenn der IdP/OP die UI-Erweiterung in XRDS unterstützt, wenn die OpenID-Discovery verwendet wird.
ForceAuthn und IsPassive
WLST-Befehl
OAM/SP stellt den WLST-Befehl configureIdPAuthnRequest() bereit, um Folgendes festzulegen:
ForceAuthn als boolescher Wert:
- In einer SAML 2.0-AuthnRequest ist das Feld
ForceAuthnauf "true" oder "false" gesetzt - Wenn in einer OpenID 2.0-Anforderung
ForceAuthnin der Konfiguration auf "true" gesetzt wurde, wird das Feldmax_auth_ageder PAPE-Anforderung auf 0 gesetzt. Andernfalls wirdmax_auth_agenicht festgelegt
IsPassive als boolescher Wert:
- In einer SAML 2.0-AuthnRequest ist das Feld
IsPassiveauf "true" oder "false" gesetzt - Wenn in einer OpenID 2.0-Anforderung
IsPassivein der Konfiguration auf "true" gesetzt wurde, wird das Modusfeld der OpenID-Anforderung aufcheckid_immediategesetzt, andernfalls aufcheckid_setup.
Testen
In diesem Test ist OAM/SP in einen Remote-SAML 2.0 IdP-Partner mit der OOTB-Konfiguration integriert. Wenn OAM/SP einen Federation-SSO-Ablauf startet, wird auf Basis dieses Setups die folgende SAML 2.0-AuthnRequest generiert:
<samlp:AuthnRequest
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-
POST" ID="id-
E4BOT7lwbYK56lO57dBaqGUFq01WJSjAHiSR60Q4"
Version="2.0" IssueInstant="2014-04-01T21:39:14Z"
Destination="https://acme.com/saml20/sso">
<saml:Issuer
Format="urn:oasis:names:tc:SAML:2.0:nameidformat:entity">https://sp.com
/oam/fed</saml:Issuer>
<samlp:NameIDPolicy AllowCreate="true"/> </samlp:AuthnRequest>
Konfigurieren wir OAM/SP für diesen IdP-Partner, sodass der SP die IdP benötigt, um den Benutzer erneut anzufordern, selbst wenn der Benutzer bereits authentifiziert ist:
- Geben Sie die WLST-Umgebung ein, indem Sie Folgendes ausführen:
$IAM_ORACLE_HOME/common/bin/WLST.sh - Stellen Sie eine Verbindung zum WLS-Admin-Server her:
connect() - Navigieren Sie zur Domainlaufzeitverzweigung:
domainRuntime() - Führen Sie den Befehl configureIdPAuthnRequest() aus:
configureIdPAuthnRequest(partner="AcmeIdP", forceAuthn="true") - Beenden Sie die WLST-Umgebung:
exit()
Nach den Änderungen wird die folgende SAML 2.0-AuthnRequest generiert:
<samlp:AuthnRequest ForceAuthn="true" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP- POST" ID="id- E4BOT7lwbYK56lO57dBaqGUFq01WJSjAHiSR60Q4" Version="2.0" IssueInstant="2014-04-01T21:39:14Z" Destination="https://acme.com/saml20/sso">
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameidformat:entity">https://sp.com/oam/fed</saml:Issuer>
<samlp:NameIDPolicy AllowCreate="true"/> </samlp:AuthnRequest>
Führen Sie die folgenden Vorgänge aus, um die ForceAuthn/IsPassive-Einstellungen anzuzeigen oder zu löschen:
- Geben Sie die WLST-Umgebung ein, indem Sie Folgendes ausführen:
$IAM_ORACLE_HOME/common/bin/WLST.sh - Stellen Sie eine Verbindung zum WLS-Admin-Server her:
connect() - Navigieren Sie zur Domainlaufzeitverzweigung:
domainRuntime() - Führen Sie den Befehl
configureIdPAuthnRequest()aus, um die ForceAuthn/IsPassive-Einstellungen für den PartnerconfigureIdPAuthnRequest(partner="AcmeIdP", displayOnly="true")anzuzeigen. - So löschen Sie die ForceAuthn/IsPassive-Einstellungen aus dem Partner
configureIdPAuthnRequest(partner="AcmeIdP", delete="true") - Beenden Sie die WLST-Umgebung:
exit()
Angeforderte Fed-Authentifizierungsmethode
Im Artikel "Fed Authentication Method Requests in OAM/SP" wurde erläutert, wie OAM/SP so konfiguriert werden könnte, dass beim Starten eines Federation-SSO-Vorgangs eine bestimmte Federation-Authentifizierungsmethode aus der IdP angefordert wird, indem Elemente in der SSO-Anforderungsnachricht festgelegt werden.
WLST-Befehl
Folgende OAM WLST-Befehle können verwendet werden:
-
setIdPPartnerProfileRequestAuthnMethod(), das die angeforderte Federation-Authentifizierungsmethode in einem bestimmten IdP-Partnerprofil konfiguriert und die folgenden Parameter akzeptiert:partnerProfile: Name des IdP-PartnerprofilsauthnMethod: Anzufordernde Federation-AuthentifizierungsmethodedisplayOnly: Ein optionaler Parameter, der angibt, ob die Methode die aktuell angeforderte Federation-Authentifizierungsmethode anzeigen soll, anstatt sie festzulegendelete: Ein optionaler Parameter, der angibt, ob die Methode die aktuell angeforderte Federation-Authentifizierungsmethode löschen soll, anstatt sie festzulegen
-
setIdPPartnerRequestAuthnMethod(), der den angegebenen IdP-Partnereintrag mit der angeforderten Federation-Authentifizierungsmethode konfiguriert und die folgenden Parameter akzeptiert: -
partner: Name des IdP-Partners -
authnMethod: Anzufordernde Federation-Authentifizierungsmethode -
displayOnly: Ein optionaler Parameter, der angibt, ob die Methode die aktuell angeforderte Federation-Authentifizierungsmethode anzeigen soll, anstatt sie festzulegen -
delete: Ein optionaler Parameter, der angibt, ob die Methode die aktuell angeforderte Federation-Authentifizierungsmethode löschen soll, anstatt sie festzulegen
Dies gilt für SAML 2.0- und SAML OpenID 2.0-Protokolle. Weitere Informationen finden Sie im Artikel "Fed Authentication Method Requests in OAM / SP".
Testen
In diesem Test ist OAM/SP in einen Remote-SAML 2.0 IdP-Partner mit der OOTB-Konfiguration integriert. Wenn OAM/SP einen Federation-SSO-Ablauf startet, wird auf Basis dieses Setups die folgende SAML 2.0-AuthnRequest generiert:
<samlp:AuthnRequest
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-
POST" ID="id-
E4BOT7lwbYK56lO57dBaqGUFq01WJSjAHiSR60Q4"
Version="2.0" IssueInstant="2014-04-01T21:39:14Z"
Destination="https://acme.com/saml20/sso">
<saml:Issuer
Format="urn:oasis:names:tc:SAML:2.0:nameidformat:entity">https://sp.com
/oam/fed</saml:Issuer>
<samlp:NameIDPolicy AllowCreate="true"/> </samlp:AuthnRequest>
Konfigurieren wir OAM/SP für diesen IdP-Partner, sodass der SP IdP auffordert, einen Mechanismus zu verwenden, der der Federation-Authentifizierungsmethode urn:oasis:names:tc:SAML:2.0:ac:classes:X509 zugeordnet ist, um den Benutzer zu authentifizieren:
- Geben Sie die WLST-Umgebung ein, indem Sie Folgendes ausführen:
$IAM_ORACLE_HOME/common/bin/WLST.sh - Stellen Sie eine Verbindung zum WLS-Admin-Server her:
connect() - Navigieren Sie zur Domainlaufzeitverzweigung:
domainRuntime() - Führen Sie den
setIdPPartnerRequestAuthnMethod()-Befehl aus:setIdPPartnerRequestAuthnMethod("AcmeIdP", "urn:oasis:names:tc:SAML:2.0:ac:classes:X509") - Beenden Sie die WLST-Umgebung:
exit()
Nach den Änderungen wird die folgende SAML 2.0-AuthnRequest generiert:
<samlp:AuthnRequest
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-
POST" ID="id-
E4BOT7lwbYK56lO57dBaqGUFq01WJSjAHiSR60Q4"
Version="2.0" IssueInstant="2014-04-01T21:39:14Z"
Destination="https://acme.com/saml20/sso">
<saml:Issuer
Format="urn:oasis:names:tc:SAML:2.0:nameidformat:entity">https://sp.com /oam/fed</saml:Issuer>
<samlp:NameIDPolicy AllowCreate="true"/>
<samlp:RequestedAuthnContext
Comparison="minimum">
<saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
urn:oasis:names:tc:SAML:2.0:ac:classes:X509
</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext> </samlp:AuthnRequest>
NameID-Format
Mit dem SAML 2.0-Protokoll kann der SP von IdP ein bestimmtes NameID-Format anfordern, das verwendet wird, wenn die Assertion von der IdP ausgegeben wird.
Hinweis: SAML 1.1 und OpenID 2.0 bieten keinen solchen Mechanismus.
OAM konfigurieren
Der Administrator kann OAM/SP so konfigurieren, dass ein NameID-Format im SAML 2.0 AuthnRequest angefordert wird über:
- OAM-Administrationskonsole im Partnereintrag IdP
- Der OAM WLST-Befehl
setIdPPartnerNameIDFormat(), der die IdP-Partnerkonfiguration ändert
OAM-Administrationskonsole
So konfigurieren Sie das angeforderte NameID-Format über die OAM-Administrationskonsole:
- Gehen Sie zur OAM-Administrationskonsole:
http(s)://OAM-admin-host:OAM-adminport/oamconsole - Navigieren Sie zu Identity Federation, Serviceprovideradministration.
- Öffnen Sie den IdP-Partner, den Sie ändern möchten.
- Im Dropdown-Feld "Format für Authentifizierungsanforderung
NameID" mit einem der folgenden Werte:None: DasNameID-Format ist "Standard"Email Address: DasNameID-Format wird aufurn:oasis:names:tc:SAML:1.1:nameidformat:emailAddressgesetzt.X.509 Subject: DasNameID-Format wird aufurn:oasis:names:tc:SAML:1.1:nameidformat:X509SubjectNamegesetzt.Windows Name Qualifier: DasNameID-Format wird aufurn:oasis:names:tc:SAML:1.1:nameidformat:WindowsDomainQualifiedNamegesetzt.Kerberos: DasNameID-Format wird aufurn:oasis:names:tc:SAML:2.0:nameidformat:kerberosgesetzt.Transient: DasNameID-Format wird aufurn:oasis:names:tc:SAML:2.0:nameidformat:transientgesetzt.Unspecified: DasNameID-Format wird aufurn:oasis:names:tc:SAML:1.1:nameidformat:unspecifiedgesetzt.Custom: In diesem Fall wird ein Feld angezeigt, mit dem der Administrator das benutzerdefinierteNameID-Format für die Verwendung angeben kann. DasNameID-Format wird auf das angegebene Format gesetzt- Persistent
: TheNameIDformat will be seturn:oasis:names:tc:SAML:2.0:nameidformat:persistentwe selectedEmail Address` in diesem Beispiel
- Klicken Sie auf Save.

Beschreibung der Abbildung OAM_Administration_Console.jpg
Beschreibung der Abbildung OAM Administration Console.jpg
WLST-Befehl
Führen Sie die folgenden Schritte aus, um das angeforderte NameID-Format über den OAM WLST-Befehl setIdPPartnerNameIDFormat() zu konfigurieren:
- Geben Sie die WLST-Umgebung ein, indem Sie Folgendes ausführen:
$IAM_ORACLE_HOME/common/bin/WLST.sh - Stellen Sie eine Verbindung zum WLS-Admin-Server her:
connect() - Navigieren Sie zur Domainlaufzeitverzweigung:
domainRuntime() - Führen Sie den Befehl setIdPPartnerNameIDFormat() aus:
setIdPPartnerNameIDFormat("PARTNER", "FORMAT", customFormat="CUSTOM")- Ersetzen Sie PARTNER durch den IdP-Partnernamen.
- FORMAT durch einen der folgenden Werte ersetzen:
orafed-none: Das NameID-Format wird als Standard festgelegt.orafed-emailaddress: Das NameID-Format wird aufurn:oasis:names:tc:SAML:1.1:nameidformat:emailAddressgesetzt.orafed-x509: Das NameID-Format wird aufurn:oasis:names:tc:SAML:1.1:nameidformat:X509SubjectNamegesetzt.orafed-windowsnamequalifier: Das NameID-Format wird aufurn:oasis:names:tc:SAML:1.1:nameidformat:WindowsDomainQualifiedNamegesetzt.orafed-kerberos: Das NameID-Format wird aufurn:oasis:names:tc:SAML:2.0:nameidformat:Kerberosgesetzt.orafed-transient: Das NameID-Format wird aufurn:oasis:names:tc:SAML:2.0:nameidformat:transientgesetzt.orafed-unspecified: Das NameID-Format wird aufurn:oasis:names:tc:SAML:1.1:nameidformat:unspecifiedgesetzt.orafed-custom: In diesem Fall wird ein Feld angezeigt, mit dem der Administrator das benutzerdefinierte NameID-Format angeben kann. Das NameID-Format wird auf das angegebene Format gesetztorafed-persistent: Das NameID-Format wird aufurn:oasis:names:tc:SAML:2.0:nameidformat:persistentgesetzt.customFormatmuss festgelegt werden, wenn FORMAT auforafed-customgesetzt ist. Beispiel:setIdPPartnerNameIDFormat("AcmeIdP", "orafed-emailaddress")
- Beenden Sie die WLST-Umgebung:
exit()
Testen
In diesem Test ist OAM/SP in einen Remote-SAML 2.0 IdP-Partner mit der OOTB-Konfiguration integriert. Wenn OAM/SP einen Federation-SSO-Ablauf startet, wird auf Basis dieses Setups die folgende SAML 2.0-AuthnRequest generiert:
<samlp:AuthnRequest
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-
POST" ID="id-
E4BOT7lwbYK56lO57dBaqGUFq01WJSjAHiSR60Q4"
Version="2.0" IssueInstant="2014-04-01T21:39:14Z"
Destination="https://acme.com/saml20/sso">
<saml:Issuer
Format="urn:oasis:names:tc:SAML:2.0:nameidformat:entity">https://sp.com
/oam/fed</saml:Issuer>
<samlp:NameIDPolicy AllowCreate="true"/>
</samlp:AuthnRequest>
Nach den Änderungen, die entweder über die OAM-Administrationskonsole oder über den OAM WLST-Befehl setIdPPartnerNameIDFormat() vorgenommen werden, wobei die E-Mail-Adresse als NameID-Format angefordert wird, wird die folgende SAML 2.0 AuthnRequest generiert:
<samlp:AuthnRequest ForceAuthn="false"
IsPassive="false"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-
POST" ID="id-
E4BOT7lwbYK56lO57dBaqGUFq01WJSjAHiSR60Q4"
Version="2.0" IssueInstant="2014-04-01T21:39:14Z"
Destination="https://acme.com/saml20/sso">
<saml:Issuer
Format="urn:oasis:names:tc:SAML:2.0:nameidformat:entity">https://sp.com
/oam/fed</saml:Issuer>
<samlp:NameIDPolicy
Format="urn:oasis:names:tc:SAML:1.1:nameidformat:emailAddress" AllowCreate="true"/> </samlp:AuthnRequest>
Protokoll-Binding
Die SAML 2.0-Spezifikationen definieren eine Möglichkeit für den SP, das von IdP zu verwendende Binding anzufordern, um den Benutzer mit der SAML 2.0-Assertion an den SP weiterzuleiten: Das Attribut ProtocolBinding gibt das Binding an, das von IdP verwendet werden soll. Er wird wie folgt festgelegt:
- Entweder
urn:oasis:names:tc:SAML:2.0:bindings:HTTPPOSTfür HTTP-POST - Oder
urn:oasis:names:tc:SAML:2.0:bindings:Artifactfür Artefakt
Die SAML 2.0-Spezifikationen definieren auch verschiedene Möglichkeiten, den Benutzer mit der SAML 2.0 AuthnRequest-Nachricht vom SP an IdP umzuleiten, da der SP die Nachricht senden kann:
- Entweder über HTTP-Umleitung
- Oder HTTP POST
- (Andere Bindings können theoretisch verwendet werden, wie Artefakt, aber diese werden in der Praxis nicht verwendet.)
OAM konfigurieren
OAM kann konfiguriert werden:
- Über die OAM-Administrationskonsole oder den OAM WLST-Befehl
configureSAMLBinding(), um das zu verwendende Assertion Response Binding festzulegen - Über den OAM WLST-Befehl
configureSAMLBinding()angeben, wie die SAML-AuthnRequest-Nachricht gesendet werden soll
Hinweis: Das Binding zum Senden der SAML 2.0-Nachricht AuthnRequest wird auch verwendet, um die SAML 2.0-Nachrichten
LogoutRequestundLogoutResponsezu senden.
OAM-Administrationskonsole
So konfigurieren Sie das SSO-Antwort-/Assertion Binding über die OAM-Administrationskonsole:
- Gehen Sie zur OAM-Administrationskonsole:
http(s)://OAM-admin-host:OAM-adminport/oamconsole. - Navigieren Sie zu Identity Federation, Serviceprovideradministration.
- Öffnen Sie den IdP-Partner, den Sie ändern möchten.
- Aktivieren Sie das Kontrollkästchen "HTTP POST SSO-Antwort-Binding", um IdP anzufordern, die SSO-Antwort über HTTP POST zurückzugeben. Deaktivieren Sie das Kontrollkästchen andernfalls, um das Artefakt anzufordern.
- Klicken Sie auf Speichern.

Beschreibung der Abbildung SSO_Response_Assertion_Configuration.jpg
WLST-Befehl
Um das SSO-Antwort-/Assertion-Binding sowie das AuthnRequest-Binding über den OAM WLST-Befehl configureSAMLBinding() zu konfigurieren, führen Sie die folgenden Schritte aus:
- Geben Sie die WLST-Umgebung ein, indem Sie Folgendes ausführen:
$IAM_ORACLE_HOME/common/bin/WLST.sh - Stellen Sie eine Verbindung zum WLS-Admin-Server her:
connect() - Navigieren Sie zur Domainlaufzeitverzweigung:
domainRuntime() - Führen Sie den
configureSAMLBinding()-Befehl aus:configureSAMLBinding("PARTNER", "PARTNER_TYPE", binding, ssoResponseBinding="httppost") - Ersetzen Sie PARTNER durch den Partnernamen
- Ersetzen Sie PARTNER_TYPE durch den Partnertyp (idp oder sp).
- Ersetzen Sie das Binding durch das Binding, das zum Senden der Nachrichten AuthnRequest und
LogoutRequest/LogoutResponseverwendet werden soll (in den meisten Fällen sollte es httpredirect sein; Standardwert) httppostfür HTTP-POST-Bindinghttpredirectfür HTTP-Redirect-Binding- Geben Sie optional
ssoResponseBindingan, um anzugeben, wie die SSO-Assertion zurückgesendet werden soll httppostfür HTTP-POST-Bindingartifactforfür Artefakt-Binding Ein Beispiel ist:configureSAMLBinding("AcmeIdP", "idp", "httpredirect", ssoResponseBinding="httppost")- Beenden Sie die WLST-Umgebung:
exit()
Testen
In diesem Test ist OAM/SP in einen Remote-SAML 2.0 IdP-Partner integriert, mit der OOTB-Konfiguration, die HTTP-POST von IdP anfordert, um die SSO-Assertion zu senden. Wenn OAM/SP einen Federation-SSO-Ablauf startet, wird auf Basis dieses Setups die folgende SAML 2.0-AuthnRequest generiert:
<samlp:AuthnRequest
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-
POST" ID="id-
E4BOT7lwbYK56lO57dBaqGUFq01WJSjAHiSR60Q4"
Version="2.0" IssueInstant="2014-04-01T21:39:14Z"
Destination="https://acme.com/saml20/sso">
<saml:Issuer
Format="urn:oasis:names:tc:SAML:2.0:nameidformat:entity">https://sp.com
/oam/fed</saml:Issuer>
<samlp:NameIDPolicy AllowCreate="true"/> </samlp:AuthnRequest>
Weitere Lernressourcen
Sehen Sie sich weitere Übungen unter docs.oracle.com/learn an, oder greifen Sie auf weitere kostenlose Lerninhalte im Oracle Learning-Kanal YouTube zu. Besuchen Sie außerdem education.oracle.com/learning-explorer, um Oracle Learning Explorer zu werden.
Die Produktdokumentation finden Sie im Oracle Help Center.
AuthnRequest Settings in OAM and SP
F59885-01
September 2022
Copyright © 2022, Oracle and/or its affiliates.