Métodos de Autenticación de Fed en OAM y IdP

Este artículo trata sobre cómo se puede configurar IdP para asignar métodos de autenticación de federación a esquemas de autenticación de OAM:

Al procesar una solicitud de autenticación, donde el SP solicita un método de autenticación de federación específico con el que el usuario debe ser consultado
Al enviar una afirmación, donde IdP define el método de autenticación de federación en la afirmación

Visión general

Los distintos protocolos de federación admiten mecanismos que permiten a los socios intercambiar información sobre:

Cómo se debe desafiar al usuario cuando el SP/RP realiza una solicitud
Cómo se ha desafiado al usuario cuando el IdP/OP emite una respuesta SSO

Cuando un partner de SP remoto redirige al usuario a IdP para SSO de federación, el mensaje puede contener datos que soliciten cómo IdP debe desafiar al usuario: se trata como el método de autenticación de federación solicitado.

IdP debe asignar el método de autenticación de federación solicitado a un esquema de autenticación local y, a continuación, llamar a OAM para la autenticación/recomprobación de usuario con el esquema de autenticación asignado. OAM autentica al usuario si es necesario con el esquema especificado por IdP.

Del mismo modo, cuando un IdP emite una respuesta SSO, la mayor parte del tiempo debe incluir un identificador que represente cómo se ha comprobado al usuario: se trata como el método de autenticación de federación.

Cuando IdP emite una afirmación, evalúa el esquema de autenticación con el que OAM identificó al usuario:

Si el esquema de autenticación se puede asignar a un método de autenticación de federación, IdP utiliza el resultado de esa asignación en la respuesta de SSO saliente:
AuthenticationStatement en la afirmación de SAML
OpenID Respuesta, si PAPE está activado
Si el esquema de autenticación no se puede asignar, IdP define el método de autenticación de federación como el nombre del esquema de autenticación en la respuesta de SSO saliente
AuthenticationStatement en la afirmación de SAML
OpenID Respuesta, si PAPE está activado

Asignaciones

En IdP, la asignación entre métodos de autenticación de federación y esquemas de autenticación tiene las siguientes reglas:

Se puede asignar un método de autenticación de federación a varios esquemas de autenticación
En un método de autenticación de federación, asignación de esquemas de autenticación, un único esquema de autenticación se marca como el esquema por defecto que se utilizará para autenticar a un usuario si el partner de SP/RP solicita al usuario que se autentique mediante un método de autenticación de federación específico.
Un esquema de autenticación se puede asignar a un único método de autenticación de federación

Examinemos el siguiente ejemplo y los distintos casos de uso, según el protocolo SAML 2.0:

Asignaciones definidas como:

urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport asignado a LDAPScheme, marcado como el esquema por defecto utilizado para la autenticación BasicScheme
urn:oasis:names:tc:SAML:2.0:ac:classes:X509 asignado a X509Scheme, marcado como el esquema por defecto utilizado para la autenticación

Casos de uso:

El SP envía un AuthnRequest especificando urn:oasis:names:tc:SAML:2.0:ac:classes:X509 como RequestedAuthnContext: IdP autentica el uso con X509Scheme, ya que es el esquema por defecto asignado para ese método.
El SP envía un AuthnRequest especificando urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport como RequestedAuthnContext: IdP autentica el uso con LDAPScheme, ya que es el esquema por defecto asignado para ese método, no BasicScheme
El SP no ha solicitado ningún método específico y el usuario se ha autenticado con BasisScheme: IdP emite una afirmación con urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport como FederationAuthenticationMethod
El SP no ha solicitado ningún método específico y el usuario se ha autenticado con LDAPScheme: IdP emite una afirmación con urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport como FederationAuthenticationMethod
El SP no ha solicitado ningún método específico y el usuario se ha autenticado con BasisSessionlessScheme: IdP emite una afirmación con BasisSessionlessScheme como FederationAuthenticationMethod, porque ese esquema no se ha podido asignar a ningún método de autenticación de federación (en este caso, el administrador debe corregirlo y crear una asignación)

