Configuración del servidor de autenticación central
El servidor de autenticación central 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.
Estas son algunas sugerencias generales que se deben tener en cuenta al implementar un CAS:
• 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.
En los productos de PTC activados para SSO se implementan los dos flujos de autenticación siguientes mediante el marco de SSO y los protocolos estándar:
• Autentificación federada
• Autorización: autorización delegada mediante tipos de concesión de OAuth.
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 de los productos de PTC, el servidor de autenticación central (CAS) debe configurarse 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 crea una aserción que indica que el usuario se ha autenticado. La autenticación se implementa mediante SAML u OIDC, en función del protocolo soportado para el producto de PTC (consulte Protocolos de SSO soportados para productos de PTC) y de la configuración del cliente.
Una vez confirmada la autenticación, la aserción se envía a la aplicación solicitante indicando que el usuario se ha autenticado correctamente y autoriza el inicio de sesión del usuario. A lo largo de esta transacción, ni el CAS ni la aplicación de PTC tendrán visibilidad ni gestionarán las credenciales de 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 cliente del usuario (explorador) y el IdP. Se debe crear una conexión de proveedor de servicios (SP) independiente para cada producto de PTC que esté en la misma federación basada en la autenticación de usuarios a través del mismo CAS.
Se seguirán los flujos de autenticación estándar de SAML y OIDC, en función de la configuración de SSO. Las opciones soportadas para una tecnología CAS determinada deben revisarse antes de seleccionarla para su uso en una configuración de SSO de PTC.
En el siguiente diagrama de secuencia se representa el flujo de autenticación. En este ejemplo, ThingWorx actúa como SP y PingFederate es el CAS. ThingWorx utiliza el protocolo estándar abierto SAML 2.0 para el intercambio de autenticación entre el SP y el IdP.
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.
Para PingFederate, PTC proporciona scripts de automatización para la configuración 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 el CAS en la configuración de SSO.
Autorización delegada (OAuth)
La autorización delegada es un concepto que permite a un proveedor de servicios (SP) 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.
Los tokens de acceso de OAuth 2 se solicitan al CAS y luego se utilizan en las solicitudes de datos de los servidores de recursos. Los servidores de recursos se basan en el CAS para verificar que el solicitante es un usuario autenticado antes de asignar 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 los productos de PTC se soportan tipos de concesión de OAuth para clientes interactivos y no interactivos. Es importante comprender la funcionalidad del cliente para determinar el tipo de concesión adecuado que se debe utilizar.
 |
Asegúrese de comprobar la documentación del producto específico de PTC para confirmar los tipos de concesión de OAuth soportados para el producto.
|
◦ Interactivo: el usuario se autentica en el cliente, el cliente solicitará recursos en nombre de ese mismo usuario. La autorización para permitir el acceso al recurso se basa en la autorización del usuario final.
◦ No interactivo: también conocido como interacción máquina a máquina (M2M). El cliente es una aplicación y debe identificarse ante el CAS al solicitar un token de OAuth. La identidad del token de OAuth es la identidad de la máquina (cliente o entidad de servicio) y no está pensada para ser un usuario humano.
En el siguiente diagrama de secuencia, se representa el flujo del código de autorización de OAuth. ThingWorx es el SP, PingFederate es el CAS y Windchill es el RS. ThingWorx en un cliente interactivo configurado para utilizar el flujo de código de autorización del protocolo OAuth2 estándar abierto para autorizar a un SP a acceder a los recursos de forma segura, fiable y eficaz, utilizando el ID de usuario del usuario final para la autorización y recuperar el recurso.
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.
Se pueden configurar tecnologías CAS alternativas utilizando este mismo flujo. Es posible que sea necesario tener en cuenta pasos y opciones de configuración específicos.
En el caso no interactivo, el flujo de credenciales de cliente se utiliza para pasar un ID de cliente y un secreto al CAS con el fin de recuperar un token de OAuth. A continuación, el token de OAuth se pasa al RS para recuperar el recurso solicitado. El RS debe configurarse para soportar el tipo de concesión de credenciales de cliente con el fin de poder gestionar el token de OAuth y validar la solicitud. En el siguiente diagrama de secuencia, el flujo de credenciales de cliente se representa con un cliente no interactivo que solicita un recurso de Windchill como RS.
La arquitectura de SSO también se puede configurar como una federación con múltiples proveedores de servicios y múltiples servidores de recursos. Las configuraciones de SP y RS las gestiona un único CAS. De esta manera, todas las identidades de usuario se comparten entre la federación. En el siguiente ejemplo, Windchill Navigate es el proveedor de servicios, mientras que Windchill y SAP son los servidores de recursos.
