Integración de ADFS 2.0 y 3.0 con OAM: Requisito previo

En este artículo se describe cómo integrar OAM con ADFS 2.0/3.0 para SSO de federación mediante el protocolo SAML 2.0. La integración abarca:

• Requisitos (este artículo)

• ADFS 2.0/3.0 como IdP y OAM como SP

• ADFS 2.0/3.0 como SP y OAM como IdP

La integración de SAML 2.0 se basa en:

• Dirección de correo electrónico que se utilizará como formato NameID

• El valor NameID contiene la dirección de correo electrónico del usuario

• El enlace HTTP POST se utilizará para enviar la afirmación de SAML al SP

• Los usuarios existen en ambos sistemas, y cada usuario tiene la misma dirección de correo electrónico para que se pueda utilizar como atributo de usuario común.

ADFS 2.0 está disponible en Windows 2008 R2, mientras que ADFS 3.0 está disponible en Windows 2012 R2. En los artículos se muestran capturas de pantalla de ADFS 3.0, mientras que los pasos documentados se aplican a ambas versiones.

Requisitos

Para integrarse con ADFS mediante el protocolo SAML 2.0, OAM debe estar configurado para utilizar HTTPS/SSL como sus puntos finales. Si no lo hace, ADFS no acepta los metadatos de SAML 2.0 de OAM al establecer la confianza de federación.

Al integrar ADFS como IdP con OAM como SP, se deben tener en cuenta los siguientes puntos:

• Por defecto, ADFS IdP cifra la afirmación de SAML al enviarla al SP mediante AES-256 y, por defecto, el JDK utilizado en el despliegue de OAM no puede utilizar una criptografía compleja como AES-256. Entonces:

  • El JDK debe estar configurado para una criptografía compleja

  • O bien ADFS IdP debe estar configurado para desactivar el cifrado

• Si ADFS IdP está configurado para autenticación mediante autenticación HTTP básica o autenticación nativa de Windows, el usuario nunca se podrá desconectar como:

  • Las credenciales de autenticación básica HTTP no se pueden eliminar del explorador una vez introducidas, a menos que el explorador esté cerrado

Nota: Esto se aplica a otros IdPs que utilizan la autenticación básica HTTP para desafiar al usuario.

• El explorador siempre está conectado a ADFS al utilizar la autenticación nativa de Windows.

• Por defecto, ADFS necesita que los mensajes se firmen mediante SHA-256, mientras que por defecto OAM utiliza SHA-1:

  • Configure ADFS para utilizar/acepte SHA-1

  • O bien, configure OAM para que utilice SHA-256 para las firmas

Por último, antes de integrar OAM y ADFS para SAML 2.0, se deben haber descargado los metadatos de los dos servidores.

Habilitación de SSL

Hay varias formas de activar SSL en los puntos finales públicos para OAM:

• Si un equilibrador de carga está delante de OAM, SSL/HTTPS se puede activar/configurar en el equilibrador de carga

• Si OHS está frente a OAM, OHS se configurará para SSL

• Si no hay ningún componente delante de OAM, el servidor WLS en el que se está ejecutando OAM se puede configurar para SSL/HTTPS

Una vez que el componente (Equilibrador de carga, OHS o WLS) se ha configurado para SSL, la configuración de OAM se debe actualizar para hacer referencia al nuevo punto final como su URL pública:

1. Vaya a la consola de administración de OAM: http(s)://oam-admin-host:oam-adminport/oamconsole

2. Vaya a Configuration , Access Manager Settings

3. Definir el host del servidor OAM en el nombre de host del punto final público

4. Definir la publicación del servidor OAM en el puerto SSL del punto final público

5. Definir el protocolo del servidor OAM en https

6. Haga clic en Aplicar.

Descripción de la ilustración Access_Manager_Settings.jpg

Nota: Después de realizar estos cambios, la recuperación de los metadatos de SAML 2.0 de OAM contiene las nuevas URL de https.

cifrado sólido

Como se ha mencionado, por defecto, ADFS IdP cifra la afirmación de SAML al enviarla al SP mediante AES-256, que Java considera un cifrado sólido (en contraposición a "fuerza normal", como AES-128, AES-192, 3DES...).

Debido a motivos de exportación legales, JDK no se puede enviar con cifrados fuertes activados en JCE: administrator/integrator/developer debe descargar e instalar la política de jurisdicción de solidez ilimitada de Java Cryptography Extension (JCE).

Para actualizar los archivos de política JCE Unlimited Strength Jurisdiction para soportar un cifrado sólido, como AES-256, realice los siguientes pasos:

1. Determine la versión de Java principal utilizada en el despliegue de OAM.

2. Busque la carpeta JDK que utiliza OAM Execute: $JDK_HOME/bin/java -version.

3. Se imprimirá la versión principal (6 o 7).

4. Descargue la política JCE Unlimited Strength Jurisdiction.

5. Si utiliza JDK 7:

   • http://www.oracle.com/technetwork/java/javas%20/downloads/index.htm (Fin de creación)

6. Si utiliza JDK 6:

   • http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archivedownloads-java-plat-419418.html (Fin de creación)

7. Baje el contenido del archivo ZIP descargado en una carpeta temporal.

8. Copie los archivos local_policy.jar y US_export_policy.jar descomprimidos en el siguiente directorio de JDK (esta operación sobrescribe los archivos local_policy.jar y US_export_policy.jar presentes en esa carpeta): $JDK_HOME/jre/lib/security.

9. Reinicie los servidores de WLS en el dominio de WLS para aplicar los cambios.

Para configurar ADFS para desactivar el cifrado al enviar la afirmación de SAML a un SP, realice los siguientes pasos:

