AuthnRequest Paramètres dans OAM et SP
Cet article répertorie les différents paramètres OAM/SP qui affectent la façon dont un message AuthnRequest est créé dans OAM dans un flux SSO de fédération. Le message AuthnRequest est utilisé par un SP pour démarrer une opération SSO de fédération et pour indiquer à IdP comment l'opération doit être exécutée :
- Comment l'utilisateur doit être interrogé sur IdP
 - Indique si l'utilisateur doit faire l'objet d'une question de vérification dans IdP, même si une session existe déjà dans IdP pour cet utilisateur
 - Quel format 
NameIDdoit être demandé dans l'assertion SAML ? - Liaison (Artifact ou HTTP-POST) à demander à IdP pour envoyer l'assertion
 - Profil qui doit être utilisé par OAM/SP pour envoyer le message AuthnRequest
 
Protocoles
Les protocoles SAML 2.0, SAML 1.1 et OpenID 2.0 définissent différents éléments de message et règles qui permettent à un administrateur d'influencer les flux SSO de fédération de différentes manières, lorsque le fournisseur de services déclenche une opération SSO :
- SAML 2.0 permet une personnalisation étendue via le message AuthnRequest
 - SAML 1.1 n'autorise aucune personnalisation car les spécifications ne définissent pas de message de demande d'authentification
 - OpenID 2.0 permet une certaine personnalisation, principalement via les extensions OpenID 2.0 telles que PAPE ou UI
 
SAML 2.0
OAM/SP permet de personnaliser le message AuthnRequest SAML 2.0 pour les éléments suivants :
ForceAuthn :
- Valeur booléenne indiquant si IdP doit forcer l'utilisateur à se réauthentifier, même si l'utilisateur dispose encore d'une session valide
 - La valeur par défaut est false.
 
IsPassive
- Valeur booléenne indiquant si IdP est autorisé à interagir avec l'utilisateur dans le cadre de l'opération SSO de fédération.
 - Si la valeur est False, l'opération SSO de fédération peut entraîner un échec avec le code d'erreur NoPassive, car IdP ne peut pas identifier l'utilisateur
 - La valeur par défaut est false.
 
RequestedAuthnContext
- Elément indiquant comment l'utilisateur doit faire l'objet d'une question de vérification dans IdP
 - Si le fournisseur de services demande une méthode d'authentification de fédération inconnue de IdP ou pour laquelle IdP n'est pas configuré, le flux SSO de fédération entraîne un échec avec le code d'erreur 
NoAuthnContext - Par défaut manquant
 
NameIDPolicy
- Elément indiquant le format 
NameIDque IdP doit inclure dans l'assertion SAML - Si le fournisseur de services demande un format 
NameIDinconnu de IdP ou pour lequel IdP n'est pas configuré, le flux SSO de fédération entraîne un échec avec le code d'erreurInvalidNameIDPolicy - En cas d'absence, IdP utilise généralement le format NameID par défaut configuré pour ce partenaire de SP à l'adresse IdP
 - Par défaut manquant
 
ProtocolBinding
- Elément indiquant quelle liaison SAML doit être utilisée par IdP pour rediriger l'utilisateur vers le fournisseur de services avec l'assertion SAML
 - Définie sur Artifact ou HTTP-POST
 - Par défaut, il est défini sur HTTP-POST.
 
OAM/SP permet également à l'administrateur de configurer le serveur pour :
- Définissez la liaison à utiliser par OAM/SP pour rediriger l'utilisateur vers IdP avec le message SAML 2.0 AuthnRequest :
 - Redirection ou HTTP-POST
 - Par défaut, redirection
 - Définissez la liaison à utiliser par OAM/SP pour rediriger l'utilisateur vers IdP lors de la déconnexion avec les messages de déconnexion SAML 2.0 :
 - Redirection ou HTTP-POST
 - Par défaut, redirection
 
