Proxy Inverso de HTTP de DCC con OAM y OAM

En este artículo se describe la función de proxy inverso HTTP del recopilador de credenciales desasociadas (DCC) que se ha introducido en la versión 11.1.2.2.0.

En un despliegue en el que esta función está activada, un agente de SSO WebGate:

En este modo, todas las interacciones entre los usuarios/clientes y OAM se realizan mediante el proxy inverso HTTP de DCC WebGate: ningún usuario accederá directamente a los servidores de OAM.

Esta nueva capacidad de proxy inverso HTTP de DCC es diferente del DCC anterior para la conexión basada en HTTPBasic/FORM, y este último no funciona para los flujos SSO de federación (modo IdP o SP).

Visión general

Este artículo no incluye ninguna topología que contenga proxies inversos HTTP o equilibrador de carga delante de los distintos componentes de OAM (el propio servidor OAM o los agentes WebGate), pero incluye un caso de uso hacia el final que indica cómo utilizar el proxy inverso HTTP DCC en despliegues de HA, delante de un equilibrador de carga.

Autenticación sin DCC

El flujo de autenticación sin DCC es el caso de uso más común, donde se redirige al usuario desde los agentes de SSO que protegen los recursos del dominio de seguridad a OAM para su comprobación y autenticación. Un despliegue típico de OAM está formado por las siguientes entidades:

En el siguiente diagrama se describe dicho entorno:

Descripción de la ilustración local_security_domain.jpg

En el flujo de prueba, utilice el OOTB LDAPScheme como esquema para proteger los recursos del dominio de seguridad local.

Un flujo de autenticación local que utiliza LDAPScheme consta de lo siguiente:

  1. El usuario solicita acceso a un recurso protegido, definido en OAM para que esté protegido por LDAPScheme.

  2. El agente SSO WebGate intercepta la solicitud HTTP, determina que el usuario debe autenticarse y redirige al usuario al servidor OAM para su autenticación.

  3. El usuario accede al servidor OAM; el servidor inicia un flujo de autenticación mediante LDAPScheme y muestra la página de conexión

Descripción de la ilustración local_authentication_flow.jpg

Una vez que el usuario introduce sus credenciales y hace clic en el botón login, ocurre lo siguiente:

  1. El servidor OAM valida las credenciales, crea una sesión para el usuario, define una cookie en el explorador del usuario y redirige al usuario al recurso protegido.

  2. El usuario solicita acceso al recurso. Esta vez, el agente de SSO WebGate detecta que el usuario está autenticado y otorga acceso al recurso

Descripción de la ilustración local_security_workflow.jpg

DCC para la conexión basada en HTTP-Basic/FORM

El DCC para la conexión basada en HTTP-Basic/FORM se introdujo en versiones anteriores de OAM 11g y proporciona una forma para que un administrador designe un agente SSO WebGate como la entidad que:

En el flujo de prueba, utilice DCCLDAPScheme basado en el OOTB LDAPScheme, pero con la URL de comprobación actualizada para hacer referencia al DCC WebGate. Este esquema se utiliza para proteger los recursos del dominio de seguridad local.

Un flujo de autenticación local que utiliza ese DCCLDAPScheme personalizado consta de lo siguiente:

  1. El usuario solicita acceso a un recurso protegido, definido en OAM para que esté protegido por DCCLDAPScheme.

  2. El agente SSO WebGate intercepta la solicitud HTTP, determina que el usuario debe autenticarse y redirige al usuario a la página de conexión de DCC WebGate para la autenticación.

  3. El usuario accede a la página de inicio de sesión de DCC WebGate y proporciona credenciales.

  4. El DCC WebGate interactúa directamente con el servidor OAM que no es el protocolo NAP de OAM para validar las credenciales y crear una sesión para el usuario. A continuación, el DCC WebGate redirige al usuario al recurso protegido.

  5. El usuario solicita acceso al recurso. Esta vez, el agente de SSO WebGate detecta que el usuario está autenticado y otorga acceso al recurso.

Proxy inverso HTTP de DCC

