SP vs. IdP SSO Iniciado

Este artigo discute sobre os conceitos de SP e IdP SSO Iniciado entre duas implantações da Federação e quais são as diferenças entre esses dois fluxos.

Este artigo também explica o conceito de um estado do usuário ou um URL de retorno compartilhado entre o IdP e o SP durante o SSO de Federação, que é chamado de:

• RelayState para SAML 2.0 TARGET para SAML 1.1 wctx para WS-Fed 1.1

• openid.return_to para OpenID 2.0 (o SSO de devolução

• O URL pode conter um parâmetro de consulta que representa o estado do usuário no SP)

Este artigo mostra exemplos usando o protocolo SAML 2.0, embora o mesmo se aplique aos outros protocolos.

Fluxos de SSO da Federação

Topologia

Uma implantação típica da Federação é feita das seguintes entidades:

• Um domínio de segurança para o Servidor IdP, no qual o usuário tem uma conta e no qual ocorre autenticação

• Um domínio de segurança para o servidor SP com

  • Um Servidor de Federação SP

  • Um servidor SSO (às vezes, o Servidor SSO e o Servidor de Federação SP são a mesma entidade)

  • Agentes Web de SSO integrados ao Servidor SSO, protegendo recursos e garantindo que o usuário seja autenticado e autorizado a acessar um recurso. A falha em fazer isso pode resultar em um fluxo de autenticação ou em uma falha de autorização

  • Recursos ou Aplicativos Web

  

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

SSO Iniciado por SP

Um fluxo de SSO Iniciado pelo SP é uma operação de SSO de Federação que foi iniciada a partir do Domínio de Segurança do SP pelo servidor de Federação do SP, criando uma Solicitação de Autenticação de Federação e redirecionando o usuário para IdP com a mensagem e alguma string curta representando o estado da operação:

• A Solicitação de Autenticação de Federação varia dependendo do protocolo usado:

  • SAML 2.0: AuthnRequest

  • SAML 1.1: um URL com um parâmetro que representa o SP

  • WS-Fed: um URL com um parâmetro wtrealm representando o SP e outros parâmetros opcionais

  • OpenID 2.0: Solicitação OpenID 2.0

• O estado da operação (o que o usuário estava fazendo antes do início da operação SSO da Federação) é transmitido na mensagem enviada ao IdP com o usuário, não como o estado inteiro, mas como um ponteiro para o estado no armazenamento de runtime do Servidor SP. Essas informações são transmitidas de maneira diferente, dependendo do protocolo:

  • SAML 2.0: parâmetro RelayState

  • SAML 1.1: Parâmetro TARGET

  • WS-Fed: parâmetro wctx

  • OpenID 2.0: parâmetro openid.return_to, que é um URL do SP, para o qual o usuário é redirecionado após a autenticação em IdP, que é gerada no runtime pelo SP e, como tal, pode conter um parâmetro de consulta que faz referência a um estado operacional

Observação sobre o estado operacional: Geralmente, o estado compartilhado na mensagem não deve ser muito longo, pois pode quebrar os fluxos de redirecionamento com o tamanho do URL de redirecionamento que excede o tamanho máximo que os navegadores podem tratar para URLs. Como tal, é sempre preferível durante o SSO Iniciado pelo SP ter o SP

• Armazene o estado operacional no armazenamento de memória/DB no SP

• Envie como RelayState/TARGET/wctx um ponteiro para o estado operacional

Há duas maneiras de acionar um fluxo de SSO Iniciado pelo SP:

• O usuário solicita acesso a um recurso, que inicia um fluxo de SSO de Federação. Depois que a operação SSO de Federação for executada, o usuário será redirecionado de volta para o recurso solicitado em primeiro lugar.

• Ou o usuário acessa diretamente um serviço no servidor SP para iniciar especificamente um fluxo de SSO de Federação com um IdP remoto. Nesse caso, o usuário normalmente fornece o URL para o qual o usuário deve ser redirecionado após a operação SSO da Federação ser executada

Acessando um Recurso

Esse é o fluxo mais comum para operações de SSO de Federação, em que o usuário tenta acessar um recurso protegido, e o sistema SSO no runtime determina que o usuário precisa ser autenticado via SSO de Federação.

Os casos de uso em que esse fluxo é usado podem ser:

• O usuário clica em um link em qualquer página que faça referência ao recurso protegido

• O usuário clica em um link em uma página do portal que faz referência ao recurso protegido