SAML 1.1
Les SPécifications SAML 1.1 ne définissent pas de message que le fournisseur de services doit envoyer à IdP lorsqu'une opération SSO de fédération est démarrée. Par conséquent, il n'est pas possible de configurer OAM/SP pour déterminer comment affecter le démarrage du flux SSO de fédération.
OpenID 2.0
OpenID 2.0 définit plusieurs extensions qui peuvent être utilisées par le fournisseur de services/RP pour affecter la façon dont l'opération SSO de fédération a lieu :
Demande OpenID :
mode: chaîne indiquant si le fournisseur d'identités/OP peut interagir visuellement avec l'utilisateurcheckid_immediaten'autorise pas le fournisseur d'identités/OP à interagir avec l'utilisateurcheckid_setuppermet l'interaction utilisateur- La valeur par défaut est 
checkid_setup. 
Extension PAPE :
max_auth_age: entier indiquant en secondes la durée maximale depuis laquelle l'utilisateur s'est authentifié auprès de IdP. Si la valeur deMaxAuthnAgeest supérieure à la durée écoulée depuis la dernière authentification de l'utilisateur au niveau de IdP, l'utilisateur doit faire l'objet d'un nouveau contrôle.- OAM/SP définit cet attribut sur 0 si l'administrateur a configuré 
ForceAuthnsur True, sinon cet attribut ne sera pas défini - Valeur par défaut manquante
 
preferred_auth_policies
- Contient une méthode d'authentification de fédération
 - Elément indiquant comment l'utilisateur doit faire l'objet d'une question de vérification dans IdP
 - Par défaut manquant
 - Spécifié uniquement dans la demande OpenID si le fournisseur d'identités/OP prend en charge PAPE dans XRDS, si le repérage OpenID est utilisé.
 
Extension d'interface utilisateur
- Mode contextuel
 - Valeur booléenne indiquant que le mode contextuel est activé pour l'accès avec connexion unique (SSO) Federation
 - Par défaut manquant
 
Préférence de langue
- Chaîne contenant la langue préférée, définie selon les préférences de langue du navigateur.
 - Par défaut manquant
 
Icône :
- Valeur booléenne indiquant si la fonctionnalité d'icône est activée. Dans ce cas, l'IdP/OP consulte le XRDS du SP/RP pour déterminer comment récupérer l'icône
 - Par défaut manquant
 - Spécifié uniquement dans la demande OpenID si le fournisseur d'identités/OP prend en charge l'extension d'interface utilisateur dans XRDS, si le repérage OpenID est utilisé.
 
ForceAuthn et IsPassive
Commande WLST
OAM/SP fournit la commande WLST configureIdPAuthnRequest() permettant de définir les éléments suivants :
ForceAuthn en tant que booléen :
- Dans un fichier AuthnRequest SAML 2.0, le champ 
ForceAuthnest défini sur True ou False - Dans une demande OpenID 2.0, si 
ForceAuthndans la configuration a été défini sur True, le champmax_auth_agede la demande PAPE est défini sur 0, sinonmax_auth_agene sera pas défini 
IsPassive en tant que booléen :
- Dans un fichier AuthnRequest SAML 2.0, le champ 
IsPassiveest défini sur True ou False - Dans une demande OpenID 2.0, si 
IsPassivedans la configuration a été défini sur True, le champ de mode de la demande OpenID est défini surcheckid_immediate, sinon surcheckid_setup 
Tester
Dans ce test, OAM/SP est intégré à un partenaire SAML 2.0 IdP distant, avec la configuration OOTB. Selon cette configuration, lorsqu'OAM/SP démarre un flux SSO de fédération, le fichier AuthnRequest SAML 2.0 suivant est généré :
<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>
Configurons OAM/SP pour ce partenaire IdP, de sorte que le SP exige que IdP réponde à l'utilisateur, même si l'utilisateur est déjà authentifié :
- Entrez dans l'environnement WLST en exécutant :
$IAM_ORACLE_HOME/common/bin/wlst.sh - Connectez-vous au serveur d'administration WLS : 
connect() - Accédez au branchement d'exécution de domaine : 
domainRuntime() - Exécutez la commande configureIdPAuthnRequest() : 
configureIdPAuthnRequest(partner="AcmeIdP", forceAuthn="true") - Quittez l'environnement WLST : 
exit() 
Après les modifications, le fichier AuthnRequest SAML 2.0 suivant est généré :
<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>
Pour afficher ou supprimer les paramètres ForceAuthn/IsPassive, effectuez les opérations suivantes :
- Entrez dans l'environnement WLST en exécutant : 
$IAM_ORACLE_HOME/common/bin/wlst.sh - Connectez-vous au serveur d'administration WLS : 
connect() - Accédez au branchement d'exécution de domaine : 
domainRuntime() - Exécutez la commande 
configureIdPAuthnRequest()pour afficher les paramètres ForceAuthn/IsPassive sur le partenaireconfigureIdPAuthnRequest(partner="AcmeIdP", displayOnly="true") - Pour supprimer les paramètres ForceAuthn/IsPassive du partenaire 
configureIdPAuthnRequest(partner="AcmeIdP", delete="true") - Quittez l'environnement WLST : 
exit() 
Méthode Fed Authn demandée
Dans l'article "Fed Authentication Method Requests in OAM / SP", nous avons expliqué comment OAM/SP peut être configuré pour demander une méthode d'authentification de fédération spécifique à partir de IdP lors du démarrage d'une opération SSO de fédération, en définissant des éléments dans le message de demande SSO.
Commande WLST
Les commandes WLST OAM pouvant être utilisées sont les suivantes :
- 
    
