Proxy de Reversão de HTTP de DCC com OAM e OAM

Este artigo discute o recurso Proxy Reverso HTTP do DCC (Detached Credential Collector) introduzido na versão 11.1.2.2.0.

Em uma implantação em que esse recurso está ativado, um Agente SSO WebGate:

Nesse modo, todas as interações entre os usuários/clientes e o OAM são feitas por meio do Proxy Reverso HTTP DCC WebGate: nenhum usuário acessará mais diretamente os servidores do OAM.

Esse novo recurso de Proxy Reverso HTTP do DCC é diferente do DCC anterior para log-in baseado em HTTPBasic/FORM, com o último a não funcionar para os fluxos de SSO da Federação (modo IdP ou SP).

Visão Geral

Este artigo não inclui nenhuma topologia contendo proxies reversos HTTP ou balanceador de carga na frente de vários componentes do OAM (o próprio servidor do OAM ou os agentes WebGate), mas inclui um caso de uso no final indicando como usar o Proxy Reverso HTTP DCC em implantações HA, liderado por um balanceador de carga.

Autenticação sem DCC

O fluxo de autenticação sem DCC é o caso de uso mais comum, em que o usuário é redirecionado dos agentes SSO que protegem recursos do domínio de segurança para o OAM para desafio e autenticação. Uma implantação típica do OAM é feita das seguintes entidades:

O diagrama a seguir descreve esse ambiente:

Descrição da ilustração local_security_domain.jpg

No fluxo de teste, use o OOTB LDAPScheme como o esquema para proteger os recursos do domínio de segurança local.

Um fluxo de autenticação local usando o LDAPScheme consiste no seguinte:

  1. O usuário solicita acesso a um recurso protegido, definido no OAM para ser protegido pelo LDAPScheme.

  2. O agente SSO WebGate intercepta a solicitação HTTP, determina que o usuário precisa ser autenticado e redireciona o usuário para o servidor do OAM para autenticação.

  3. O usuário acessa o servidor OAM; o servidor inicia um fluxo de autenticação usando o LDAPScheme e exibe a página de log-in

Descrição da ilustração local_authentication_flow.jpg

Quando o usuário informar suas credenciais e clicar no botão login, ocorrerá o seguinte:

  1. O servidor OAM valida as credenciais, cria uma sessão para o usuário, define um cookie no browser do usuário e redireciona o usuário para o recurso protegido.

  2. O usuário solicita acesso ao recurso. Desta vez, o Agente SSO WebGate detecta que o usuário está autenticado e concede acesso ao recurso

Descrição da ilustração local_security_workflow.jpg

DCC para login baseado em HTTP-Basic/FORM

O DCC para log-in baseado em HTTP-Basic/FORM foi introduzido em versões anteriores do OAM 11g e fornece uma forma de um administrador designar um Agente SSO WebGate como a entidade que:

No fluxo de teste, use o DCCLDAPScheme baseado no OOTB LDAPScheme, mas com o URL do Desafio atualizado para fazer referência ao DCC WebGate. Este esquema é usado para proteger os recursos do domínio de segurança local.

Um fluxo de autenticação local usando esse DCCLDAPScheme personalizado consiste no seguinte:

  1. O usuário solicita acesso a um recurso protegido, definido no OAM para ser protegido pelo DCCLDAPScheme.

  2. O agente SSO WebGate intercepta a solicitação HTTP, determina que o usuário precisa ser autenticado e redireciona o usuário para a página de log-in do DCC WebGate para autenticação.

  3. O usuário acessa a página de log-in do DCC WebGate e fornece credenciais.

  4. O DCC WebGate interage diretamente com o servidor do OAM, outro protocolo NAP do OAM para validar as credenciais e criar uma sessão para o usuário. O DCC WebGate então redireciona o usuário para o recurso protegido.

  5. O usuário solicita acesso ao recurso. Desta vez, o Agente SSO WebGate detecta que o usuário está autenticado e concede acesso ao recurso.

Proxy de Reversão de HTTP DCC