El proxy inverso HTTP de DCC se introdujo en la versión 11.1.2.2.0 de OAM y permite al administrador configurar un agente SSO WebGate para que actúe como punto final público para el servidor OAM y OAM:

Nota: Básicamente, DCC WebGate se convierte en el punto final público para OAM y OAM y actúa como proxy inverso HTTP, a través del protocolo NAP de OAM.

En esta prueba, después de configurar OAM y WebGate para el proxy inverso HTTP de DCC y utiliza OOTB LDAPScheme como esquema para proteger los recursos del dominio de seguridad local (el esquema no se habrá cambiado).

Nota: Cualquier esquema de autenticación con una URL de comprobación que contenga una ruta de acceso relativa se puede utilizar en este modo de DCC, como FederationScheme. Además, la función IdP es compatible con ese modo de DCC.

Un flujo de autenticación local que utiliza LDAPScheme consta de lo siguiente:

  1. El usuario solicita acceso a un recurso protegido, definido en OAM para que esté protegido por LDAPScheme.

  2. El agente de SSO WebGate intercepta la solicitud HTTP, determina que el usuario debe autenticarse y redirige al usuario al DCC WebGate para su autenticación.

  3. El usuario accede a DCC WebGate y reenvía la solicitud al servidor OAM; el servidor inicia un flujo de autenticación mediante LDAPScheme, devuelve una página de conexión que se mostrará al DCC WebGate y el DCC WebGate muestra la página de conexión al usuario.

Descripción de la ilustración local_authentication_flow_LDAP.jpg

Una vez que el usuario introduce las credenciales y hace clic en el botón login, ocurre lo siguiente:

  1. DCC WebGate envía la solicitud HTTP que contiene las credenciales al servidor OAM, que las valida, crea una sesión para el usuario, crea una cookie y devuelve una respuesta HTTP con la cookie y un comando de redirección al DCC WebGate; el DCC WebGate define la cookie en el explorador del usuario y redirige al usuario al recurso protegido.

  2. El usuario solicita acceso al recurso. Esta vez, el agente de SSO WebGate detecta que el usuario está autenticado y otorga acceso al recurso

Descripción de la ilustración local_security_LDAPworkflow.jpg

Configuración del proxy inverso HTTP de DCC

Configuración inicial

Los pasos necesarios para configurar un despliegue de OAM para el proxy inverso HTTP de DCC se dividen en:

Para configurar un agente de SSO de WebGate específico como DCC WebGate, realice los siguientes pasos:

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

  2. Vaya a Access Manager, SSO Agents.

  3. Busque la entrada WebGate que ya se ha registrado.

  4. Haga clic y abra la entrada WebGate.

  5. Active la casilla Permitir operaciones de recopilador de credenciales.

  6. En el cuadro Parámetro definido por el usuario, agregue la siguiente línea: TunneledUrls=/oam,/oamfed.

  7. Haga clic en Aplicar.

Descripción de la ilustración Setting_DCC.jpg

Para actualizar las políticas de autenticación para los servicios OAM y OAM, realice los siguientes pasos:

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

  2. Vaya a Administrador de acceso, Dominios de aplicación.

  3. Busque el dominio de aplicación relacionado con el DCC WebGate.

  4. Abra el dominio de aplicación.

  5. Haga clic en el separador Recursos.

  6. Configure el siguiente recurso como recursos públicos, marcando los recursos como no protegidos y definiendo una política de autenticación pública y una política de autorización pública:

  7. Haga clic en Aplicar.

Descripción de la ilustración Authentication_Policies.jpg

Actualizar la configuración de OAM para especificar el DCC WebGate como el nuevo punto final público para OAM

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

  2. Vaya a Configuración, Configuración de Access Manager.

  3. En el host del servidor de OAM, introduzca el nombre de host que se utiliza para acceder al DCC WebGate mediante el explorador.

  4. En el puerto del servidor de OAM, introduzca el puerto que se utiliza para acceder al DCC WebGate mediante el explorador.

  5. En el protocolo de servidor OAM, introduzca el protocolo http que se utiliza para acceder al DCC WebGate a través del explorador.

  6. Una vez realizados, estos tres campos deben hacer referencia al punto final HTTP/HTTPS WebGate de DCC.

  7. Haga clic en Aplicar.