setIdPPartnerProfileRequestAuthnMethod(), qui configure la méthode d'authentification de fédération demandée dans un profil de partenaire IdP spécifique et accepte les paramètres suivants :partnerProfile: nom du profil de partenaire IdPauthnMethod: méthode d'authentification de fédération à demanderdisplayOnly: paramètre facultatif indiquant si la méthode doit afficher la méthode d'authentification de fédération demandée en cours au lieu de la définirdelete: paramètre facultatif indiquant si la méthode doit supprimer la méthode d'authentification de fédération demandée en cours au lieu de la définir
 - 
    
setIdPPartnerRequestAuthnMethod(), qui configure l'entrée de partenaire IdP spécifiée avec la méthode d'authentification de fédération demandée et accepte les paramètres suivants : - 
    
partner: nom du partenaire IdP - 
    
authnMethod: méthode d'authentification de fédération à demander - 
    
displayOnly: paramètre facultatif indiquant si la méthode doit afficher la méthode d'authentification de fédération demandée en cours au lieu de la définir - 
    
delete: paramètre facultatif indiquant si la méthode doit supprimer la méthode d'authentification de fédération demandée en cours au lieu de la définir 
Cela s'applique aux protocoles SAML 2.0 et OpenID 2.0. Pour plus d'informations, reportez-vous à l'article "Fed Authentication Method Requests in OAM / SP".
Tester
Dans ce test, OAM/SP est intégré à un partenaire SAML 2.0 IdP distant, avec la configuration OOTB. Selon cette configuration, lorsqu'OAM/SP démarre un flux SSO de fédération, le fichier AuthnRequest SAML 2.0 suivant est généré :
<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>
Configurons OAM/SP pour ce partenaire IdP afin que le fournisseur de services demande à IdP d'utiliser un mécanisme mis en correspondance avec la méthode d'authentification de fédération urn:oasis:names:tc:SAML:2.0:ac:classes:X509 pour authentifier l'utilisateur :
- Entrez dans l'environnement WLST en exécutant : 
$IAM_ORACLE_HOME/common/bin/wlst.sh - Connectez-vous au serveur d'administration WLS : 
connect() - Accédez au branchement d'exécution de domaine : 
domainRuntime() - Exécutez la commande 
setIdPPartnerRequestAuthnMethod():setIdPPartnerRequestAuthnMethod("AcmeIdP", "urn:oasis:names:tc:SAML:2.0:ac:classes:X509") - Quittez l'environnement WLST : 
exit() 
Après les modifications, le fichier AuthnRequest SAML 2.0 suivant est généré :
<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>
Format de NameID
Le protocole SAML 2.0 permet au fournisseur de services de demander à partir de IdP un format NameID SPécifique à utiliser lorsque l'assertion est émise par IdP.
Remarque : SAML 1.1 et OpenID 2.0 ne fournissent pas un tel mécanisme.
Configuration d'OAM
L'administrateur peut configurer OAM/SP pour demander un format NameID dans SAML 2.0 AuthnRequest via :
- Console d'administration OAM, dans l'entrée Partner IdP
 - Commande OAM WLST 
setIdPPartnerNameIDFormat()qui modifie la configuration du partenaire IdP 
Console d'administration OAM
Pour configurer le format NameID demandé via la console d'administration OAM, procédez comme suit :
- Accédez à la console d'administration OAM : 
http(s)://oam-admin-host:oam-adminport/oamconsole - Accédez à Fédération d'identités, Administration de fournisseur de services
 - Ouvrez le partenaire IdP que vous souhaitez modifier
 - Dans la liste déroulante Format de la demande d'authentification 