O Proxy Reverso HTTP do DCC foi introduzido na release 11.1.2.2.0 do OAM e permite que o administrador configure um Agente SSO WebGate para atuar como ponto final público para o servidor OAM e OAM:

Observação: Basicamente, o DCC WebGate torna-se o ponto final público do OAM e do OAM e atua como um Proxy Reverso HTTP, por meio do protocolo NAP do OAM.

Neste teste, após o OAM e o WebGate terem sido configurados para o Proxy Reverso HTTP do DCC, e usar o OOTB LDAPScheme como o esquema para proteger os recursos do domínio de segurança local (o esquema não será alterado).

Observação: Qualquer esquema de autenticação com um URL de Desafio contendo um caminho relativo pode ser usado nesse modo DCC, como FederationScheme. Além disso, o recurso IdP é compatível com esse modo DCC

Um fluxo de autenticação local usando o LDAPScheme consiste no seguinte:

  1. O usuário solicita acesso a um recurso protegido, definido no OAM para ser protegido pelo LDAPScheme.

  2. O agente SSO WebGate intercepta a solicitação HTTP, determina que o usuário precisa ser autenticado e redireciona o usuário para o DCC WebGate para autenticação.

  3. O usuário acessa o DCC WebGate e encaminha a solicitação ao servidor do OAM; o servidor inicia um fluxo de autenticação usando o LDAPScheme, retorna uma página de log-in a ser exibida para o DCC WebGate e o DCC WebGate exibe a página de log-in para o usuário.

Descrição da ilustração local_authentication_flow_LDAP.jpg

Quando o usuário informa credenciais e clica no botão login, ocorre o seguinte:

  1. O DCC WebGate envia a solicitação HTTP contendo as credenciais para o servidor OAM que as valida, cria uma sessão para o usuário, cria um cookie e retorna uma Resposta HTTP com o cookie e um comando de redirecionamento para o DCC WebGate; o DCC WebGate define o cookie no browser do usuário e redireciona o usuário para o recurso protegido.

  2. O usuário solicita acesso ao recurso. Desta vez, o Agente SSO WebGate detecta que o usuário está autenticado e concede acesso ao recurso

Descrição da ilustração local_security_LDAPworkflow.jpg

Configurando Proxy Reverso HTTP DCC

Configuração Inicial

As etapas necessárias para configurar uma implantação do OAM para o Proxy Reverso HTTP do DCC são divididas em:

Para configurar um Agente SSO WebGate específico como um WebGate DCC, execute as seguintes etapas:

  1. Vá para a Console de Administração do OAM: http(s)://oam-admin-host:oam-adminport/oamconsole.

  2. Navegue até Gerenciador de Acesso, Agentes SSO.

  3. Procure a entrada WebGate que você já registrou.

  4. Clique e abra a entrada WebGate.

  5. Marque a caixa Permitir Operação do Coletor de Credenciais.

  6. Na caixa Parâmetro Definido pelo Usuário, adicione a seguinte linha: TunneledUrls=/oam,/oamfed.

  7. Clique em Aplicar.

Descrição da ilustração Setting_DCC.jpg

Para atualizar as Políticas de Autenticação dos serviços OAM e OAM, execute as seguintes etapas:

  1. Vá para a Console de Administração do OAM: http(s)://oam-admin-host:oam-adminport/oamconsole.

  2. Navegue até Access Manager, Domínios de Aplicativos.

  3. Procure o Domínio do Aplicativo relacionado ao DCC WebGate.

  4. Abra o Domínio do Aplicativo.

  5. Clique na tab Recursos.

  6. Configure o seguinte recurso como Recursos públicos, marcando os recursos como Não Protegidos e definindo uma política de autenticação pública e uma política de autorização pública:

  7. Clique em Aplicar

Descrição da ilustração Authentication_Policies.jpg

Para atualizar a configuração do OAM para especificar o DCC WebGate como o novo ponto final público do OAM

  1. Vá para a Console de Administração do OAM: http(s)://oam-admin-host:oam-adminport/oamconsole.

  2. Navegue até Configuração, Definições do Access Manager.

  3. No Host do Servidor do OAM, informe o nome do host usado para acessar o DCC WebGate via browser.

  4. Na Porta do Servidor do OAM, informe a porta usada para acessar o DCC WebGate via browser.

  5. No Protocolo do Servidor do OAM, informe o protocolo http usado para acessar o DCC WebGate via browser.

  6. Uma vez concluído, esses três campos devem fazer referência ao ponto final HTTP/HTTPS DCC WebGate.

  7. Clique em Aplicar.

