Alguém pode me explicar quais são as principais diferenças entre SSO iniciado por SP e SSO iniciado por IDP , incluindo qual seria a melhor solução para implementar o logon único em conjunto com ADFS + OpenAM Federation?
Alguém pode me explicar quais são as principais diferenças entre SSO iniciado por SP e SSO iniciado por IDP , incluindo qual seria a melhor solução para implementar o logon único em conjunto com ADFS + OpenAM Federation?
Respostas:
No IDP Init SSO (SSO da Web não solicitado), o processo de Federação é iniciado pelo IDP, enviando uma resposta SAML não solicitada ao SP. No SP-Init, o SP gera um AuthnRequest que é enviado ao IDP como a primeira etapa do processo de Federação e o IDP então responde com uma Resposta SAML. O suporte IMHO ADFSv2 para SAML2.0 Web SSO SP-Init é mais forte do que o suporte IDP-Init em relação à integração com produtos Fed de terceiros (principalmente em torno do suporte para RelayState), portanto, se você tiver a opção de usar o SP- Init, pois provavelmente tornará a vida mais fácil com ADFSv2.
Aqui estão algumas descrições simples de SSO do Guia de introdução do PingFederate 8.0 que você pode consultar e que também podem ajudar - https://documentation.pingidentity.com/pingfederate/pf80/index.shtml#gettingStartedGuide/task/idpInitiatedSsoPOST.html
SSO iniciado por IDP
Da documentação do PingFederate: - https://docs.pingidentity.com/bundle/pf_sm_supportedStandards_pf82/page/task/idpInitiatedSsoPOST.html
Nesse cenário, um usuário está conectado ao IdP e tenta acessar um recurso em um servidor SP remoto. A asserção SAML é transportada para o SP via HTTP POST.
Etapas de processamento:
SSO iniciado por SP
Da documentação do PingFederate: - http://documentation.pingidentity.com/display/PF610/SP-Initiated+SSO--POST-POST
Nesse cenário, um usuário tenta acessar um recurso protegido diretamente em um site do SP, sem estar conectado. O usuário não tem uma conta no site do SP, mas tem uma conta federada gerenciada por um IdP de terceiros. O SP envia uma solicitação de autenticação ao IdP. Tanto a solicitação quanto a asserção SAML retornada são enviadas por meio do navegador do usuário via HTTP POST.
Etapas de processamento:
Informações adicionais sobre o usuário podem ser recuperadas do armazenamento de dados do usuário para inclusão na resposta SAML. (Esses atributos são pré-determinados como parte do acordo de federação entre o IdP e o SP)
O serviço SSO do IdP retorna um formulário HTML ao navegador com uma resposta SAML contendo a asserção de autenticação e quaisquer atributos adicionais. O navegador envia automaticamente o formulário HTML de volta ao SP. NOTA: As especificações SAML exigem que as respostas do POST sejam assinadas digitalmente.
(Não mostrado) Se a assinatura e a declaração forem válidas, o SP estabelece uma sessão para o usuário e redireciona o navegador para o recurso de destino.
Bill o usuário: "Ei Jimmy, mostre-me esse relatório"
Jimmy, o SP: "Ei, ainda não tenho certeza de quem você é. Temos um processo aqui, então primeiro faça a verificação com Bob, o IdP. Eu confio nele."
Bob, o IdP: "Vejo que Jimmy o enviou aqui. Por favor, me dê suas credenciais."
Cobrar o usuário: "Olá, sou o Bill. Aqui estão minhas credenciais."
Bob, o IdP: "Olá, Bill. Parece que você deu uma olhada."
Bob, o IdP: "Ei Jimmy. Esse cara, Bill, verifica e aqui estão algumas informações adicionais sobre ele. Faça o que quiser a partir daqui."
Jimmy the SP: "Ok legal. Parece que Bill também está em nossa lista de convidados conhecidos. Vou deixar Bill entrar."
Bill para o usuário: "Ei, Bob. Quero ir para a casa de Jimmy. A segurança é rigorosa lá."
Bob, o IdP: "Ei Jimmy. Eu confio no Bill. Ele verifica e aqui estão algumas informações adicionais sobre ele. Faça o que quiser a partir daqui."
Jimmy the SP: "Ok legal. Parece que Bill também está em nossa lista de convidados conhecidos. Vou deixar Bill entrar."
Entrarei em mais detalhes aqui, mas mantendo as coisas simples: https://jorgecolonconsulting.com/saml-sso-in-simple-terms/ .