AuthnRequest Impostazioni in OAM e SP
In questo articolo vengono elencate le varie impostazioni OAM/SP che influiscono sulla modalità di creazione di un messaggio AuthnRequest in OAM in un flusso SSO Federation. Il messaggio AuthnRequest viene utilizzato da un SP per avviare un'operazione SSO Federation e per indicare all'indirizzo IdP la modalità di esecuzione dell'operazione:
- Modalità di richiesta di verifica dell'utente in IdP
- Indica se la richiesta di verifica deve essere eseguita all'utente in IdP, anche se esiste già una sessione in IdP per questo utente
- Formato
NameIDda richiedere nell'asserzione SAML - Quale associazione (Artifact o HTTP-POST) deve essere richiesta a IdP per inviare l'asserzione
- Profilo utilizzato da OAM/SP per inviare il messaggio AuthnRequest
Protocolli
I protocolli SAML 2.0, SAML 1.1 e OpenID 2.0 definiscono elementi messaggio e regole diversi che consentono a un amministratore di influenzare i flussi SSO Federation in modi diversi, quando l'SP attiva un'operazione SSO:
- SAML 2.0 consente una personalizzazione estesa tramite il messaggio AuthnRequest
- SAML 1.1 non consente alcuna personalizzazione, poiché le specifiche non definiscono un messaggio di richiesta di autenticazione
- OpenID 2.0 consente alcune personalizzazioni, principalmente tramite le estensioni OpenID 2.0 come PAPE o UI
SAML 2.0
OAM/SP consente la personalizzazione del messaggio AuthnRequest SAML 2.0 per i seguenti elementi:
ForceAuthn:
- Valore booleano che indica se IdP deve forzare la nuova autenticazione dell'utente anche se l'utente dispone ancora di una sessione valida
- L'impostazione predefinita è false
IsPassive
- Valore booleano che indica se IdP è autorizzato a interagire con l'utente nell'ambito dell'operazione SSO Federation.
- Se false, l'operazione SSO Federation potrebbe generare un errore con il codice di errore NoPassive poiché IdP non è in grado di identificare l'utente.
- L'impostazione predefinita è false
RequestedAuthnContext
- Elemento che indica la modalità di richiesta di verifica dell'utente in IdP
- Se il provider di servizi richiede un metodo di autenticazione federativo sconosciuto a IdP o per il quale non è configurato IdP, il flusso SSO federativo genererà un errore con il codice di errore
NoAuthnContext - Per impostazione predefinita mancante
NameIDPolicy
- Elemento che indica il formato
NameIDche IdP deve includere nell'asserzione SAML - Se il provider di servizi richiede un formato
NameIDsconosciuto a IdP o per il quale non è configurato IdP, il flusso SSO Federation genererà un errore con il codice di erroreInvalidNameIDPolicy - Se mancante, IdP in genere utilizza il formato NameID predefinito configurato per questo partner SP all'indirizzo IdP
- Per impostazione predefinita mancante
ProtocolBinding
- Elemento che indica quale associazione SAML deve essere utilizzata da IdP per reindirizzare l'utente all'SP con l'asserzione SAML
- Imposta su artifact o HTTP-POST
- Per impostazione predefinita, è impostato su HTTP-POST
OAM/SP consente inoltre all'amministratore di configurare il server per:
- Impostare l'associazione che deve essere utilizzata da OAM/SP per reindirizzare l'utente a IdP con il messaggio AuthnRequest SAML 2.0:
- Reindirizzamento o HTTP-POST
- L'impostazione predefinita è Reindirizza
- Impostare l'associazione che deve essere utilizzata da OAM/SP per reindirizzare l'utente a IdP durante il logout con i messaggi di logout SAML 2.0:
- Reindirizzamento o HTTP-POST
- L'impostazione predefinita è Reindirizza
SAML 1.1
Le specifiche SAML 1.1 non definiscono un messaggio per l'SP da inviare a IdP quando viene avviata un'operazione SSO Federation. Pertanto, non è possibile configurare OAM/SP su come influenzare l'avvio del flusso SSO Federation.
OpenID 2.0
OpenID 2.0 definisce diverse estensioni che possono essere utilizzate da SP/RP per influenzare l'esecuzione dell'operazione SSO Federation:
Richiesta OpenID:
mode: stringa che indica se IdP/OP può interagire visivamente con l'utentecheckid_immediatenon consente a IdP/OP di interagire con l'utentecheckid_setupconsente l'interazione dell'utente- Per impostazione predefinita, impostare
checkid_setup
Estensione PAPE:
max_auth_age: numero intero che indica in secondi il periodo di tempo massimo dal momento in cui l'utente ha eseguito l'autenticazione in IdP. SeMaxAuthnAgeè più grande del tempo trascorso dall'ultima autenticazione dell'utente in IdP, l'utente deve essere ricontattato.- OAM/SP imposta questo attributo su 0 se l'amministratore ha configurato
ForceAuthnsu true, altrimenti l'attributo non verrà impostato - Valore predefinito mancante
preferred_auth_policies
- Contiene un metodo di autenticazione Federation
- Elemento che indica la modalità di richiesta di verifica dell'utente in IdP
- Per impostazione predefinita mancante
- Specificato solo nella richiesta OpenID se IdP/OP supporta PAPE in XRDS, se viene utilizzata la ricerca automatica OpenID.
Estensione interfaccia utente
- Modalità popup
- Valore booleano che indica che la modalità popup è abilitata per SSO federazione
- Per impostazione predefinita mancante
Preferenza lingua
- Stringa contenente la lingua preferita, impostata in base alle preferenze della lingua del browser.
- Per impostazione predefinita mancante
Icona:
- Valore booleano che indica se la funzione icona è abilitata. In questo caso, l'IdP/OP esamina l'XRDS SP/RP per determinare come recuperare l'icona
- Per impostazione predefinita mancante
- Specificato solo nella richiesta OpenID se IdP/OP supporta l'estensione dell'interfaccia utente in XRDS, se viene utilizzata la ricerca automatica OpenID.
ForceAuthn e IsPassive
Comando WLST
OAM/SP fornisce il comando WLST configureIdPAuthnRequest() per impostare:
ForceAuthn come valore booleano:
- In un AuthnRequest SAML 2.0, il campo
ForceAuthnè impostato su true o false - In una richiesta OpenID 2.0, se
ForceAuthnnella configurazione è stato impostato su true, il campomax_auth_agedella richiesta PAPE è impostato su 0, altrimentimax_auth_agenon verrà impostato
IsPassive come valore booleano:
- In un AuthnRequest SAML 2.0, il campo
IsPassiveè impostato su true o false - In una richiesta OpenID 2.0, se
IsPassivenella configurazione è stato impostato su true, il campo della modalità della richiesta OpenID è impostato sucheckid_immediate, altrimenti è impostato sucheckid_setup
Test
In questo test, OAM/SP è integrato con un partner SAML 2.0 IdP remoto, con la configurazione OOTB. In base a questa impostazione, quando OAM/SP avvia un flusso SSO Federation, viene generato il seguente SAML 2.0 AuthnRequest:
<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>
Configurare OAM/SP per il partner IdP in modo che il provider di servizi richieda a IdP di eseguire di nuovo la verifica dell'utente, anche se l'utente è già autenticato:
- Immettere l'ambiente WLST eseguendo:
$IAM_ORACLE_HOME/common/bin/wlst.sh - Connetti al server di amministrazione WLS:
connect() - Passare alla diramazione Runtime dominio:
domainRuntime() - Eseguire il comando configureIdPAuthnRequest():
configureIdPAuthnRequest(partner="AcmeIdP", forceAuthn="true") - Uscire dall'ambiente WLST:
exit()
Dopo le modifiche, viene generato il seguente SAML 2.0 AuthnRequest:
<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>
Per visualizzare o eliminare le impostazioni ForceAuthn/IsPassive, effettuare le operazioni riportate di seguito.
- Immettere l'ambiente WLST eseguendo:
$IAM_ORACLE_HOME/common/bin/wlst.sh - Connetti al server di amministrazione WLS:
connect() - Passare alla diramazione Runtime dominio:
domainRuntime() - Eseguire il comando
configureIdPAuthnRequest()per visualizzare le impostazioni di ForceAuthn/IsPassive sul partnerconfigureIdPAuthnRequest(partner="AcmeIdP", displayOnly="true") - Per eliminare le impostazioni ForceAuthn/IsPassive dal partner
configureIdPAuthnRequest(partner="AcmeIdP", delete="true") - Uscire dall'ambiente WLST:
exit()
Metodo di autenticazione federale richiesto
Nell'articolo "Fed Authentication Method Requests in OAM / SP" si è discusso di come OAM/SP potrebbe essere configurato per richiedere uno specifico metodo di autenticazione Federation dal IdP quando si avvia un'operazione SSO Federation, impostando gli elementi nel messaggio di richiesta SSO.
Comando WLST
I comandi WLST OAM che possono essere utilizzati sono:
-
setIdPPartnerProfileRequestAuthnMethod()che configura il metodo di autenticazione federativo richiesto in un profilo partner IdP specifico e accetta i seguenti parametri:partnerProfile: nome del profilo partner IdPauthnMethod: il metodo di autenticazione Federation da richiederedisplayOnly: parametro facoltativo che indica se il metodo deve visualizzare il metodo di autenticazione federativa richiesto corrente anziché impostarlodelete: parametro facoltativo che indica se il metodo deve eliminare il metodo di autenticazione federativa richiesto corrente anziché impostarlo
-
setIdPPartnerRequestAuthnMethod()che configura la voce partner IdP specificata con il metodo di autenticazione Federation richiesto e accetta i parametri riportati di seguito. -
partner: nome del partner IdP -
authnMethod: il metodo di autenticazione Federation da richiedere -
displayOnly: parametro facoltativo che indica se il metodo deve visualizzare il metodo di autenticazione federativa richiesto corrente anziché impostarlo -
delete: parametro facoltativo che indica se il metodo deve eliminare il metodo di autenticazione federativa richiesto corrente anziché impostarlo
Ciò è valido per i protocolli SAML 2.0 e OpenID 2.0. Per ulteriori informazioni, vedere l'articolo "Fed Authentication Method Requests in OAM / SP".
Test
In questo test, OAM/SP è integrato con un partner SAML 2.0 IdP remoto, con la configurazione OOTB. In base a questa impostazione, quando OAM/SP avvia un flusso SSO Federation, viene generato il seguente SAML 2.0 AuthnRequest:
<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>
Configurare OAM/SP per il partner IdP in modo che il provider di servizi richieda a IdP di utilizzare un meccanismo mappato al metodo di autenticazione Federation urn:oasis:names:tc:SAML:2.0:ac:classes:X509 per autenticare l'utente.
- Immettere l'ambiente WLST eseguendo:
$IAM_ORACLE_HOME/common/bin/wlst.sh - Connetti al server di amministrazione WLS:
connect() - Passare alla diramazione Runtime dominio:
domainRuntime() - Eseguire il comando
setIdPPartnerRequestAuthnMethod():setIdPPartnerRequestAuthnMethod("AcmeIdP", "urn:oasis:names:tc:SAML:2.0:ac:classes:X509") - Uscire dall'ambiente WLST:
exit()
Dopo le modifiche, viene generato il seguente SAML 2.0 AuthnRequest:
<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>
Formato NameID
Il protocollo SAML 2.0 consente all'SP di richiedere da IdP un formato NameID specifico da utilizzare quando l'asserzione viene emessa da IdP.
Nota: SAML 1.1 e OpenID 2.0 non forniscono un meccanismo di questo tipo
Configurazione di OAM
L'amministratore può configurare OAM/SP per richiedere un formato NameID in SAML 2.0 AuthnRequest tramite:
- La console di amministrazione OAM, nella voce Partner IdP
- Il comando OAM WLST
setIdPPartnerNameIDFormat()che modifica la configurazione del partner IdP
Console di amministrazione di OAM
Per configurare il formato NameID richiesto tramite la console di amministrazione OAM, effettuare le operazioni riportate di seguito.
- Andare alla console di amministrazione OAM:
http(s)://oam-admin-host:oam-adminport/oamconsole - Passare a Identity Federation, Amministrazione provider di servizi
- Apri il partner IdP che desideri modificare
- Nella casella a discesa Formato richiesta di autenticazione
NameIDcon uno dei valori riportati di seguito.None: il formatoNameIDè impostato su PredefinitoEmail Address: il formatoNameIDverrà impostato suurn:oasis:names:tc:SAML:1.1:nameidformat:emailAddressX.509 Subject: il formatoNameIDverrà impostato suurn:oasis:names:tc:SAML:1.1:nameidformat:X509SubjectNameWindows Name Qualifier: il formatoNameIDverrà impostato suurn:oasis:names:tc:SAML:1.1:nameidformat:WindowsDomainQualifiedNameKerberos: il formatoNameIDverrà impostato suurn:oasis:names:tc:SAML:2.0:nameidformat:kerberosTransient: il formatoNameIDverrà impostato suurn:oasis:names:tc:SAML:2.0:nameidformat:transientUnspecified: il formatoNameIDverrà impostato suurn:oasis:names:tc:SAML:1.1:nameidformat:unspecifiedCustom: in questo caso viene visualizzato un campo che consente all'amministratore di indicare il formatoNameIDpersonalizzato da utilizzare. Il formatoNameIDverrà impostato sul formato specificato.- Persistent
: TheNameIDformat will be seturn:oasis:names:tc:SAML:2.0:nameidformat:persistentwe selectedIndirizzo e-mail` in questo esempio
- Fare clic su Salva

Descrizione dell'immagine OAM_Administration_Console.jpg
Descrizione dell'immagine OAM Administration Console.jpg
Comando WLST
Per configurare il formato NameID richiesto tramite il comando OAM WLST setIdPPartnerNameIDFormat(), attenersi alla procedura riportata di seguito.
- Immettere l'ambiente WLST eseguendo:
$IAM_ORACLE_HOME/common/bin/wlst.sh - Connetti al server di amministrazione WLS:
connect() - Passare alla diramazione Runtime dominio:
domainRuntime() - Eseguire il comando setIdPPartnerNameIDFormat():
setIdPPartnerNameIDFormat("PARTNER", "FORMAT", customFormat="CUSTOM")- Sostituire PARTNER con il nome partner IdP
- Sostituire FORMAT con uno dei seguenti elementi:
orafed-none: il formato NameID verrà impostato come predefinitoorafed-emailaddress: il formato NameID verrà impostato suurn:oasis:names:tc:SAML:1.1:nameidformat:emailAddressorafed-x509: il formato NameID verrà impostato suurn:oasis:names:tc:SAML:1.1:nameidformat:X509SubjectNameorafed-windowsnamequalifier: il formato NameID verrà impostato suurn:oasis:names:tc:SAML:1.1:nameidformat:WindowsDomainQualifiedNameorafed-kerberos: il formato NameID verrà impostato suurn:oasis:names:tc:SAML:2.0:nameidformat:Kerberosorafed-transient: il formato NameID verrà impostato suurn:oasis:names:tc:SAML:2.0:nameidformat:transientorafed-unspecified: il formato NameID verrà impostato suurn:oasis:names:tc:SAML:1.1:nameidformat:unspecifiedorafed-custom: in questo caso viene visualizzato un campo che consente all'amministratore di indicare il formato NameID personalizzato da utilizzare. Il formato NameID verrà impostato sul formato specificatoorafed-persistent: il formato NameID verrà impostato suurn:oasis:names:tc:SAML:2.0:nameidformat:persistentcustomFormatdovrà essere impostato se FORMAT è impostato suorafed-customUn esempio è:setIdPPartnerNameIDFormat("AcmeIdP", "orafed-emailaddress")
- Uscire dall'ambiente WLST:
exit()
Test
In questo test, OAM/SP è integrato con un partner SAML 2.0 IdP remoto, con la configurazione OOTB. In base a questa impostazione, quando OAM/SP avvia un flusso SSO Federation, viene generato il seguente SAML 2.0 AuthnRequest:
<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>
Dopo l'esecuzione delle modifiche mediante la console di amministrazione OAM o tramite il comando OAM WLST setIdPPartnerNameIDFormat() in cui è richiesto l'indirizzo e-mail come formato NameID, viene generato il seguente SAML 2.0 AuthnRequest:
<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>
Associazione di protocollo
Le specifiche SAML 2.0 definiscono un modo in cui l'SP può richiedere l'associazione che deve essere utilizzata da IdP per reindirizzare l'utente all'SP con l'asserzione SAML 2.0: l'attributo ProtocolBinding indica l'associazione che IdP deve utilizzare. È impostato su:
urn:oasis:names:tc:SAML:2.0:bindings:HTTPPOSTper HTTP-POST- Oppure
urn:oasis:names:tc:SAML:2.0:bindings:Artifactper l'artifact
Le specifiche SAML 2.0 definiscono inoltre modi diversi per reindirizzare l'utente dall'SP al IdP con il messaggio SAML 2.0 AuthnRequest, in quanto l'SP può inviare il messaggio:
- Tramite reindirizzamento HTTP
- Oppure POST HTTP
- (È possibile utilizzare teoricamente altre associazioni, ad esempio Artifact, ma queste non vengono utilizzate nella pratica)
Configurazione di OAM
È possibile configurare OAM:
- Tramite la console di amministrazione OAM o il comando WLST
configureSAMLBinding()OAM per impostare l'associazione della risposta di asserzione da utilizzare - Tramite il comando WLST
configureSAMLBinding()OAM per indicare la modalità di invio del messaggio SAML AuthnRequest
Nota: per inviare i messaggi
LogoutRequesteLogoutResponseSAML 2.0 verrà utilizzata anche l'associazione per l'invio del messaggio AuthnRequest SAML 2.0.
Console di amministrazione di OAM
Per configurare l'associazione di risposte/asserzioni SSO tramite la console di amministrazione OAM, effettuare le operazioni riportate di seguito.
- Andare alla console di amministrazione OAM:
http(s)://oam-admin-host:oam-adminport/oamconsole. - Passare a Identity Federation, Service Provider Administration.
- Aprire il partner IdP che si desidera modificare.
- Selezionare la casella "Associazione risposta SSO POST HTTP" per richiedere a IdP di restituire la risposta SSO tramite POST HTTP, altrimenti deselezionarla per richiedere l'artifact.
- Fare clic su Salva.

Descrizione dell'immagine SSO_Response_Assertion_Configuration.jpg
Comando WLST
Per configurare l'associazione risposta/asserzione SSO e l'associazione AuthnRequest tramite il comando OAM WLST configureSAMLBinding(), effettuare le operazioni riportate di seguito.
- Immettere l'ambiente WLST eseguendo:
$IAM_ORACLE_HOME/common/bin/wlst.sh - Connetti al server di amministrazione WLS:
connect() - Passare alla diramazione Runtime dominio:
domainRuntime() - Eseguire il comando
configureSAMLBinding():configureSAMLBinding("PARTNER", "PARTNER_TYPE", binding, ssoResponseBinding="httppost") - Sostituisci PARTNER con nome partner
- Sostituire PARTNER_TYPE con il tipo di partner (idp o sp)
- Sostituire l'associazione con l'associazione da utilizzare per inviare i messaggi AuthnRequest e
LogoutRequest/LogoutResponse(dovrebbe essere httpredirect nella maggior parte dei casi; predefinito) httppostper l'associazione HTTP-POSThttpredirectper l'associazione HTTP-reindirizzamento- Specificare facoltativamente
ssoResponseBindingper indicare come deve essere inviata l'asserzione SSO httppostper l'associazione HTTP-POSTartifactforper l'associazione dell'artifact Un esempio èconfigureSAMLBinding("AcmeIdP", "idp", "httpredirect", ssoResponseBinding="httppost")- Uscire dall'ambiente WLST:
exit()
Test
In questo test, OAM/SP è integrato con un partner SAML 2.0 IdP remoto, con la configurazione OOTB che richiede HTTP-POST da IdP per inviare l'asserzione SSO. In base a questa impostazione, quando OAM/SP avvia un flusso SSO Federation, viene generato il seguente SAML 2.0 AuthnRequest:
<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>
Altre risorse di apprendimento
Esplora altri laboratori su docs.oracle.com/learn o visita altri contenuti di formazione gratuiti sul canale Oracle Learning YouTube. Inoltre, visitare education.oracle.com/learning-explorer per diventare un Oracle Learning Explorer.
Per la documentazione sul prodotto, visitare Oracle Help Center.
AuthnRequest Settings in OAM and SP
F59885-01
September 2022
Copyright © 2022, Oracle and/or its affiliates.