Proxy de Federação no OAM e IdP
Este artigo explica o conceito de Proxy de Federação e como IdP pode ser facilmente configurado para se tornar um SP e delegar autenticação a outro IdP remoto, em vez de autenticar o usuário localmente.
O Proxy de Federação geralmente é usado quando um hub de Federação atua como:
-
Um IdP para Parceiros SP, em que o IdP agrega confiança de Federação entre esses SPs e ele mesmo
-
Um SP com Parceiros IdP remotos
Esta abordagem tem a vantagem de:
-
Redução da sobrecarga do gerenciamento da confiança
-
Cada novo Parceiro IdP adicionado ao hub Federação estará automaticamente disponível para todos os parceiros SP integrados ao hub Federação
-
Cada novo Parceiro SP adicionado ao hub da Federação não precisará ser definido nos Parceiros IdP
-
Fornecendo um modelo confiável de Federação em camadas, em que o hub da Federação oculta a implantação da Federação para os Parceiros IdP
Modelo de Confiança Direta
Neste modelo, os vários servidores da Federação confiam uns nos outros diretamente e não há entidades intermediárias atuando como proxy.
Esse modelo tem a vantagem de reduzir a complexidade dos fluxos de Federação, pois apenas dois servidores estão envolvidos com a operação SSO, mas às vezes tem a desvantagem de criar uma enorme sobrecarga de gerenciamento com a qual os parceiros podem não concordar.
Vamos dar um exemplo de uma empresa global chamada ACME Corp, que tem escritórios em todo o mundo. A estrutura da empresa é composta por três organizações principais que representam uma região diferente do mundo, e cada organização é responsável por seu domínio de segurança:
- Norte e Sulamericano
- Europeu
- Ásia-África-Pacífico
Cada organização tem seu próprio domínio de segurança, o que significa:
- Um conjunto de recursos
- Um servidor SSO
- Um servidor de Federação As entidades de uma organização são independentes das de outra organização. Como tal, ser autenticado em um domínio não concederá acesso a recursos de outro domínio até que a autenticação tenha sido executada nesse outro domínio.
Agora, digamos que a ACME Corp queira ter um acordo de Federação com alguns Provedores de Serviços, alguns dos quais são fornecedores, outros são serviços adquiridos pela ACME Corp, como um serviço Conference Call e um serviço Webex.
Para estabelecer a Federação entre as várias organizações ACME Corp e os SPs, o servidor de Federação de cada organização deve estabelecer confiança com cada SP remoto:
-
O número de estabelecimentos de confiança deve ser alto
-
Os Parceiros de SP podem se recusar a esse tipo de estabelecimento de confiança, dado o alto número de acordos de Federação envolvidos para um único cliente
Este diagrama representa todos os acordos que precisariam ser implementados:
Descrição da ilustração Direct_Trust_Model.jpg
Essa abordagem geralmente é evitada porque publica para o parceiro a complexidade interna da infraestrutura da ACME Corp.
O SSO e SAML da federação foram definidos para permitir que dois domínios de segurança distintos executem o SSO de domínio cruzado de forma que um parceiro não precisasse saber sobre a implementação e a implantação de segurança do outro parceiro. Neste caso, torna-se óbvio que esta promessa está quebrada e que a complexidade das opções de segurança da ACME Corp está impactando os parceiros do SP.
Modelo de Confiança Corrigido
Neste modelo, há o conceito de Proxy de Federação no qual algumas entidades devem ser usadas para atuar como proxies/SPs para executar operações de SSO de Federação em nome de outros SPs.
Se dermos um exemplo da ACME Corp novamente, a abordagem correta para implementar o Federation SSO com outros parceiros SP é feita por meio de um modelo Brokered Trust ou Federation Proxy, em que:
-
Um novo servidor será instalado na ACME Corp atuando como um hub de Federação
-
O Federation Hub atua como um Provedor de Serviços para o IdPs interno da ACME Corp
-
O Federation Hub atua como um IdP para os SPs externos (fornecedores, teleconferência e webex)
-
Durante uma operação SSO de Federação, em vez de desafiar o usuário diretamente, o hub atua como um SP e aciona uma operação SSO de Federação com um IdP interno remoto
Essa abordagem está mais de acordo com a filosofia Federação/SAML, em que os parceiros externos desconhecem a infraestrutura de segurança e os componentes da ACME Corp e interagem apenas com um único IdP.
Essa solução também resolve os altos custos gerais de gerenciamento, em que o número de acordos era particularmente alto, e estava tornando qualquer atualização no acordo um processo demorado. Com essa abordagem:
-
Os acordos de federação estão entre o hub e o IdPs interno e entre o hub e SPs externos
-
A adição de um IdP interno ficará invisível aos SPs externos
-
A adição de um SP externo ficará invisível ao IdPs interno
-
A atualização do acordo de Federação (por exemplo, rollover de chave) será uma operação única, em vez de ser repetida várias vezes
Este diagrama representa os acordos de Federação necessários em um modelo de Confiança Corrigida (ou Proxy de Federação):
Descrição da ilustração Brokered_Trust_Model.jpg
Proxy de Federação no OAM
O objetivo em um Proxy de Federação é transformar o IdP em um SP para que, ao receber uma solicitação de SSO de um primeiro SP remoto, em vez de desafiar o usuário localmente, o IdP se torne um SP e acione uma nova operação de SSO de Federação com um segundo IdP remoto.
Após a conclusão bem-sucedida da segunda operação SSO de Federação, o proxy IdP identificará o usuário e poderá criar uma resposta SSO para o SP original.
O OAM suporta o Proxy de Federação Agora para todos os protocolos:
-
SAML 2.0, SAML 1.1 e OpenID 2.0
-
O protocolo entre o SP original e IdP é o mesmo usado entre o OAM/SP e o segundo IdP remoto
-
O protocolo entre o SP original e IdP é diferente do usado entre o OAM/SP e o segundo IdP remoto
Portanto, seria possível que um SP fizesse SSO de Federação com IdP via SAML 1.1 e IdP se tornasse um SP e fizesse SSO de Federação com um segundo IdP remoto via SAML 2.0. O SP original não precisaria saber o protocolo usado entre o OAM/SP e o segundo IdP, ou mesmo que uma segunda operação de SSO de Federação ocorresse.
Em um Proxy de Federação Agora, IdP pode ser configurado para "encaminhar" o Método de Autenticação de Federação especificado no segundo SSO de Federação para o SP original.
Configurando o OAM para Proxy de Federação
Conforme discutido anteriormente, o IdP aproveita o OAM para autenticação do usuário: toda vez que uma operação de SSO de Federação ocorre, o IdP chama o OAM especificando um Esquema de Autenticação, para garantir que o usuário seja autenticado adequadamente e desafiá-lo, se necessário.
Como você sabe, o OAM define esquemas específicos vinculados ao OAM/SP: se um usuário não autenticado solicitar acesso a um recurso protegido por um FederationScheme
(ou esquema que usa um Módulo de Autenticação semelhante ao FederationPlugin
), o OAM chamará o OAM/SP que dispara uma operação SSO de Federação com um IdP remoto.
Portanto, para que IdP execute um Proxy de Federação Agora, em vez de ter IdP chamado o OAM com um Esquema de Autenticação local, você deve ter IdP chamado o OAM com um FederationScheme
. Lá:
-
O OAM chama o OAM/SP e aciona um novo SSO de Federação Agora com um segundo IdP remoto
-
O segundo IdP remoto autentica o usuário, se necessário, emita uma resposta de SSO
-
O OAM/SP valida a resposta do SSO; crie uma sessão do OAM
-
O OAM redireciona o usuário para IdP
-
IdP cria uma resposta SSO e redireciona o usuário para o SP original com essa resposta
Comando WLST
Para configurar IdP para usar o SSO de Federação para autenticar um usuário em vez de um mecanismo de autenticação local, execute um dos seguintes comandos:
-
setIdPDefaultScheme()
para definir o esquema padrão global como um Esquema de Federação -
setSPPartnerProfileDefaultScheme()
para definir o esquema padrão em um Perfil do Parceiro SP -
setSPPartnerDefaultScheme()
para definir o esquema padrão em um Parceiro SP
Consulte o artigo sobre Autenticação em IdP para obter mais informações sobre como configurar o OAM para autenticação. Neste exemplo, configure IdP globalmente para usar o SSO de Federação como mecanismo de autenticação padrão:
-
Informe o ambiente WLST executando:
$IAM_ORACLE_HOME/common/bin/wlst.sh
. -
Conecte-se ao servidor de Administração WLS:
connect()
. -
Navegue até a ramificação Runtime do Domínio:
domainRuntime()
. -
Execute o comando
setIdPDefaultScheme()
:setIdPDefaultScheme("FederationScheme")
. -
Saia do ambiente WLST:
exit()
.
Com essa alteração, FederationScheme
é usado para autenticar usuários.
Outros Esquemas de Federação podem ser usados para autenticar o usuário, com o OAM sendo configurado no nível global (todos os usuários de todos os SPs são autenticados usando esse Esquema de Federação) ou no nível do Parceiro SP (todos os usuários que executam o SSO de Federação com esse SP específico são autenticados usando esse Esquema de Federação). Lembre-se de que você pode criar um Esquema de Federação para um IdP específico, por meio do comando WLST createAuthnSchemeAndModule
do OAM ou pela seção Editar Parceiro IdP na Console de Administração do OAM.
Determinando o Segundo IdP a ser usado
Quando um Esquema de Federação for usado para autenticação no OAM, o OAM/SP precisará determinar qual IdP usar para a operação SSO de Federação:
-
Se o esquema foi criado com base em uma entrada do Parceiro IdP, ele indicará ao OAM/SP para executar SSO de Federação com esse IdP
-
Se o esquema for
FederationScheme
, o OAM/SP primeiro avalia se está configurado para usar um Serviço de Descoberta IdP -
Se ele estiver configurado para um Serviço de Descoberta IdP, o OAM/SP redirecionará o usuário para esse serviço para selecionar um IdP
-
Caso contrário, o OAM/SP usará o SSO Padrão IdP
Para definir um Parceiro IdP como o SSO Padrão IdP:
-
Vá para o Parceiro IdP na Console de Administração do OAM e marque a caixa Parceiro do Provedor de Identidades Padrão
-
Ou use o comando WLST setDefaultSSOIdPPartner() do OAM especificando o nome do Parceiro IdP
Proxiesando Métodos de Autenticação de Federação
Conforme explicado em um artigo anterior, quando IdP constrói uma Asserção, ele mapeia o esquema do OAM local usado para autenticar o usuário em um Método de Autenticação da Federação.
No caso de um Proxy de SSO de Federação Agora, isso significa que um FederationScheme
está mapeado para um Método de Autenticação de Federação. Por exemplo, se o esquema precisar ser mapeado para urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
para SAML 2.0, o administrador usará um comando semelhante a:
-
Para criar o mapeamento em um nível de Perfil do Parceiro SP:
addSPPartnerProfileAuthnMethod("saml20-sppartner-profile","urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport", "FederationScheme")
-
Para criar o mapeamento em um nível de Parceiro SP:
addSPPartnerAuthnMethod("AcmeSP","urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport ", "FederationScheme")
Em alguns casos, pode ser preferível encaminhar o Método de Autenticação de Federação recebido do segundo IdP, em vez de mapear localmente o Esquema de Federação para um Método de Autenticação de Federação.
Para configurar IdP para encaminhar os Métodos de Autenticação de Federação em um Proxy SSO de Federação.
Agora, use o comando useProxiedFedAuthnMethod()
:
-
Informe o ambiente WLST executando:
$IAM_ORACLE_HOME/common/bin/wlst.sh
. -
Conecte-se ao servidor de Administração WLS:
connect()
. -
Navegue até a ramificação Runtime do Domínio:
domainRuntime()
. -
Execute o comando
useProxiedFedAuthnMethod()
:useProxiedFedAuthnMethod(enabled="true/false",authnSchemeToAdd="SCHEME", authnSchemeToRemove="SCHEME")
. -
O parâmetro ativado indica se IdP deve ou não ser configurado para encaminhar os Métodos de Autenticação de Federação em um Proxy SSO de Federação Agora
-
O parâmetro
authnSchemeToAdd
indica qual Esquema de Autenticação do OAM é um Esquema de Federação: isso permite que IdP determine se deve ou não usar o Método de Autenticação de Federação armazenado no cache com base no esquema de autenticação da sessão do usuário -
O parâmetro
authnSchemeToRemove
remove um Esquema de Autenticação do OAM da lista de esquemas marcados como Esquemas de Federação para os quais IdP deve usar o Método de Autenticação de Federação com proxy -
Um exemplo é:
useProxiedFedAuthnMethod(enabled="true", authnSchemeToAdd="FederationScheme")
- Saia do ambiente WLST:
exit()
.
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.
Federation Proxy in OAM and IdP
F60446-01
September 2022
Copyright © 2022, Oracle and/or its affiliates.