Descrição da ilustração OAM_configuration.jpg

Quando as três alterações de configuração forem feitas, o OAM e o OAM serão configurados para usar o DCC WebGate como o Proxy Reverso HTTP sobre o protocolo NAP.

Como teste, se a federação tiver sido ativada na seção Console de Administração do OAM, Serviços de Configuração Disponíveis, você poderá acessar os metadados do OAM por meio do URL WebGate do DCC: http(s)://dcc-webgatehost:dcc-webgate-port/oamfed/idp/metadata e deverá exibir os Metadados SAML 2.0 para o OAM. Na minha configuração, os Metadados apareceram sem precisar reiniciar nenhum serviço, e os URLs dos serviços da Federação referenciam a localização WebGate do DCC, não o servidor OAM mais.

Observação: se a Federação ProviderID precisar ser atualizada, você poderá fazer isso por meio da Console de Administração do OAM, Configuração, Federação e a alteração será refletida no atributo entityID dos Metadados.

Um exemplo dos metadados é (entityID é derivado da Console de Administração do OAM , Configuração , seção Federação):

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

Autenticação Local

Na minha implantação de teste, tenho o seguinte implantado:

O LDAPScheme é o OOTB e não foi modificado, especificamente o parâmetro URL do Desafio não faz referência ao DCC WebGate:

Descrição da ilustração Local_Authentication.jpg

Antes de configurar o OAM, o OAM e o WebGate2 para Proxy Reverso HTTP DCC, a solicitação de acesso ao recurso protegido /cgi-bin/printenv em OHS1 estava resultando em WebGate1 interceptando a solicitação e redirecionando o browser para o servidor do OAM para autenticação:

Descrição da ilustração Access_Manager_Screen.jpg

Ao informar as credenciais corretas, o OAM validava o nome de usuário/senha e redirecionava o browser para o recurso protegido.

Depois de configurar o OAM, o OAM e o WebGate2 para Proxy Reverso HTTP DCC, solicitar acesso ao recurso protegido /cgi-bin/printenv em OHS1 agora resulta em WebGate1 interceptando a solicitação e redirecionando o browser para o DCC WebGate para autenticação que encaminha a solicitação HTTP pelo protocolo NAP para o servidor do OAM que envia de volta para o DCC WebGate uma página a ser exibida:

Descrição da ilustração Protected_Access_Screen.jpg

Ao informar as credenciais corretas, ocorre o seguinte:

OAM como SP

Esse modo difere um pouco do caso de uso de autenticação local. As únicas diferenças são:

Observação: nenhuma configuração especial é necessária para usar FederationScheme com o Proxy Reverso HTTP DCC!

O FederationScheme é o OOTB e não foi modificado, especificamente o parâmetro URL do Desafio não faz referência ao DCC WebGate:

Descrição da ilustração Authentication_Schemes.jpg

Quando o recurso protegido é solicitado, o seguinte ocorre:

  1. O usuário solicita acesso a um recurso protegido, definido no OAM para ser protegido pelo FederationScheme.

  2. O agente SSO WebGate intercepta a solicitação HTTP, determina que o usuário precisa ser autenticado e redireciona o usuário para o DCC WebGate para autenticação.

  3. O usuário acessa o DCC WebGate, que compacta as solicitações HTTP e as envia por NAP ao servidor OAM; o servidor determina que o usuário precisa ser desafiado por meio do FederationScheme e o módulo OAM/SP é chamado.

  4. O OAM/SP cria uma Solicitação SAML e cria um URL de redirecionamento 302 com a mensagem SAML; o OAM compacta os dados e envia a resposta de volta para o DCC WebGate, que retorna a resposta HTTP para o browser do usuário.

  5. O browser do usuário é redirecionado para IdP com a Solicitação SAML