1. Vaya a la máquina en la que está desplegado ADFS.

2. Si se utiliza ADFS 2.0, haga clic en Menú de inicio , Programas , Herramientas administrativas , Módulos de Windows PowerShell.

3. Si se utiliza ADFS 3.0, haga clic en Start Menu (Iniciar), Administrative Tools (Herramientas administrativas), Active Directory Module for Windows PowerShell (Módulo de Active Directory para Windows).

4. Ejecute el siguiente comando (sustituya RP_NAME por el nombre del SP utilizado para crear el partner en ADFS): set-ADFSRelyingPartyTrust –TargetName“RP_NAME” –EncryptClaims $False.

Desconexión de ADFS

El protocolo SAML 2.0 define un perfil de desconexión en el que cada partner de federación implicado en una SSO de federación para la sesión del usuario actual recibe una notificación del usuario que se desconecta. Esto permite a los distintos partners de federación terminar la sesión del usuario en su dominio de SSO.

ADFS IdP proporciona diferentes formas de autenticar al usuario cuando se realiza una SSO de federación:

• autenticación basada en FORM donde

  • El servidor muestra una página de conexión

  • El usuario introduce las credenciales y las envía

• Autenticación HTTP Básica

  • Donde el servidor devuelve un código de estado 401 al explorador

  • El explorador recopila las credenciales del usuario

  • El explorador presenta las credenciales al servidor de ADFS

Nota: El explorador mantiene las credenciales y las proporciona al servidor de ADFS cada vez que el explorador accede a ADFS, hasta que se cierra el explorador.

• Autenticación de Windows integrada en la que ADFS aprovecha el estado de autenticación del usuario en el entorno de Windows: en este caso, dado que el usuario ya está conectado a Windows, el usuario se autentica automáticamente sin ninguna interacción del usuario.

Veamos el efecto (o no efecto) de la desconexión de SAML 2.0 según cómo se autentique el usuario:

• El SP inicia una operación SSO de federación con ADFS IdP

• ADFS IdP debe autenticar/identificar el usuario

  • Si se utiliza la autenticación basada en FORM, ADFS muestra una página de conexión y el usuario introduce sus credenciales

  • Si se utiliza la autenticación HTTP básica, ADFS devuelve el código de respuesta 401, el explorador recopila las credenciales del usuario y las presenta a ADFS

  • Si se utiliza la autenticación integrada de Windows, el explorador obtiene automáticamente un token Kerberos/NTLMSSP del controlador de dominio de Windows/KDC que presenta al servidor ADFS. No hay interacción del usuario.

• Se redirige al usuario al SP con una afirmación de SAML

• El usuario inicia la desconexión de SAML 2.0 desde el SP

• El SP redirige al usuario a ADFS IdP para la desconexión de SAML 2.0

• ADFS borra las cookies del explorador del usuario (pero no las credenciales de autenticación básica HTTP almacenadas en caché si se han utilizado anteriormente)

• En el mismo explorador, SP inicia una operación SSO de federación con ADFS IdP

• ADFS IdP debe autenticar/identificar el usuario

  • Si se utiliza la autenticación basada en FORM, ADFS muestra una página de conexión y el usuario introduce sus credenciales: el usuario es desafiado y debe proporcionar sus credenciales

  • Si se utiliza la autenticación básica HTTP, ADFS devuelve el código de respuesta 401, el explorador ha almacenado en caché las credenciales recopiladas anteriormente y, por lo tanto, las presenta automáticamente a ADFS. No hay interacción del usuario

  • Si se utiliza la autenticación integrada de Windows, el explorador obtiene automáticamente un token Kerberos/NTLMSSP del controlador de dominio de Windows/KDC que presenta al servidor ADFS. No hay interacción del usuario.

Por lo tanto, si se utiliza la autenticación HTTP básica o la autenticación de Windows integrada como mecanismo de autenticación en ADFS 2.0 IdP, después de una desconexión, el usuario seguirá "conectado" en IdP y la ejecución de una nueva SSO de federación no disparará el usuario que se está comprobando y provocará que el usuario se autentique automáticamente en el SP, después de realizar la SSO de federación.

Nota importante: el comportamiento observado con la desconexión también se aplica a otros IdPs (por ejemplo, OAM), que utilizan la autenticación básica HTTP como mecanismo de autenticación

Metadatos de SAML 2.0

Para descargar los metadatos de SAML 2.0 del servidor ADFS 2.0/3.0:

1. Abra un explorador.

2. Vaya al servicio de publicación de metadatos de ADFS 2.0/3.0: https://adfs-host:adfs-port/FederationMetadata/2007-06/FederationMetadata.xml.

3. Guarde los metadatos localmente con el botón Save As del explorador.

Para descargar los metadatos de SAML 2.0 desde OAM:

1. Abra un explorador.

2. Vaya al servicio de publicación de metadatos de OAM: http(s)://oam-runtime-host:oam-runtimeport/oamfed/idp/metadata o http(s)://oam-runtime-host:oam-runtimeport/oamfed/sp/metadata.

3. Guarde los metadatos localmente con el botón Save As del explorador.

Nota: Asegúrese de haber activado SSL en OAM antes de descargar los metadatos de OAM, ya que los metadatos contienen las URL de OAM.

SHA-256 frente a SHA-1

Después de configurar la federación entre OAM y ADFS, debe:

• Configure ADFS 2.0 para utilizar/aceptar SHA-1

• O bien, configure OAM para que utilice SHA-256 para las firmas

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

Integrating ADFS 2.0 and 3.0 with OAM Pre-requisite

F60452-01

September 2022

Copyright © 2022, Oracle and/or its affiliates.