• O usuário tem um marcador para o recurso protegido

O fluxo envolve as seguintes etapas:

1. Acesso de solicitação do browser do usuário a um recurso protegido

2. O Agente da Web SSO intercepta a chamada, determina que o usuário precisa ser autenticado e emite um redirecionamento de volta para o browser do usuário

3. O browser do usuário acessa o servidor SSO, sendo redirecionado pelo Agente Web SSO

4. O Servidor SSO determina que o usuário deve ser autenticado via SSO de Federação, seleciona um IdP, cria uma mensagem SAML 2.0 AuthnRequest, salva o estado operacional no armazenamento do servidor SSO e redireciona o browser do usuário para o IdP com a mensagem SAML e uma string que faz referência ao estado operacional no SP

5. O browser do usuário acessa o serviço IdP SAML 2.0 com a mensagem AuthnRequest.

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

Depois que o IdP recebe a mensagem SAML 2.0 AuthnRequest, o servidor determina se o usuário precisa ser desafiado (ainda não autenticado, a sessão expirou...). Após a possível identificação do usuário, o fluxo SSO da Federação é retomado.

1. O IdP cria uma Resposta SSO com uma Asserção SAML 2.0 contendo informações do usuário, bem como dados de autenticação, e redireciona o browser do usuário para o SP com a mensagem e o parâmetro RelayState

2. O browser do usuário apresenta a resposta SSO ao servidor SP

3. O SP valida a Asserção SAML 2.0 e cria uma sessão SSO para o usuário. Em seguida, o servidor SSO redireciona o browser do usuário de volta para o recurso solicitado originalmente

4. O browser do usuário solicita acesso ao recurso. Desta vez, o Agente Web SSO concede acesso ao recurso

5. O Aplicativo Web retorna uma resposta ao browser do usuário

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

Como mencionado anteriormente, esse fluxo é o mais usado, pois o SSO da Federação só é acionado pelo servidor SSO no runtime, sem que outros componentes do Domínio de Segurança do SP precisem estar cientes da Federação.

Chamando um Serviço SP de Federação

Esse fluxo não é amplamente usado, pois implica que o SSO de Federação será iniciado no SP, acessando um serviço no servidor SP e ignorando qualquer sessão válida existente que o usuário já possa ter. Como tal, deve ser evitado, pois causa um impacto no desempenho em:

• Os servidores como SSO de Federação são caros (XML para alguns protocolos, assinaturas digitais para proteger as mensagens, comunicações entre servidores)

• A experiência do usuário como navegador será redirecionada em diferentes domínios, resultando em atraso para que o usuário possa obter acesso ao recurso protegido direcionado.

Os casos de uso em que esse fluxo é usado podem ser:

• O usuário clica em um link em qualquer página que faça referência ao recurso protegido (não habitual)

• O usuário clica em um link em uma página do portal que faz referência ao recurso protegido

Os casos de uso em que esse fluxo é usado envolvem as seguintes etapas:

1. O browser do usuário acessa o SP para iniciar um fluxo de SSO de Federação especificando opcionalmente

   1. O URL para o qual o browser do usuário deve ser redirecionado após a conclusão do SSO de Federação

   2. O IdP a ser usado

2. O Servidor SSO seleciona um IdP se não for fornecido e seleciona o URL de retorno padrão se não for fornecido, cria uma mensagem SAML 2.0 AuthnRequest, salva o estado operacional no armazenamento do servidor SSO e redireciona o browser do usuário para o IdP com a mensagem SAML e uma string que faz referência ao estado operacional no SP

3. O browser do usuário acessa o serviço IdP SAML 2.0 com a mensagem AuthnRequest.

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

Depois que o IdP recebe a mensagem SAML 2.0 AuthnRequest, o servidor determina se o usuário precisa ser desafiado (ainda não autenticado, a sessão expirou...). Após a possível identificação do usuário, o fluxo SSO da Federação é retomado:

1. O IdP cria uma Resposta SSO com uma Asserção SAML 2.0 contendo informações do usuário, bem como dados de autenticação, e redireciona o browser do usuário para o SP com a mensagem e o parâmetro RelayState

2. O browser do usuário apresenta a resposta SSO ao servidor SP

3. O SP valida a Asserção SAML 2.0 e cria uma sessão SSO para o usuário. Em seguida, o servidor SSO redireciona o browser do usuário de volta para o recurso solicitado originalmente

4. O browser do usuário solicita acesso ao recurso. Desta vez, o Agente Web SSO concede acesso ao recurso