NameID, entrez l'une des valeurs suivantes :None: le formatNameIDest défini par défautEmail Address: le formatNameIDsera défini sururn:oasis:names:tc:SAML:1.1:nameidformat:emailAddressX.509 Subject: le formatNameIDsera défini sururn:oasis:names:tc:SAML:1.1:nameidformat:X509SubjectNameWindows Name Qualifier: le formatNameIDsera défini sururn:oasis:names:tc:SAML:1.1:nameidformat:WindowsDomainQualifiedNameKerberos: le formatNameIDsera défini sururn:oasis:names:tc:SAML:2.0:nameidformat:kerberosTransient: le formatNameIDsera défini sururn:oasis:names:tc:SAML:2.0:nameidformat:transientUnspecified: le formatNameIDsera défini sururn:oasis:names:tc:SAML:1.1:nameidformat:unspecifiedCustom: dans ce cas, un champ apparaît, permettant à l'administrateur d'indiquer le format personnaliséNameIDà utiliser. Le formatNameIDsera défini sur le format spécifié- Persistent
: TheNameIDformat will be seturn:oasis:names:tc:SAML :2.0 :nameidformat:persistentwe selectedEmail Address dans cet exemple 
 - Cliquez sur Enregistrer.
 

Description de l'image OAM_Administration_Console.jpg
Description de l'illustration Administration OAM Console.jpg
Commande WLST
Pour configurer le format NameID demandé via la commande OAM WLST setIdPPartnerNameIDFormat(), procédez comme suit :
- Entrez dans l'environnement WLST en exécutant : 
$IAM_ORACLE_HOME/common/bin/wlst.sh - Connectez-vous au serveur d'administration WLS : 
connect() - Accédez au branchement d'exécution de domaine : 
domainRuntime() - Exécutez la commande setIdPPartnerNameIDFormat() : 
setIdPPartnerNameIDFormat("PARTNER", "FORMAT", customFormat="CUSTOM")- Remplacez PARTNER par le nom de partenaire IdP
 - Remplacez FORMAT par l'un des éléments suivants :
 orafed-none: le format NameID sera défini comme valeur par défautorafed-emailaddress: le format NameID sera défini sururn:oasis:names:tc:SAML:1.1:nameidformat:emailAddressorafed-x509: le format NameID sera défini sururn:oasis:names:tc:SAML:1.1:nameidformat:X509SubjectNameorafed-windowsnamequalifier: le format NameID sera défini sururn:oasis:names:tc:SAML:1.1:nameidformat:WindowsDomainQualifiedNameorafed-kerberos: le format NameID sera défini sururn:oasis:names:tc:SAML:2.0:nameidformat:Kerberosorafed-transient: le format NameID sera défini sururn:oasis:names:tc:SAML:2.0:nameidformat:transientorafed-unspecified: le format NameID sera défini sururn:oasis:names:tc:SAML:1.1:nameidformat:unspecifiedorafed-custom: dans ce cas, un champ apparaît pour permettre à l'administrateur d'indiquer le format personnalisé NameID à utiliser. Le format NameID sera défini sur le format indiquéorafed-persistent: le format NameID sera défini sururn:oasis:names:tc:SAML:2.0:nameidformat:persistentcustomFormatdoit être défini si FORMAT est défini surorafed-customExemple :setIdPPartnerNameIDFormat("AcmeIdP", "orafed-emailaddress")
 - Quittez l'environnement WLST : 
