
Estimados amigos de SAP
Durante la implementación del flujo de OAuth 2.0 JWT Grant en SAP PI REST, aprendí muchos entresijos al respecto y espero que a través de este blog tenga una mejor comprensión de qué esperar al configurar la autenticación JWT para las API que lo requieren.
Hay otro blog sobre la autenticación JWT de DocuSign para la integración en la nube, por lo que si necesita detalles de configuración sobre el mismo en el contexto de la integración en la nube, puede consultar este excelente blog:
Cuando obtuve el requisito, el blog anterior no estaba allí, así que me aseguré de incluir pasos y observaciones detallados y las razones detrás de ellos en esta publicación de blog.
Objetivo:
Comprender e implementar un escenario completo de extremo a extremo para la configuración del adaptador SAP PI REST donde usaremos la configuración OAuth2 para usar la autenticación de concesión JWT. Estoy seguro de que esta publicación de blog podrá arrojar luz sobre la autenticación basada en JWT, que tiene una documentación disponible muy limitada.
Lo que ya deberías saber antes de esta publicación de blog:
(i) Comprensión de cómo funcionan las API. (Métodos HTTP, encabezados, parámetros, etc.)
(ii) Comprensión del adaptador REST.
(iii) Pruebas de API con Postman.
Para obtener una explicación teórica e información más detallada sobre JWT, puede consultar la página de inicio de jwt.io o debajo de la página de DocuSign:
https://developers.docusign.com/platform/auth/jwt/
Intentaré centrarme más en la implementación aquí. Empecemos.
(e) Lo llevará a la página de detalles de la aplicación donde debe anotar algunos parámetros y configurar otros. Mantenga la selección a continuación tal como está:
(f) Desplácese hacia abajo hasta la sección Integración de servicios, donde puede cargar su propio par de claves RSA o generar uno nuevo. Generaremos uno nuevo aquí.
(g) Verá que se genera un nuevo par de claves, copie los valores haciendo clic en los botones resaltados como se muestra a continuación y cópielos en un bloc de notas (o guárdelos de forma segura para su uso posterior).
(h) Agregue un URI de redirección como se muestra a continuación para redirigir al usuario a los códigos de autorización de respuesta.
Haga clic en el botón «Guardar» en la parte inferior y listo.
(i) Como estamos utilizando la concesión individual, en este caso debemos otorgar el consentimiento para que esta aplicación se autentique en nuestro nombre (el del usuario que ha iniciado sesión).
Para hacer esto, debemos llamar a la siguiente URL y dar nuestro consentimiento. Se le pedirá que inicie sesión en caso de «no iniciar sesión» o «sesión obsoleta».
La URL es:
https://account-d.docusign.com/oauth/auth?response_type=code&scope=signature%20spring_read%20spring_write%20interpretación&id_cliente={Clave de integración}&redirect_uri={redirigir_uri}
Observación #1: el parámetro de consulta de alcance debe incluir «suplantación de identidad» como se muestra arriba, de lo contrario obtendrá «consentimiento requerido” error más tarde (consulte el paso 3.b) a pesar de una ejecución exitosa del siguiente paso.
Pongamos la URL rellenada en el navegador. Obtendrá una página debajo que le pedirá que «permita el acceso»
Haga clic en «PERMITIR ACCESO» y será redirigido a la página siguiente.
Siempre que el código se genere en la URL como se ve a continuación, esto es lo esperado. Confirma que el consentimiento ahora se ha otorgado con éxito en nombre del usuario que inició sesión. Ahora su integración en SAP PI puede usar los identificadores de esta aplicación para obtener «access_token» con el flujo de concesión de JWT para la autenticación final.
emisor (iss) | Clave de integración para la aplicación DocuSign |
Asunto (sub) | ID de usuario del usuario registrado en el portal DocuSign Developer |
Audiencia (audiencia) | en la documentación oficial de DocuSign es cuenta-d.docusign.com |
Caducidad (exp) | no tiene ninguna relación con el proceso de autorización, ya que el vencimiento del token lo establece la aplicación DocuSign y no el cliente. estableceremos como 3600 aquí. |
Algoritmo de firma JWT | puede usar varios tipos de algoritmos de firma, pero según la documentación de DocuSign, usaremos RSA256 |
Alcance | Básicamente, se trata de la autorización/permiso a nivel de entidad otorgado al usuario para realizar ciertas operaciones, estas serán proporcionadas por el usuario funcional e implementadas por el administrador de la organización para su usuario. |
Observación #2: Para el algoritmo de firma JWT, usaremos el par de claves RSA generado en el paso 5.f y estas claves se instalarán en Almacén de claves NWA para uso en la configuración del canal REST
(d) Ahora completaremos toda la información para el paso (c) del paso 5.
Observación #3: Es posible que hayas notado que el campo de alcance está en blanco aquí. La razón de esto es el hecho de que, por alguna razón, el «alcance» era una reclamación que no se trató como tal cuando los valores se configuraron aquí y la configuración no pudo usar los valores del alcance para generar el token.
Para configurar el alcance, utilizaremos la configuración de «Parámetros adicionales de OAuth 2.0» como se muestra a continuación:
Observación #4: Todos los valores de alcance configurados aquí se deben usar en el paso «otorgar consentimiento» en el paso 5; de lo contrario, el token de acceso generado, aunque sea válido, no podrá obtener ni actualizar las entidades relevantes en DocuSign.
(e) El resto de la configuración para el «canal del receptor REST» seguirá siendo la misma que la configuración para otras API.
Configuración de URL de REST
Como ya seleccionó «Encabezado HTTP» como opción para usar el token de OAuth 2.0 en la configuración, como se muestra en el paso 6.d, no necesita configurar nada específico para el parámetro «Autorización» en la pestaña «Encabezados HTTP de REST». canal.
Configuración de encabezado HTTP
Termina el resto de la configuración y listo.
(f) Puede ejecutar una prueba de extremo a extremo o hacer ping al canal para validar la configuración. A continuación se muestra una muestra de ping exitosa:
(g) Para las pruebas de extremo a extremo, he creado un escenario simple REST (SAP PI) a REST (DocuSign API). No entraré en la configuración de iFlow aquí.
A continuación se muestra la captura del cartero para probar la misma interfaz.
Solo para aclarar el campo «creado» en la respuesta, como se ve arriba, es la marca de tiempo de cuando se creó mi cuenta en DocuSign el año pasado. Esta API de DocuSign solo obtiene información de la cuenta del usuario.
Y aquí están los registros de una llamada exitosa a la API de DocuSign.
Acción para el lector:
Puede hacer que esta configuración funcione para otras API de terceros también con una configuración similar. Asegúrese de probar primero las API en Postman para esta configuración, de modo que tenga menos problemas que solucionar cuando mueva la configuración al Adaptador REST.
Las preguntas y comentarios son muy bienvenidos. Por favor, comparte, dale me gusta y sígueme para más publicaciones de este tipo si disfrutaste esta.
Gracias por leer.
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