Descrição da ilustração Protected_Resource_Request.jpg

Depois que o usuário informa suas credenciais em IdP, ocorre o seguinte:

  1. O IdP cria uma Asserção SAML e redireciona o browser do usuário com a mensagem SAML para o DCC WebGate (que é o ponto final da Federação para o OAM, publicado nos Metadados SAML 2.0).

  2. O browser do usuário apresenta a Asserção SAML para o DCC WebGate, que empacota as solicitações HTTP e as envia por NAP para o servidor OAM, que, por sua vez, chama o módulo OAM/SP para processar a Asserção SAML.

  3. O OAM/SP valida a Asserção SAML, o OAM cria uma sessão de usuário, cria um redirecionamento 302 para o recurso protegido e envia a resposta de volta para o DCC WebGate, que retorna a resposta HTTP para o browser do usuário.

  4. O usuário é redirecionado para o recurso protegido

  5. WebGate O Agente SSO concede acesso

Descrição da ilustração local_security_Webgatedomain.jpg

OAM como um IdP

Nesse caso de uso, o OAM atua como um Provedor de Identidades e o DCC WebGate é o ponto final público do IdP. Nesta configuração:

Observação: nenhuma configuração especial é necessária para usar IdP com o Proxy Reverso HTTP DCC!

Quando um usuário inicia um SSO de Federação do SP remoto, ocorre o seguinte:

  1. O usuário inicia uma operação SSO de Federação no SP remoto.

  2. O SP remoto cria uma Solicitação SAML e redireciona o usuário para o ponto final IdP SAML 2.0 com a Solicitação SAML: esse ponto final é o Proxy Reverso HTTP WebGate do DCC, conforme publicado nos Metadados SAML 2.0 IdP.

  3. O Usuário acessa o ponto final IdP público SAML 2.0 no DCC WebGate com a Solicitação SAML; o DCC WebGate empacota a Solicitação HTTP e a mensagem SAML e a encaminha ao servidor IdP pelo protocolo NAP do OAM.

  4. O servidor IdP processa a Solicitação SAML, determina que o usuário precisa ser autenticado por meio do LDAPScheme, chama internamente o OAM para autenticação, que por sua vez retorna ao DCC WebGate a página de log-in a ser exibida; o DCC WebGate decodifica a resposta do OAM enviada por NAP e retorna a resposta HTTP ao browser do usuário.

Descrição da ilustração local_security_FedSSO.jpg

Após a exibição da página de login, ocorre o seguinte:

  1. O usuário informa suas credenciais e clica no botão log-in.

  2. O DCC WebGate coleta os dados de entrada, os compacta e os envia para o servidor OAM por meio do NAP.

  3. O OAM valida as credenciais, cria uma sessão para o usuário e retorna internamente a identidade do usuário para IdP; o servidor de Federação cria uma Asserção SAML e cria uma resposta contendo a Asserção, compacta-a e a retorna para o DCC WebGate, que, por sua vez, decodifica os dados e envia a Resposta HTTP com a Asserção SAML para o browser do usuário.

  4. O navegador do usuário publica a Resposta SAML no SP, que valida com sucesso a Asserção.

Descrição da ilustração local_security_DCCWebgate.jpg

Proxy reverso DCC HTTP e HA

Em uma implantação de HA, as etapas necessárias para configurar os diversos componentes (Balanceador de carga, OAM...) ainda se aplicam quando o recurso Proxy Reverso HTTP DCC é usado.

Vamos dar um exemplo da seguinte implantação (outros tipos de topologias HA usam uma abordagem semelhante):

A topologia deste exemplo tem a seguinte aparência:

Descrição da ilustração local_security_Topology.jpg

As etapas necessárias neste exemplo são baseadas em:

Mais Recursos de Aprendizagem

Explore outros laboratórios em docs.oracle.com/learn ou acesse mais conteúdo de aprendizado gratuito no canal YouTube do Oracle Learning. Além disso, visite education.oracle.com/learning-explorer para se tornar um Oracle Learning Explorer.

Para obter a documentação do produto, visite o Oracle Help Center.