Méthodes d'authentification fédérées dans OAM et IdP
Cet article explique comment configurer IdP pour mettre en correspondance les méthodes d'authentification de fédération avec les modèles d'authentification OAM :
-
Lors du traitement d'une demande Authn, où le SP demande une méthode d'authentification de fédération spécifique avec laquelle l'utilisateur doit être interrogé
-
Lors de l'envoi d'une assertion, où IdP définit la méthode d'authentification de fédération dans l'assertion
Présentation
Les différents protocoles de la Fédération soutiennent des mécanismes permettant aux partenaires d'échanger des informations sur :
-
Méthode de questionnement de l'utilisateur lorsque le SP/RP effectue une demande
-
Comment l'utilisateur a été interrogé lorsque le fournisseur d'identités/OP émet une réponse SSO
Lorsqu'un partenaire SP distant redirige l'utilisateur vers IdP pour l'authentification SSO de fédération, le message peut contenir des données demandant comment l'utilisateur doit être interrogé par IdP : il est traité comme la méthode d'authentification de fédération demandée.
IdP doit mettre en correspondance cette méthode d'authentification de fédération demandée avec un modèle d'authentification local, puis appeler OAM pour l'authentification/le défi utilisateur avec le modèle d'authentification mis en correspondance. OAM authentifie l'utilisateur si nécessaire avec le modèle indiqué par IdP.
De même, lorsqu'un élément IdP émet une réponse SSO, la plupart du temps, il doit inclure un identificateur représentant la manière dont l'utilisateur a été interrogé : il est traité comme la méthode d'authentification de fédération.
Lorsque IdP émet une assertion, il évalue le modèle d'authentification avec lequel OAM a identifié l'utilisateur :
-
Si le modèle d'authentification peut être mis en correspondance avec une méthode d'authentification de fédération, IdP utilise le résultat de cette mise en correspondance dans la réponse SSO sortante :
-
AuthenticationStatement
dans l'assertion SAML -
Réponse OpenID, si PAPE est activé
-
Si le modèle d'authentification ne peut pas être mis en correspondance, IdP définit la méthode d'authentification de fédération en tant que nom du modèle d'authentification dans la réponse SSO sortante
-
AuthenticationStatement
dans l'assertion SAML -
Réponse OpenID, si PAPE est activé
Correspondances
Dans IdP, la correspondance entre les méthodes d'authentification de fédération et les modèles d'authentification comporte les règles suivantes :
-
Une méthode d'authentification de fédération peut être mise en correspondance avec plusieurs modèles d'authentification
-
Dans une méthode d'authentification de fédération, correspondance de modèles d'authentification, un seul modèle d'authentification est marqué comme modèle par défaut qui sera utilisé pour authentifier un utilisateur, si le partenaire SP/RP demande à l'utilisateur d'être authentifié via une méthode d'authentification de fédération spécifique
-
Un modèle d'authentification peut être mis en correspondance avec une seule méthode d'authentification de fédération
Examinons l'exemple suivant et les différents cas d'utilisation basés sur le protocole SAML 2.0 :
Mappages définis en tant que :
-
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
mis en correspondance avecLDAPScheme
, marqué comme modèle par défaut utilisé pour l'authentificationBasicScheme
-
urn:oasis:names:tc:SAML:2.0:ac:classes:X509
mis en correspondance avecX509Scheme
, marqué comme modèle par défaut utilisé pour l'authentification
Cas d'emploi:
-
Le processeur de service envoie un message AuthnRequest indiquant
urn:oasis:names:tc:SAML:2.0:ac:classes:X509
comme RequestedAuthnContext : IdP authentifie l'utilisation avecX509Scheme
car il s'agit du schéma par défaut mappé pour cette méthode. -
Le processeur de service envoie un message AuthnRequest indiquant
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
comme RequestedAuthnContext : IdP authentifie l'utilisation avecLDAPScheme
car il s'agit du schéma par défaut mappé pour cette méthode, et non avecBasicScheme
-
Le SP n'a demandé aucune méthode spécifique et l'utilisateur a été authentifié avec
BasisScheme
: IdP émet une assertion avecurn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
en tant queFederationAuthenticationMethod
-
Le SP n'a demandé aucune méthode spécifique et l'utilisateur a été authentifié avec
LDAPScheme
: IdP émet une assertion avecurn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
en tant queFederationAuthenticationMethod
-
Le fournisseur de services n'a demandé aucune méthode SPécifique et l'utilisateur a été authentifié avec
BasisSessionlessScheme
: IdP émet une assertion avecBasisSessionlessScheme
en tant queFederationAuthenticationMethod
, car ce modèle n'a pu être mis en correspondance avec aucune méthode d'authentification de fédération (dans ce cas, l'administrateur doit corriger cela et créer un mapping).
Configuration
La correspondance entre les méthodes d'authentification Federation et les modèles d'authentification OAM dépend du protocole car les méthodes sont définies dans les différents protocoles (SAML 2.0, SAML 1.1, OpenID 2.0).
Par conséquent, les commandes WLST permettant de définir ces mappings impliquent :
-
Le profil de partenaire de fournisseur de services et tous les partenaires référençant ce profil, qui ne remplacent pas les correspondances de méthode d'authentification de fédération avec le modèle d'authentification OAM
-
Ou l'entrée du partenaire SP, qui affecte le partenaire SP
Remarque : il est important de noter que si un partenaire de fournisseur de services est configuré pour définir des mappings de méthode d'authentification de fédération avec modèle d'authentification OAM, tous les mappings de2ned du profil de partenaire de fournisseur de services sont ignorés.
Modèle d'authentification
Lors de l'accès avec connexion unique (SSO) de fédération, IdP transmet l'utilisateur en interne à OAM pour authentification/vérification et indique le modèle d'authentification à utiliser.
OAM détermine si un utilisateur doit faire l'objet d'une question de vérification :
-
Si l'utilisateur n'est pas encore authentifié
-
Si l'utilisateur est authentifié mais que la session a expiré
-
Si l'utilisateur est authentifié, mais que le niveau de modèle d'authentification de l'authentification d'origine est inférieur au niveau de modèle d'authentification demandé par IdP
Ainsi, même si un SP demande qu'une méthode d'authentification de fédération spécifique soit utilisée pour la question de vérification de l'utilisateur, si cette méthode est mise en correspondance avec un modèle d'authentification et qu'à l'exécution, OAM considère que l'utilisateur n'a pas besoin d'être questionné avec ce schéma (car l'utilisateur est déjà authentifié, la session n'a pas expiré, et le niveau d'authentification de session est égal ou supérieur à celui du schéma d'authentification spécifié), l'arc ne conduit pas à une opération de challenge.
Protocoles
SAML 2.0
Les spécifications SAML 2.0 définissent les méthodes d'authentification de fédération suivantes pour les flux SAML 2.0 :
-
urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified
-
urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocol
-
urn:oasis:names:tc:SAML:2.0:ac:classes:Telephony
-
urn:oasis:names:tc:SAML:2.0:ac:classes:MobileOneFactorUnregistered
-
urn:oasis:names:tc:SAML:2.0:ac:classes:PersonalTelephony
-
urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession
-
urn:oasis:names:tc:SAML:2.0:ac:classes:MobileOneFactorContract
-
urn:oasis:names:tc:SAML:2.0:ac:classes:Smartcard
-
urn:oasis:names:tc:SAML:2.0:ac:classes:Password
-
urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocolPassword
-
urn:oasis:names:tc:SAML:2.0:ac:classes:X509
-
urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient
-
urn:oasis:names:tc:SAML:2.0:ac:classes:PGP
-
urn:oasis:names:tc:SAML:2.0:ac:classes:SPKI
-
urn:oasis:names:tc:SAML:2.0:ac:classes:XMLDSig
-
urn:oasis:names:tc:SAML:2.0:ac:classes:SoftwarePKI
-
urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos
-
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
-
urn:oasis:names:tc:SAML:2.0:ac:classes:SecureRemotePassword
-
urn:oasis:names:tc:SAML:2.0:ac:classes:NomadTelephony
-
urn:oasis:names:tc:SAML:2.0:ac:classes:AuthenticatedTelephony
-
urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorUnregistered
-
urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorContract
-
urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI
-
urn:oasis:names:tc:SAML:2.0:ac:classes:TimeSyncToken
Prêt à l'emploi, IdP dispose des correspondances suivantes pour le protocole SAML 2.0 :
-
Seul
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
est défini -
Cette méthode d'authentification de fédération est mise en correspondance avec :
-
LDAPScheme
, marqué comme modèle par défaut utilisé pour l'authentification -
FAAuthScheme
-
BasicScheme
-
BasicFAScheme
-
-
Ce mappage est défini dans le profil de partenaire de fournisseur de services saml20-SP-partner-profile, qui est le profil de partenaire de fournisseur de services OOTB par défaut pour SAML 2.0
Voici un exemple de message AuthnRequest envoyé par un fournisseur de services à IdP, le fournisseur de services demandant une méthode d'authentification de fédération SPécifique à utiliser pour la question de vérification de l'utilisateur :
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
Destination="https://idp.com/oamfed/idp/samlv20" ID="id-8bWn
A9o4aoMl3Nhx1DuPOOjawc-" IssueInstant="2014-03-21T20:51:11Z" Version="2.0">
<saml:Issuer ...>https://acme.com/sp</saml:Issuer>
<samlp:NameIDPolicy AllowCreate="false"
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspeciGed"/> <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:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
</samlp:AuthnRequest>
Voici un exemple d'assertion émise par un élément IdP :
<samlp:Response ...>
<saml:Issuer ...>https://idp.com/oam/fed</saml:Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<saml:Assertion ...>
<saml:Issuer ...>https://idp.com/oam/fed</saml:Issuer>
<dsig:Signature>
...
</dsig:Signature>
<saml:Subject>
<saml:NameID ...>bob@oracle.com</saml:NameID>
<saml:SubjectConGrmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConGrmationData .../>
</saml:SubjectConGrmation> </saml:Subject>
<saml:Conditions ...>
<saml:AudienceRestriction>
<saml:Audience>https://acme.com/sp</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement AuthnInstant="2014-03-21T20:53:55Z" SessionIndex="id6i-Dm0yB-HekG6cejktwcKIFMzYE8Yrmqwfd0azz"
SessionNotOnOrAfter="2014-03-21T21:53:55Z">
<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef> </saml:AuthnContext>
</saml:AuthnStatement>
</saml:Assertion>
</samlp:Response>
Un administrateur doit pouvoir spécifier une correspondance entre une méthode d'authentification de fédération SAML 2.0 et des modèles d'authentification OAM
SAML 1.1
Les spécifications SAML 1.1 définissent les méthodes d'authentification de fédération suivantes pour les flux SAML 1.1 :
-
urn:oasis:names:tc:SAML:1.0:am:unspecified
-
urn:oasis:names:tc:SAML:1.0:am:HardwareToken
-
urn:oasis:names:tc:SAML:1.0:am:password
-
urn:oasis:names:tc:SAML:1.0:am:X509-PKI
-
urn:ietf:rfc:2246
-
urn:oasis:names:tc:SAML:1.0:am:PGP
-
urn:oasis:names:tc:SAML:1.0:am:SPKI
-
urn:ietf:rfc:3075
-
urn:oasis:names:tc:SAML:1.0:am:XKMS
-
urn:ietf:rfc:1510 urn:ietf:rfc:2945
Prêt à l'emploi, IdP dispose des correspondances suivantes pour le protocole SAML 1.1 :
-
Seul
urn:oasis:names:tc:SAML:1.0:am:password
est défini -
Cette méthode d'authentification de fédération est mise en correspondance avec :
-
LDAPScheme
, marqué comme modèle par défaut utilisé pour l'authentification -
FAAuthScheme
-
BasicScheme
-
BasicFAScheme
Ce mappage est défini dans le profil de partenaire de fournisseur de services saml11-SP-partner-profile, qui est le profil de partenaire de fournisseur de services OOTB par défaut pour SAML 1.1
Voici un exemple d'assertion émise par un élément IdP :
<samlp:Response ...>
<samlp:Status>
<samlp:StatusCode Value="samlp:Success"/>
</samlp:Status>
<saml:Assertion Issuer="https://idp.com/oam/fed" ...>
<saml:Conditions ...>
<saml:AudienceRestriction>
<saml:Audience>https://acme.com/sp/ssov11</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement AuthenticationInstant="2014-03-21T20:53:55Z"
AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password">
<saml:Subject>
<saml:NameIdentiGer ...>bob@oracle.com</saml:NameIdentiGer>
<saml:SubjectConGrmation>
<saml:ConGrmationMethod>
urn:oasis:names:tc:SAML:1.0:cm:bearer
</saml:ConGrmationMethod>
</saml:SubjectConGrmation>
</saml:Subject>
</saml:AuthnStatement>
<dsig:Signature>
...
</dsig:Signature> </saml:Assertion> </samlp:Response>
Remarque : SAML 1.1 ne définit pas de message AuthnRequest.
Un administrateur peut spécifier une correspondance entre une méthode d'authentification de fédération SAML 1.1 et des modèles d'authentification OAM.
OpenID 2.0
Les spécifications PAPE OpenID 2.0 définissent les méthodes d'authentification de fédération suivantes pour les flux OpenID 2.0 :
-
http://schemas.openid.net/pape/policies/2007/06/phishing-resista
-
http://schemas.openid.net/pape/policies/2007/06/multi-fact
-
http://schemas.openid.net/pape/policies/2007/06/multi-factor-physic
IdP ne définit aucune correspondance prête à l'emploi pour les méthodes d'authentification de fédération OpenID 2.0.
Pour OpenID 2.0, la configuration implique la mise en correspondance d'une liste de stratégies OpenID 2.0 avec une liste de modèles d'authentification.
Voici un exemple de message de demande OpenID 2.0 envoyé par un SP/RP à un fournisseur d'identités/OP :
https://idp.com/openid?openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0&openid.mode=checkid_setup&openid.claimed_id=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2FidentiGer_select&openid.identity=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2FidentiGer_select&openid.assoc_handle=id-6a5S6zhAKaRwQNUnjTKROREdAGSjWodG1el4xyz3&openid.return_to=https%3A%2F%2Facme.com%2Fopenid%3FreGd%3Did9PKVXZmRxAeDYcgLqPm36ClzOMA-&openid.realm=https%3A%2F%2Facme.com%2Fopenid&openid.ns.ax=http%3A%2F%2Fopenid.net%2Fsrv%2Fax%2F1.0&openid.ax.mode=fetch_request&openid.ax.type.aer0=http%3A%2F%2Faxschema.org%2Fcontact%2Femail&openid.ax.if_available=aer0&openid.ns.pape=http%3A%2F%2Fspecs.openid.net%2Fextensions%2Fpape%2F1.0&openid.pape.max_auth_age=0
Voici un exemple de réponse SSO OpenID 2.0 émise par un fournisseur d'identités/un fournisseur d'exploitation :
https://acme.com/openid?reGd=id-9PKVXZmRxAeDYcgLqPm36ClzOMA-&openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0&openid.mode=id_res&openid.op_endpoint=https%3A%2F%2Fidp.com%2Fopenid&openid.claimed_id=https%3A%2F%2Fidp.com%2Fopenid%3Fid%3Did-38iCmmlAVEXPsFjnFVKArfn5RIiF75D5doorhEgqqPM%3D&openid.identity=https%3A%2F%2Fidp.com%2Fopenid%3Fid%3Did-38iCmmlAVEXPsFjnFVKArfn5RIiF75D5doorhEgqqPM%3D&openid.return_to=https%3A%2F%2Facme.com%2Fopenid%3FreGd%3Did9PKVXZmRxAeDYcgLqPm36ClzOMA-&openid.response_nonce=2014-03-24T19%3A20%3A06Zid-YPa2kTNNFftZkgBb460jxJGblk2g--iNwPpDI7M1&openid.assoc_handle=id6a5S6zhAKaRwQNUnjTKROREdAGSjWodG1el4xyz3&openid.ns.ax=http%3A%2F%2Fopenid.net%2Fsrv%2Fax%2F1.0&openid.ax.mode=fetch_response&openid.ax.type.aer0=http%3A%2F%2Fsession%2Fcount&openid.ax.value.aer0=1&openid.ax.type.aer1=http%3A%2F%2Fopenid.net%2Fschema%2FnamePerson%2Ffriendly&openid.ax.value.aer1=My+name+is+Bobby+Smith&openid.ax.type.aer2=http%3A%2F%2Fschemas.openid.net%2Fax%2Fapi%2Fuser_id&openid.ax.value.aer2=bob&openid.ax.type.aer3=http%3A%2F%2Faxschema.org%2Fcontact%2Femail&openid.ax.value.aer3=bob%40oracle.com&openid.ax.type.aer4=http%3A%2F%2Fsession%2Fipaddress&openid.ax.value.aer4=10.145.120.253&openid.ns.pape=http%3A%2F%2Fspecs.openid.net%2Fextensions%2Fpape%2F1.0&openid.pape.auth_time=2014-03-24T19%3A20%3A05Z&openid.pape.auth_policies=http%3A%2F%2Fschemas.openid.net%2Fpape%2Fpolicies%2F2007%2F06%2Fphishing-resistant&openid.signed=op_endpoint%2Cclaimed_id%2Cidentity%2Creturn_to%2Cresponse_nonce%2Cassoc_handle%2Cns.ax%2Cax.mode%2Cax.type.aer0%2Cax.value.aer0%2Cax.type.aer1%2Cax.value.aer1%2Cax.type.aer2%2Cax.value.aer2%openid.sig=mYMgbGYSs22l8e%2FDom9NRPw15u8%3D
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.
Fed Authentication Methods in OAM and IdP
F60445-01
September 2022
Copyright © 2022, Oracle and/or its affiliates.