exit() 
Tester
Dans ce test, OAM/SP est intégré à un partenaire SAML 2.0 IdP distant, avec la configuration OOTB. Selon cette configuration, lorsqu'OAM/SP démarre un flux SSO de fédération, le fichier AuthnRequest SAML 2.0 suivant est généré :
<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>
Une fois les modifications effectuées via la console d'administration OAM ou la commande OAM WLST setIdPPartnerNameIDFormat() où l'adresse électronique est demandée au format NameID, le SAML 2.0 AuthnRequest suivant est généré :
<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>
Liaison de protocole
Les SPécifications SAML 2.0 définissent un moyen pour le fournisseur de services de demander quelle liaison doit être utilisée par IdP pour rediriger l'utilisateur vers le fournisseur de services avec l'assertion SAML 2.0 : l'attribut ProtocolBinding indique la liaison que IdP doit utiliser. Elle est définie sur :
urn:oasis:names:tc:SAML:2.0:bindings:HTTPPOSTpour HTTP-POST- Ou 
urn:oasis:names:tc:SAML:2.0:bindings:Artifactpour l'artefact 
Les SPécifications SAML 2.0 définissent également différentes manières de rediriger l'utilisateur du fournisseur de services vers IdP avec le message SAML 2.0 AuthnRequest, car le fournisseur de services peut envoyer le message :
- L'un ou l'autre via le réacheminement HTTP
 - Ou HTTP POST
 - (D'autres liaisons peuvent théoriquement être utilisées comme Artifact, mais elles ne sont pas utilisées dans la pratique)
 
Configuration d'OAM
OAM peut être configuré :
- Via la console d'administration OAM ou la commande OAM WLST 
configureSAMLBinding()pour définir la liaison de réponse d'assertion à utiliser - Via la commande OAM WLST 
configureSAMLBinding()pour indiquer comment le message SAML AuthnRequest doit être envoyé 
Remarque : la liaison pour l'envoi du message SAML 2.0 AuthnRequest sera également utilisée pour envoyer les messages SAML 2.0
LogoutRequestetLogoutResponse.
Console d'administration OAM
Pour configurer la liaison réponse/assertion SSO via la console d'administration OAM, procédez comme suit :
- Accédez à la console d'administration OAM : 
http(s)://oam-admin-host:oam-adminport/oamconsole. - Accédez à Fédération d'identités, Administration de fournisseur de services.
 - Ouvrez le partenaire IdP que vous souhaitez modifier.
 - Cochez la case "HTTP POST SSO Response Binding" pour demander à IdP de renvoyer la réponse SSO via HTTP POST, ou désélectionnez-la pour demander l'artefact.
 - Cliquez sur Enregistrer.
 

Description de l'image SSO_Response_Assertion_Configuration.jpg
Commande WLST
Pour configurer la liaison d'assertion/réponse SSO ainsi que la liaison AuthnRequest via la commande OAM WLST configureSAMLBinding(), procédez comme suit :
- Entrez dans l'environnement WLST en exécutant : 
$IAM_ORACLE_HOME/common/bin/wlst.sh - Connectez-vous au serveur d'administration WLS : 
connect() - Accédez au branchement d'exécution de domaine : 
domainRuntime() - Exécutez la commande 
configureSAMLBinding():configureSAMLBinding("PARTNER", "PARTNER_TYPE", binding, ssoResponseBinding="httppost") - Remplacer le PARTENAIRE par le nom du partenaire
 - Remplacez PARTNER_TYPE par le type de partenaire (idp ou sp).
 - Remplacez la liaison par la liaison à utiliser pour envoyer les messages AuthnRequest et 
LogoutRequest/LogoutResponse(il doit s'agir de httpredirect dans la plupart des cas ; par défaut) httppostpour la liaison HTTP-POSThttpredirectpour la liaison HTTP-Redirect- Indiquez éventuellement 
ssoResponseBindingpour indiquer comment renvoyer l'assertion SSO httppostpour la liaison HTTP-POSTartifactforpour la liaison d'artefact. Exemple :configureSAMLBinding("AcmeIdP", "idp", "httpredirect", ssoResponseBinding="httppost")- Quittez l'environnement WLST : 
exit() 
Tester
Dans ce test, OAM/SP est intégré à un partenaire SAML 2.0 IdP distant, avec la configuration OOTB qui demande à HTTP-POST à partir de IdP d'envoyer l'assertion SSO. Selon cette configuration, lorsqu'OAM/SP démarre un flux SSO de fédération, le fichier AuthnRequest SAML 2.0 suivant est généré :
<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>
Ressources de formation supplémentaires
Parcourez d'autres ateliers sur docs.oracle.com/learn ou accédez à d'autres contenus de formation gratuite sur le canal Oracle Learning YouTube. En outre, visitez le site education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.
Pour consulter la documentation du produit, visitez le site Oracle Help Center.
AuthnRequest Settings in OAM and SP
F59885-01
September 2022
Copyright © 2022, Oracle and/or its affiliates.