single-sign-on - microsoft - sso active directory
Las diferencias entre SP iniciado SSO y IDP iniciado SSO (3)
¿Puede alguien explicarme cuáles son las principales diferencias entre el SSO iniciado por SP y el SSO iniciado por IDP , incluida cuál sería la mejor solución para implementar el inicio de sesión único junto con ADFS + OpenAM Federation?
SP iniciado SSO
SP: "Oye, ¿conoces a Sal?"
IdP: "¿Yo sí? ... ¡Oh, sí! Sí, lo sé Sal"
SP: "Ok, genial. La dejaré entrar".
IdP Iniciado SSO
IdP: "Hey Sal me dice que la conoces"
SP: "¿Lo hago? ... Oh sí, lo hago. La dejaré entrar".
En IDP Init SSO (SSO web no solicitado), el proceso de federación se inicia cuando el IDP envía una respuesta SAML no solicitada al SP. En SP-Init, el SP genera una AuthnRequest que se envía al IDP como primer paso en el proceso de Federación y el IDP luego responde con una Respuesta SAML. Soporte de IMHO ADFSv2 para SAML2.0 Web SSO SP-Init es más fuerte que su IDP-Init support re: integración con productos de terceros Fed (principalmente girando en torno a soporte para RelayState) así que si tiene una opción, querrá usar SP- Inicia ya que probablemente te hará la vida más fácil con ADFSv2.
Aquí hay algunas descripciones sencillas de SSO de la Guía de introducción de PingFederate 8.0 que puede consultar también: https://documentation.pingidentity.com/pingfederate/pf80/index.shtml#gettingStartedGuide/task/idpInitiatedSsoPOST.html
IDP inició SSO
De la documentación de PingFederate: - https://docs.pingidentity.com/bundle/pf_sm_supportedStandards_pf82/page/task/idpInitiatedSsoPOST.html
En este escenario, un usuario inicia sesión en el IdP e intenta acceder a un recurso en un servidor de SP remoto. La aserción SAML se transporta al SP a través de HTTP POST.
Pasos de procesamiento:
- Un usuario ha iniciado sesión en el IdP.
- El usuario solicita acceso a un recurso SP protegido. El usuario no ha iniciado sesión en el sitio SP.
- Opcionalmente, el IdP recupera atributos del almacén de datos del usuario.
- El servicio SSO del IdP devuelve un formulario HTML al navegador con una respuesta SAML que contiene la aserción de autenticación y cualquier atributo adicional. El navegador automáticamente publica el formulario HTML de nuevo en el SP.
SP iniciado SSO
De la documentación de PingFederate: - http://documentation.pingidentity.com/display/PF610/SP-Initiated+SSO--POST-POST
En este escenario, un usuario intenta acceder a un recurso protegido directamente en un sitio web de SP sin iniciar sesión. El usuario no tiene una cuenta en el sitio SP, pero tiene una cuenta federada administrada por un IdP de un tercero. El SP envía una solicitud de autenticación al IdP. Tanto la solicitud como la aserción SAML devuelta se envían a través del navegador del usuario a través de HTTP POST.
Pasos de procesamiento:
- El usuario solicita acceso a un recurso SP protegido. La solicitud se redirige al servidor de federación para gestionar la autenticación.
- El servidor de federación envía un formulario HTML al navegador con una solicitud SAML para la autenticación del IdP. El formulario HTML se publica automáticamente en el servicio SSO del IdP.
- Si el usuario aún no ha iniciado sesión en el sitio IdP o si se requiere una nueva autenticación, el IdP solicita credenciales (por ejemplo, ID y contraseña) y el usuario inicia sesión.
Se puede recuperar información adicional sobre el usuario del almacén de datos del usuario para incluirla en la respuesta de SAML. (Estos atributos están predeterminados como parte del acuerdo de federación entre el IdP y el SP)
El servicio SSO del IdP devuelve un formulario HTML al navegador con una respuesta SAML que contiene la aserción de autenticación y cualquier atributo adicional. El navegador automáticamente publica el formulario HTML de nuevo en el SP. NOTA: las especificaciones SAML requieren que las respuestas POST se firmen digitalmente.
(No se muestra) Si la firma y la aserción son válidas, el SP establece una sesión para el usuario y redirige el navegador al recurso de destino.