Descripción de la ilustración OAM_configuration.jpg

Una vez realizados los tres cambios de configuración, OAM y OAM se configuran para utilizar el DCC WebGate como proxy inverso HTTP mediante el protocolo NAP.

Como prueba, si se ha activado la federación en la sección Consola de administración de OAM, Servicios disponibles de configuración, puede acceder a los metadatos de OAM mediante la URL WebGate de DCC: http(s)://dcc-webgatehost:dcc-webgate-port/oamfed/idp/metadata y debe mostrar los metadatos de SAML 2.0 para OAM. En mi configuración, los metadatos se mostraron sin tener que reiniciar ningún servicio y las URL de los servicios de federación hacen referencia a la ubicación WebGate de DCC, no al servidor OAM.

Nota: si es necesario actualizar la federación ProviderID, puede hacerlo mediante la consola de administración de OAM, la configuración, la federación y el cambio se refleja en el atributo entityID de los metadatos.

Un ejemplo de los metadatos es (entityID se deriva de la Consola de administración de OAM, Configuración, Sección Federación):

<md:EntityDescriptor entityID="hUp://oam.acme.com
/oam/fed" ...>
  ...
  <md:IDPSSODescriptor>
    ...
    <md:ArtifactResolutionService ...
Location="hUp://dcc-webgate.acme.com:7777
/oamfed/idp/soap"/>
    <md:SingleLogoutService ... Location="hUp://dccwebgate.acme.com:7777/oamfed/idp/samlv20"/>     <md:SingleSignOnService ... Location="hUp://dccwebgate.acme.com:7777/oamfed/idp/samlv20"/>
    ...
  </md:IDPSSODescriptor>
  ...
</md:EntityDescriptor>

Identificación Local

En mi despliegue de prueba, tengo el siguiente despliegue:

LDAPScheme es el OOTB y no se ha modificado, específicamente el parámetro de URL de comprobación no hace referencia a WebGate DCC:

Descripción de la ilustración Local_Authentication.jpg

Antes de configurar OAM, OAM y WebGate2 para el proxy inverso HTTP de DCC, la solicitud de acceso al recurso protegido /cgi-bin/printenv en OHS1 tenía como resultado que WebGate1 intercepte la solicitud y redirija el explorador al servidor OAM para la autenticación:

Descripción de la ilustración Access_Manager_Screen.jpg

Al introducir las credenciales correctas, OAM estaba validando el nombre de usuario/contraseña y redirigiendo el explorador al recurso protegido.

Después de configurar OAM, OAM y WebGate2 para el proxy inverso HTTP de DCC, la solicitud de acceso al recurso protegido por /cgi-bin/printenv en OHS1 ahora da como resultado que WebGate1 intercepte la solicitud y redirija el explorador al DCC WebGate para la autenticación que reenvía la solicitud HTTP a través del protocolo NAP al servidor OAM que devuelve al DCC WebGate una página que se mostrará:

Descripción de la ilustración Protected_Access_Screen.jpg

Al introducir las credenciales correctas, ocurre lo siguiente:

OAM como SP

Este modo difiere ligeramente del caso de uso de autenticación local. Las únicas diferencias son:

Nota: No es necesaria ninguna configuración especial para utilizar FederationScheme con el proxy inverso HTTP de DCC.

FederationScheme es el OOTB y no se ha modificado, específicamente el parámetro de URL de comprobación no hace referencia a WebGate DCC:

Descripción de la ilustración Authentication_Schemes.jpg

Cuando se solicita el recurso protegido, ocurre lo siguiente:

  1. El usuario solicita acceso a un recurso protegido, definido en OAM para que esté protegido por FederationScheme.

  2. El agente de SSO WebGate intercepta la solicitud HTTP, determina que el usuario debe autenticarse y redirige al usuario al DCC WebGate para su autenticación.

  3. El usuario accede a DCC WebGate, que empaqueta las solicitudes HTTP y las envía a través de NAP al servidor OAM; el servidor determina que el usuario debe ser desafiado a través de FederationScheme y se llama al módulo OAM/SP.

  4. OAM/SP crea una solicitud SAML y crea una URL de redirección 302 con el mensaje SAML; OAM empaqueta los datos y envía la respuesta de nuevo al DCC WebGate, que devuelve la respuesta HTTP al explorador del usuario.

  5. El explorador del usuario se redirige a IdP con la solicitud de SAML