5. O Aplicativo Web retorna uma resposta ao browser do usuário

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

Esse fluxo raramente deve ser usado, pois o SSO de Federação é acionado estaticamente, mesmo se o usuário já tiver uma sessão SSO válida. Além disso, isso implica que alguns componentes do Domínio de Segurança do SP estejam cientes do serviço SP.

IdP SSO Iniciado

Um fluxo de SSO Iniciado IdP é uma operação de SSO de Federação que foi iniciada no Domínio de Segurança IdP pelo servidor de Federação IdP que cria uma Resposta de SSO de Federação e redireciona o usuário para o SP com a mensagem de resposta e um estado operacional opcional:

• A Resposta de SSO da Federação varia dependendo do protocolo usado:

  • SAML 2.0: SAMLResponse com asserção

  • SAML 1.1: Resposta com Asserção

  • WS-Fed: Resposta com Asserção

  • OpenID 2.0: Resposta OpenID 2.0

• O estado de operação opcional nesse fluxo transmite o URL para o qual o usuário deve ser redirecionado após a conclusão do SSO de Federação no SP. Se estiver ausente, o SP deverá determinar para onde o usuário deverá ser redirecionado. Essas informações são transmitidas de maneira diferente, dependendo do protocolo:

  • SAML 2.0: parâmetro RelayState

  • SAML 1.1: parâmetro TARGET

  • WS-Fed: parâmetro wctx OpenID 2.0: esse protocolo não suporta o fluxo de SSO Iniciado IdP.

Como observado na seção anterior, o estado compartilhado na mensagem não deve ser muito longo, pois pode quebrar os fluxos de redirecionamento com o tamanho do URL de redirecionamento que excede o tamanho máximo que os navegadores podem tratar para URLs.

Esse fluxo geralmente é usado quando os usuários IdP precisam acessar recursos hospedados por um SP, mas não é a melhor abordagem para o SSO de Federação, pois desconsidera qualquer sessão válida existente no SP que o usuário já poderia ter. Como tal, deve ser evitado, pois causa um impacto no desempenho em:

• Os servidores como SSO de Federação são caros (XML para alguns protocolos, assinaturas digitais para proteger as mensagens, comunicações entre servidores)

• A experiência do usuário como navegador será redirecionada em diferentes domínios, resultando em atraso para que o usuário possa obter acesso ao recurso protegido direcionado.

Os casos de uso em que esse fluxo é usado podem ser:

• O usuário clica em um link em uma página do portal IdP que faz referência ao recurso protegido no SP.

Os casos de uso em que esse fluxo é usado envolvem as seguintes etapas:

1. O browser do usuário acessa o IdP para iniciar um fluxo SSO de Federação especificando

   1. O SP a ser usado

   2. Opcionalmente, o URL para o qual o browser do usuário deve ser redirecionado após a conclusão do SSO de Federação

2. Depois de ter identificado o usuário, o IdP cria uma Resposta SSO com uma Asserção SAML 2.0 contendo informações do usuário, bem como dados de autenticação, e redireciona o browser do usuário para o SP com a mensagem e o parâmetro RelayState

3. O browser do usuário apresenta a resposta SSO ao servidor SP

4. O SP valida a Asserção SAML 2.0 e cria uma sessão SSO para o usuário. Em seguida, o servidor SSO redireciona o browser do usuário de volta para o recurso solicitado originalmente

5. O browser do usuário solicita acesso ao recurso. Desta vez, o Agente Web SSO concede acesso ao recurso

6. O Aplicativo Web retorna uma resposta ao browser do usuário

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

Conclusão

Como visto nos vários fluxos, a melhor abordagem em uma implantação de Federação é que o SSO de Federação seja acionado pelo servidor SSO, no runtime, quando ele for considerado obrigatório pelo servidor SSO. Os outros casos têm uma abordagem estática e sempre exercem um fluxo de SSO da Federação, mesmo que não seja necessário (se o usuário já tiver uma sessão válida, por exemplo), e a execução de operações desnecessárias da Federação impactará:

• O desempenho dos servidores (interações de CPU, LDAP/RDBMS...)

• O tempo de resposta do usuário, com base no tempo necessário para executar uma operação SSO de Federação com os redirecionamentos envolvidos.

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.

---

Título e Informações de Copyright

SP vs IdP Initiated SSO

F60244-01

September 2022

Copyright © 2022, Oracle and/or its affiliates.