Configuración del servidor de autenticación central: PingFederate
PTC soporta PingFederate como servidor de autenticación central (CAS). El CAS gestiona la relación de confianza entre los productos de PTC que participan en el marco de SSO. El CAS actúa como intermediario entre las aplicaciones mediante la autorización de conexiones de usuario, una vez que el usuario se ha autenticado, y mediante la emisión y verificación de los tokens de acceso que se intercambian entre los proveedores de servicios y los servidores de recursos.
Los productos de PTC implementan los siguientes elementos en el marco de SSO:
1. Utilice aserciones de SAML para autenticar a los usuarios con el IdP.
2. A continuación, después de que el usuario se haya autenticado, PingFederate presenta al usuario una página de aprobación de concesiones en la que se le pregunta si desea que los datos del servidor de recursos se compartan con la aplicación que está utilizando.
Al trabajar con PingFederate, se debe revisar la documentación de PingFederate. Estas son algunas sugerencias generales que se deben tener en cuenta al implementar PingFederate:
• Revise el tiempo máximo durante el que una conexión de usuario es válida y considere si se deben utilizar los mismos valores en cada una de las aplicaciones que participan en la solución de SSO.
• Confirme que los sistemas funcionan dentro de una tolerancia de desfase de tiempo aceptable. Si uno o más relojes del sistema no están sincronizados con el CAS y superan el tiempo de tolerancia de desfase definido en los sistemas, la configuración producirá errores y evitará que se autentiquen los usuarios.
Autentificación federada
La autentificación federada es el proceso de validar la solicitud de conexión de un usuario comparándola con las credenciales almacenadas en el proveedor de identidad.
En la arquitectura de SSO del producto de PTC, PingFederate no autentica directamente las conexiones de usuario. En su lugar, se debe configurar PingFederate para redirigir las solicitudes de conexión del usuario al IdP de la empresa. El IdP verifica la autenticidad de las credenciales de conexión del usuario y envía una aserción a PingFederate que indica que el usuario se ha autenticado. A continuación, PingFederate envía una aserción a la aplicación solicitante en la que se indica que el usuario se ha autenticado y autoriza la conexión del usuario. En esta transacción, PingFederate no gestiona las credenciales del usuario. Cuando el explorador se redirige al IdP, el intercambio de información de nombre de usuario y contraseña se produce directamente entre el agente del cliente de usuario (explorador) y el IdP. Se debe crear una conexión de proveedor de servicios independiente para cada producto de PTC que encamina la autentificación de usuario a través de PingFederate.
En el siguiente ejemplo, ThingWorx es el proveedor de servicios y PingFederate es el CAS. ThingWorx utiliza el protocolo estándar abierto SAML 2.0 para el intercambio de autentificación entre el proveedor de servicios y el proveedor de identidad.
El proceso de autenticación es el siguiente:
1. El usuario intenta acceder al proveedor de servicios.
2. El proveedor de servicios genera una solicitud de SAML para el usuario y la envía al CAS.
3. El CAS redirige la solicitud de SAML al IdP.
4. El IdP redirige al usuario a una página de autentificación para que proporcione sus credenciales (p. ej., nombre de usuario y contraseña). Una vez que el usuario haya introducido sus credenciales, el IdP generará una respuesta de SAML. Si el usuario se ha autenticado correctamente, la respuesta de SAML incluirá una aserción de SAML que incluye la autorización del usuario.
5. A continuación, el IdP redirigirá la respuesta a los CAS.
PTC proporciona scripts de automatización para la configuración de PingFederate con PingFederate como IdP. Para obtener más información, consulte Configuración automática de PingFederate como servidor de autenticación central.
En el caso de IdP de terceros, se debe configurar PingFederate en la configuración de SSO. Para obtener más información, consulte Configuración manual de la autenticación de IdP de terceros.
Autorización delegada
La autorización delegada es un concepto que permite a un proveedor de servicios realizar acciones o acceder a recursos de un servidor de recursos (RS) en nombre de un usuario, sin que el usuario comparta sus credenciales con el RS.
PingFederate genera tokens de acceso de OAuth 2 que los productos de PTC incluyen en solicitudes de datos de servidores de recursos. Los servidores de recursos se basan en el CAS para verificar la autenticidad de los tokens de acceso. Es necesario crear clientes de OAuth independientes para cada una de las aplicaciones de PTC que participan en escenarios de autorización delegada.
Los productos de PTC protegen aún más los recursos protegidos por OAuth mediante la configuración de ámbitos como medida protectora adicional. Cuando un proveedor de servicios envía un token de acceso junto con su solicitud de datos del servidor de recursos, el token de acceso también debe tener un ámbito adjunto que esté registrado en los datos del servidor de recursos. Para obtener más información, consulte Gestión de ámbitos en la autorización delegada.
En el siguiente ejemplo, ThingWorx es el proveedor de servicios, PingFederate es el CAS y Windchill es el servidor de recursos. ThingWorx utiliza el protocolo de OAuth2 estándar abierto para autorizar a un proveedor de servicios a acceder a recursos de manera segura, fiable y eficaz.
El proceso de autorización es el siguiente:
1. Después de recibir la respuesta de SAML del IdP, el CAS envía una página de solicitud de autorización de concesión para que el usuario la apruebe. El CAS utiliza la página de solicitud de autorización de concesión a fin de obtener la autorización para generar un código de OAuth.
2. Una vez que el usuario concede el acceso, el CAS genera un código de autorización de OAuth. A continuación, el CAS redirige la respuesta de SAML y el código de autorización al proveedor de servicios.
3. Una vez que el proveedor de servicios recibe el código de autorización de OAuth, solicita un token de acceso y un token de renovación del CAS, mediante el código de autorización.
4. El CAS valida el código de autorización y genera un token de acceso de OAuth y un token de renovación. A continuación, el CAS envía ambos tokens al proveedor de servicios.
5. El propietario del recurso (normalmente el usuario) solicita contenido del proveedor de servicios que requiere datos del servidor de recursos.
6. El proveedor de servicios solicita el contenido del servidor de recursos en nombre del propietario del recurso mediante el token de acceso.
7. El servidor de recursos verifica el token de acceso con el CAS.
8. A continuación, el servidor de recursos obtiene el contenido solicitado y lo envía al proveedor de servicios.
9. Después de recibir el contenido, el proveedor de servicios lo entrega al propietario del recurso.
También se puede implementar la arquitectura de SSO con múltiples servidores de recursos. En el ejemplo, ThingWorx Navigate es el proveedor de servicios, mientras que Windchill y SAP son los servidores de recursos.