Configuración

La asignación de métodos de autenticación de federación a esquemas de autenticación de OAM depende del protocolo, ya que los métodos se definen en los distintos protocolos (SAML 2.0, SAML 1.1, OpenID 2.0).

Como tal, los comandos de WLST para definir esas asignaciones implican:

El perfil de socio de SP y afecta a todos los socios que hacen referencia a ese perfil, que no sustituyen las asignaciones del método de autenticación de federación al esquema de autenticación de OAM
O la entrada de socio del SP, que afecta al socio del SP

Nota: Es importante tener en cuenta que si un partner de SP está configurado para definir una o más asignaciones de método de autenticación de federación a esquema de autenticación de OAM, se ignoran todas las asignaciones de2ned del perfil de partner de SP.

Esquema de Autenticación

Durante SSO de federación, IdP reenvía internamente el usuario a OAM para autenticación/verificación y especifica el esquema de autenticación que se va a utilizar.

OAM determina si un usuario debe ser desafiado:

Si el usuario aún no se ha autenticado
Si el usuario está autenticado pero la sesión ha sufrido un timeout
Si el usuario está autenticado, pero el nivel de esquema de autenticación de la autenticación original es inferior al nivel del esquema de autenticación solicitado por IdP

Por lo tanto, aunque un SP solicite que se utilice un método de autenticación de federación específico para desafiar al usuario, si ese método está asignado a un esquema de autenticación y en tiempo de ejecución OAM considera que el usuario no necesita ser desafiado con ese esquema (porque el usuario ya está autenticado, la sesión no ha sufrido un timeout y el nivel de autenticación de sesión es igual o superior al del esquema de autenticación especificado), el arco no da como resultado una operación de comprobación.

Protocolos

SAML 2.0

Las especificaciones de SAML 2.0 definen los siguientes métodos de autenticación de federación para flujos de SAML 2.0:

urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified (Fin de creación)
urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocol (Fin de creación)
urn:oasis:names:tc:SAML:2.0:ac:classes:Telephony (Fin de creación)
urn:oasis:names:tc:SAML:2.0:ac:classes:MobileOneFactorUnregistered (Fin de creación)
urn:oasis:names:tc:SAML:2.0:ac:classes:PersonalTelephony (Fin de creación)
urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession (Fin de creación)
urn:oasis:names:tc:SAML:2.0:ac:classes:MobileOneFactorContract (Fin de creación)
urn:oasis:names:tc:SAML:2.0:ac:classes:Smartcard (Fin de creación)
urn:oasis:names:tc:SAML:2.0:ac:classes:Password (Fin de creación)
urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocolPassword (Fin de creación)
urn:oasis:names:tc:SAML:2.0:ac:classes:X509 (Fin de creación)
urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient (Fin de creación)
urn:oasis:names:tc:SAML:2.0:ac:classes:PGP (Fin de creación)
urn:oasis:names:tc:SAML:2.0:ac:classes:SPKI (Fin de creación)
urn:oasis:names:tc:SAML:2.0:ac:classes:XMLDSig (Fin de creación)
urn:oasis:names:tc:SAML:2.0:ac:classes:SoftwarePKI (Fin de creación)
urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos (Fin de creación)
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport (Fin de creación)
urn:oasis:names:tc:SAML:2.0:ac:classes:SecureRemotePassword (Fin de creación)
urn:oasis:names:tc:SAML:2.0:ac:classes:NomadTelephony (Fin de creación)
urn:oasis:names:tc:SAML:2.0:ac:classes:AuthenticatedTelephony (Fin de creación)
urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorUnregistered (Fin de creación)
urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorContract (Fin de creación)
urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI (Fin de creación)
urn:oasis:names:tc:SAML:2.0:ac:classes:TimeSyncToken (Fin de creación)

Inicialmente, IdP tiene las siguientes asignaciones para el protocolo SAML 2.0:

Solo se define urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
Este método de autenticación de federación se asigna a:
- LDAPScheme, marcado como el esquema por defecto utilizado para la autenticación
- FAAuthScheme (Fin de creación)
- BasicScheme (Fin de creación)
- BasicFAScheme (Fin de creación)
Esta asignación se define en el perfil de socio de SP saml20-sp-partner-profile, que es el perfil de socio de SP de OOTB por defecto para SAML 2.0

Un ejemplo de un mensaje AuthnRequest enviado por un SP a IdP con el SP que solicita un método de autenticación de federación específico que se utilizará para desafiar al usuario será:

<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>

Un ejemplo de afirmación emitida por IdP será:

<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 administrador debe poder especificar una asignación entre un método de autenticación de federación de SAML 2.0 y uno o más esquemas de autenticación de OAM

SAML 1.1

Las especificaciones de SAML 1.1 definen los siguientes métodos de autenticación de federación para flujos de SAML 1.1:

urn:oasis:names:tc:SAML:1.0:am:unspecified (Fin de creación)
urn:oasis:names:tc:SAML:1.0:am:HardwareToken (Fin de creación)
urn:oasis:names:tc:SAML:1.0:am:password (Fin de creación)
urn:oasis:names:tc:SAML:1.0:am:X509-PKI (Fin de creación)
urn:ietf:rfc:2246 (Fin de creación)
urn:oasis:names:tc:SAML:1.0:am:PGP (Fin de creación)
urn:oasis:names:tc:SAML:1.0:am:SPKI (Fin de creación)
urn:ietf:rfc:3075 (Fin de creación)
urn:oasis:names:tc:SAML:1.0:am:XKMS (Fin de creación)
urn:ietf:rfc:1510 urn:ietf:rfc:2945 (Fin de creación)

Inicialmente, IdP tiene las siguientes asignaciones para el protocolo SAML 1.1:

Solo se define urn:oasis:names:tc:SAML:1.0:am:password
Este método de autenticación de federación se asigna a:
LDAPScheme, marcado como el esquema por defecto utilizado para la autenticación
FAAuthScheme (Fin de creación)
BasicScheme (Fin de creación)
BasicFAScheme (Fin de creación)

Esta asignación se define en el perfil de socio de SP saml11-sp-partner-profile, que es el perfil de socio de SP de OOTB por defecto para SAML 1.1

Un ejemplo de afirmación emitida por IdP será:

<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>

Nota: SAML 1.1 no define un mensaje AuthnRequest.

Un administrador puede especificar una asignación entre un método de autenticación de federación de SAML 1.1 y uno o más esquemas de autenticación de OAM.

OpenID 2.0

Las especificaciones PAPE OpenID 2.0 definen los siguientes métodos de autenticación de federación para los flujos OpenID 2.0:

http://schemas.openid.net/pape/policies/2007/06/phishing-resista (Fin de creación)
http://schemas.openid.net/pape/policies/2007/06/multi-fact (Fin de creación)
http://schemas.openid.net/pape/policies/2007/06/multi-factor-physic (Fin de creación)

Inicialmente, IdP no define ninguna asignación para los métodos de autenticación de federación OpenID 2.0.

Para OpenID 2.0, la configuración implica la asignación de una lista de políticas OpenID 2.0 a una lista de esquemas de autenticación.

Un ejemplo de un mensaje de solicitud OpenID 2.0 enviado por un SP/RP a un IdP/OP será:

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

Un ejemplo de una respuesta de inicio de sesión único de Open ID 2.0 emitida por un IdP/OP será:

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

Más recursos de aprendizaje

Explore otros laboratorios en docs.oracle.com/learn o acceda a más contenido de aprendizaje gratuito en el canal YouTube de Oracle Learning. Además, visite education.oracle.com/learning-explorer para convertirse en un explorador de Oracle Learning.

Para obtener documentación sobre el producto, visite Oracle Help Center.

Título e Información de Copyright

Fed Authentication Methods in OAM and IdP

F60445-01

September 2022