Descripción de la ilustración Protected_Resource_Request.jpg

Una vez que el usuario introduce sus credenciales en IdP, ocurre lo siguiente:

  1. IdP crea una afirmación de SAML y redirige el explorador del usuario con el mensaje SAML al DCC WebGate (que es el punto final de federación para OAM, publicado en los metadatos de SAML 2.0).

  2. El explorador del usuario presenta la afirmación de SAML al DCC WebGate, que empaqueta las solicitudes HTTP y las envía a través de NAP al servidor OAM, que a su vez llama al módulo OAM/SP para procesar la afirmación de SAML.

  3. OAM/SP valida la afirmación de SAML; OAM crea una sesión de usuario, crea un redireccionamiento 302 al recurso protegido y envía la respuesta de nuevo al DCC WebGate que devuelve la respuesta HTTP al explorador del usuario.

  4. Se redirige al usuario al recurso protegido

  5. WebGate El agente de SSO otorga acceso

Descripción de la ilustración local_security_Webgatedomain.jpg

OAM como IdP

En este caso de uso, OAM actúa como proveedor de identidad y DCC WebGate es el punto final público para IdP. En esta configuración:

Nota: No es necesaria ninguna configuración especial para utilizar IdP con el proxy inverso HTTP de DCC.

Cuando un usuario inicia una SSO de federación desde el SP remoto, ocurre lo siguiente:

  1. El usuario inicia una operación de SSO de federación en el SP remoto.

  2. El SP remoto crea una solicitud SAML y redirige al usuario al punto final de SAML 2.0 IdP con la solicitud SAML: este punto final es el proxy inverso HTTP WebGate de DCC, como se publica en los metadatos de SAML 2.0 IdP.

  3. El usuario accede al punto final de SAML 2.0 público IdP en el DCC WebGate con la solicitud SAML; el DCC WebGate empaqueta la solicitud HTTP y el mensaje SAML y lo reenvía al servidor IdP a través del protocolo NAP de OAM.

  4. El servidor IdP procesa la solicitud de SAML, determina que el usuario necesita autenticación a través de LDAPScheme, llama internamente a OAM para autenticación, que a su vez devuelve al DCC WebGate la página de conexión que se va a mostrar; el DCC WebGate descodifica la respuesta de OAM enviada por NAP y devuelve la respuesta HTTP al explorador del usuario.

Descripción de la ilustración local_security_FedSSO.jpg

Después de la visualización de la página de inicio de sesión, ocurre lo siguiente:

  1. El usuario introduce sus credenciales y hace clic en el botón login (Iniciar sesión).

  2. DCC WebGate recopila los datos entrantes, los empaqueta y los envía al servidor OAM a través de NAP.

  3. OAM valida las credenciales, crea una sesión para el usuario y devuelve internamente la identidad del usuario a IdP; el servidor de federación crea una afirmación de SAML y crea una respuesta que contiene la afirmación, la empaqueta y la devuelve al DCC WebGate, que a su vez descodifica los datos y envía la respuesta HTTP con la afirmación de SAML al explorador del usuario.

  4. El explorador del usuario publica la respuesta de SAML en el SP que valida correctamente la afirmación.

Descripción de la ilustración local_security_DCCWebgate.jpg

Proxy inverso HTTP de DCC y HA

En un despliegue de HA, los pasos necesarios para configurar los distintos componentes (Equilibrador de carga, OAM, etc.) se siguen aplicando cuando se utiliza la función de proxy inverso HTTP de DCC.

Tomemos como ejemplo el siguiente despliegue (otros tipos de topologías de alta disponibilidad utilizan un enfoque similar):

La topología de este ejemplo tiene el siguiente aspecto:

Descripción de la ilustración local_security_Topology.jpg

Los pasos necesarios en este ejemplo se basan en:

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.