En este blog, profundizaré en cómo puede solucionar errores en SAP IAS relacionados con SSO y S/4 HANA en la nube privada. Como sabrá, SAP IAS es un producto altamente competitivo cuando se trata de integrar soluciones SAP SaaS y PaaS con S/4 HANA. Su enfoque principal está en la integración, la seguridad, el cumplimiento, la simplicidad y la escalabilidad, lo que lo convierte en una opción ideal para las empresas que buscan optimizar sus operaciones y garantizar la seguridad de los datos.
Sin embargo, incluso con un producto confiable como SAP IAS, aún pueden ocurrir errores, lo que genera frustración e incomodidad para los clientes. En este blog, explicaré cómo podemos rastrear un error en IAS y esforzarnos por resolverlo, usando un ejemplo real de un problema que enfrentamos recientemente. Específicamente, exploraré una llamada de escalamiento con un cliente y SI para resolver un error que el cliente estaba recibiendo cuando intentaba iniciar sesión en su enlace Fiori externo de S/4 HANA.
El cliente afirmó que el SSO se configuró a través de IAS y estaba funcionando antes. Recientemente, cuando los usuarios hicieron clic en el enlace de Fiori (https://fiori-test.contoso.com), después de usar su correo electrónico (@test.example.com), el SSO ya no funciona.
Le mostraré cómo solucionar este error, paso a paso, para ayudarlo a comprender el proceso y resolver problemas similares que puedan surgir en el futuro.
Primero expliquemos la arquitectura de alto nivel de nuestro escenario.
Como puede ver en el diagrama a continuación, S/4 HANA es compatible con el equipo de SAP ECS en Azure (hiperescalador) y el arrendatario de IAS es el servicio de autenticación de identidad de SAP integrado con los múltiples IdP del cliente. IAS permite que este cliente se autentique con sus IdP de Azure o Google. La integración existente ayuda al cliente a iniciar sesión en el enlace de la plataforma de lanzamiento de Fiori (S/4 HANA) a través del protocolo SAML2 sin volver a ingresar la contraseña de usuario en el nivel de S/4 HANA después de que el IdP respectivo autorice al usuario.
En otras palabras, los usuarios solían hacer clic en el enlace de Fiori y luego solo se les pedía que iniciaran sesión con su correo electrónico corporativo en Google o Azure y, después de pasar la autenticación, accedían a S/4 Fiori o a cualquier mosaico en su tablero de S/4 Fiori sin problemas. :
Si tu sigues números En el diagrama anterior, puede ver cuando el usuario del grupo empresarial B que se originó en Google (IdP), hace clic en el enlace de Fiori, será dirigido a IAS y luego redirigido a Google IdP, después de que el usuario autorice con éxito, tiene acceso a SAP El panel de control de Fiori y puede acceder al mosaico S/4 QA o cualquier otro mosaico para SAP SaaS que se pueden ver en su panel de control similar al que se muestra a continuación:
Aquí hay un diagrama de arquitectura simple para esta solución:
Básicamente, todos los SAML2 para aplicaciones SaaS y S/4 HANA se configuraron en la sección Aplicaciones de este IAS de cliente en la siguiente sección:
https://***.cuentas.ondemand.com/admin/#/aplicaciones
Aplicaciones y recursos > Aplicaciones:
Todos los IdP para diferentes departamentos con el dominio respectivo configurado en la sección Proveedores de identidad de IAS:
https://***.accounts.ondemand.com/admin/#/idPProxies
Proveedores de identidad > Proveedores de identidad corporativa:
Hay tres lugares que probablemente debamos revisar durante la solución de problemas para encontrar la causa raíz principal de este problema:
Proveedor de identidad: Este es el proveedor de identidad de IAS para el dominio de prueba de Google (@test.examle.com) en nuestro escenario
Solicitud: Esta es la aplicación en IAS que se conecta a S/4 HANA (sistema QA1) o el sistema de prueba del cliente al que apunta el enlace Fiori
Sistema de control de calidad S/4 HANA: compruebe la configuración de SAML2 en el sistema de control de calidad S/4 HANA (NetWeaver), incluida una revisión de la fecha de caducidad del certificado
La mejor manera de abordar este problema es descargar primero los registros de errores de IAS y del sistema S/4 (si lo hay) y luego subirlos a Asistente de registro de soporte de SAP Herramienta de autoservicio para analizar:
Support Log Assistant 2.0: herramienta de autoservicio
Para obtener más detalles sobre Support Log Assistant, consulte SAP Nota 2990062 o debajo del video:
Asistente de registro de soporte: descripción general de la herramienta de autoservicio [Video]
El Asistente de registro de soporte es una gran herramienta que puede ayudar a encontrar la mejor resolución para sus errores y puede cargar varios archivos de registro de errores en esta herramienta. ¡Es mucho mejor que buscar en Internet o incluso preguntar a ChatGPT!
Después de subir los registros a Asistente de registro de soporte, Fui guiado a algunas Notas y la nota principal específicamente relacionada con nuestro problema fue la Nota 2698094.
A continuación puede ver el resultado de Support Log Assistant después de analizar los registros:
Como puede ver, había una referencia a la nota de SAP (2698094) que era más relativo a uno de los principales errores que enfrentamos en IAS:
“El proveedor de identidad no pudo procesar la solicitud de autenticación recibida debido a un error del cliente. La firma digital del mensaje SAML2 recibido no es válida. Causado por: No se puede validar la firma Causado por: La longitud de la firma no es correcta”
Básicamente, para estar seguro después de revisar la Nota, solicité obtener un certificado de dominio de prueba de Google nuevo para que el equipo de Google rehaga el certificado al importarlo al IdP de prueba de Google de IAS existente. Después de eso, debemos cargar la respuesta del certificado de S/4 HANA a la aplicación S/4 QA en IAS.
Para hacerlo, primero tuvimos que obtener el certificado SAML2 del arrendatario de IAS (exportar) junto con el nuevo certificado de IdP de Google para poder generar una nueva respuesta de certificado del sistema S/4 HANA QA NetWeaver.
El paso final sería cargar la respuesta del certificado S/4 HANA QA que refleja tanto IAS como Google IdP a la aplicación QA en IAS, lo que causa el problema para SSO.
Al seguir los pasos mencionados anteriormente, pudimos renovar el certificado para todas las capas involucradas en esta solución para asegurarnos de que SAMl2 pueda establecerse correctamente nuevamente.
Los suyos son los pasos que seguí para resolver este problema:
Paso 1: renovar Google Test (IdP) en IAS:
Inicie sesión en el arrendatario de IAS del cliente y vaya a Proveedores de identidad > Proveedores de identidad corporativa:
Luego vaya a «Configuración de SAML 2.0», cargue el archivo xml de metadatos que recibimos del equipo de Google para el dominio @test.exampple.com haciendo clic en «Examinar»:
Nos aseguramos de que «Reenviar todas las solicitudes de SSO al IdP corporativo» esté activado:
Y en la sección «Federación de identidades», use el almacén de usuarios de autenticación de identidad:
Paso 2: exportar el certificado de arrendatario de IAS:
Para exportar metadatos del arrendatario de IAS. Podemos navegar a Configuración de arrendatario de IAS > Configuración de SAML 2.0:
Haga clic en «Descargar archivo de metadatos» para obtenerlo en formato XML:
Este archivo de exportación se puede compartir con proveedores de IdP como Azure y Google y también se utilizará para obtener la respuesta final del certificado del sistema de control de calidad de S/4 HANA.
Paso 3: cargue los certificados de IAS y Google IdP en el sistema S/4 HANA QA a través de SAML2 tcode:
Inicie sesión en el sistema QA1 en S/4 HANA y ejecute tcode SAML2, luego vaya a la pestaña «Proveedor de confianza» y cargue dos certificados de IAS e IdP:
Genere el certificado de respuesta de S/4 HANA:
En el sistema QA1 en S/4 HANA, ejecute tcode SAML2, luego vaya a la pestaña «Proveedor local» y exporte los metadatos:
Asegúrese de marcar las tres opciones antes de hacer clic en “Descargar metadatos” luego guarde el archivo como QA1.xml que se usará para cargar en la sección de aplicaciones QA1 en IAS.
Paso 4: cargue el certificado combinado S/4 HANA al sistema de control de calidad en la aplicación IAS:
Inicie sesión en IAS y vaya a la sección «Aplicaciones» y haga clic en QA1-100:
Haga clic en «Configuración SAML2.0» y luego cargue los metadatos XML (QA1.xml) del sistema QA1 (Paso 3). El resto de los detalles se completarán después de que se complete la carga y no es necesario completarlos:
Atención: siempre marque la sección «Autenticación condicional» de su aplicación y haga clic en «Agregar regla» para tener su proveedor de identidad (refleja el dominio de correo electrónico para el inicio de sesión del usuario) si aún no está allí:
Nota: Si algún mosaico de aplicación en el tablero de Fiori enfrenta un problema similar, solo necesitamos renovar su certificado en IAS también.
Espero que después de leer este blog pueda solucionar errores en SAP IAS y comprender cómo puede habilitar SAML2 para IdP corporativos para SSO.
Siempre puede seguir la publicación de SAP Business Technology Platform y responder preguntas:
https://blogs.sap.com/tags/8077228b-f0b1-4176-ad1b-61a78d61a847/
Para seguir las preguntas de seguridad, publicación y respuesta de SAP BTP:
https://blogs.sap.com/tags/842ea649-eeef-464c-b80c-a64b03e40158/
Referencias:
Nota 2942816 – Cómo exportar y autoanalizar registros de resolución de problemas desde la autenticación de identidad
Nota 3058189 – La firma digital del mensaje SAML2 recibido no es válida. Causado por: Certificado caducado
Nota 2698094 – La URL dada no contiene la solicitud de autenticación SAML2 para la validación
Nota 2645425 – La firma digital del mensaje SAML2 recibido no es válida
Exportación de los metadatos del proveedor de identidad SAML:
Configure el proveedor de servicios SAML 2.0:
Configuración de inquilino SAML 2.0:
¡Deja tu comentario si tienes algo que agregar!
Si desea hacer preguntas, utilice el preguntas y respuestas de la comunidad.
Danos un me gusta y comparte en las redes sociales si crees que fue útil
¡Gracias!
Calle Eloy Gonzalo, 27
Madrid, Madrid.
Código Postal 28010
Paseo de la Reforma 26
Colonia Juárez, Cuauhtémoc
Ciudad de México 06600
Real Cariari
Autopista General Cañas,
San José, SJ 40104
Av. Jorge Basadre 349
San Isidro
Lima, LIM 15073