Este resumen es para mostrar cómo usar rutas de destino dinámico con SAP Build Work Zone, edición estándar servicio para ejecutar destinos SAP BTP definidos en un nivel de subcuenta BTP. Larga historia corta. Un compañero de comunidad miembro me habia preguntado lo siguiente pregunta. Más allá de los aspectos técnicos involucrados, rutas de destino dinámico ofrecer una solución sencilla a los mismos adivinanza de como probar [complex] destinos [w/o the principal user propagation] sin escribir una sola línea de código… A ver… |
SAP Build Work Zone, servicio de edición estándar (anteriormente conocido como servicio SAP Launchpad) es el producto de entrada a la familia de productos SAP Build Work Zone. (También está disponible como un servicio de suscripción gratuito con cuentas SAP BTP Free Tier).
El destino_dinámico construct permite llamar a cualquier destino definido en un nivel de subcuenta usando el aprobador administrado, por ejemplo:
https://<tenant>.launchpad.cfapps.<region>.hana.ondemand.com/dynamic_dest/<dest_name>/<api_endpoint>
Bueno saber:
Puedes referirte a Pautas de configuración de destinos de la documentación oficial de SAP para obtener más detalles.
Tuve la oportunidad de probarlo usando una serie de OAuth2SAMLBearerAssertion destinos de nivel de subcuenta.
Puede llamar a un sistema/API remoto protegido por OAuth2 y propagar una ID de usuario al sistema remoto mediante el OAuth2SAMLBearerAssertion tipo de autenticación. El servicio de destino proporciona funcionalidad para la recuperación y el almacenamiento en caché automáticos de tokens, al automatizar la construcción y el envío de la aserción SAML. Esto simplifica el desarrollo de aplicaciones, dejándolo solo con la construcción de la solicitud al sistema remoto al proporcionar el token, que el servicio de destino obtiene para usted. Para más información, ver Propagación de usuarios a través del flujo de aserción de portador de SAML 2.0.
Desde el momento en que los sistemas de destino (SAP Analytics Cloud, SAP S/4HANA Cloud, SAP SuccessFactors, etc.) están correctamente configurados para la propagación del usuario principal, el destino_dinámico debería funcionar fuera de la caja… por ejemplo:
https://<tenant>.launchpad.cfapps.<region>.hana.ondemand.com/dynamic_dest/S4HC-Product/$metadata
https://<tenant>.launchpad.cfapps.<region>.hana.ondemand.com/dynamic_dest/QUOVADIS-ISVENG-JWT/A_SalesOrder?$top=5
https://ateam.launchpad.cfapps.sap.hana.ondemand.com/dynamic_dest/Quovadis-SAP-JWT/User?$top=1&$format=json
https://<tenant>.launchpad.cfapps.<region>.hana.ondemand.com/dynamic_dest/ateam-partnereng/stories
En todos los casos anteriores, la identidad de un usuario de subcuenta SAP BTP que inicia sesión en SAP Build Work Zone, edición estándar (también conocido como servicio Launchpad) se transfiere a un destino dinámico. El servicio de destino genera una afirmación SAML que se pasa al proveedor de recursos. En caso de que un inicio de sesión de usuario remoto (con un flujo delegado por IDP) tenga éxito, se recupera un token de acceso de portador y luego se pasa al llamar a la función empresarial.
Por lo tanto, la identidad del usuario debe ser conocida por un sistema de destino.
Hoy en día, las cargas de trabajo en contenedores administradas por kubernetes se están volviendo cada vez más populares, casi omnipresentes. Con SAP BTP, la regla CRD de la API del tiempo de ejecución de Kyma, es bastante fácil exponer de forma segura los microservicios y sus terminales al mundo exterior. Dado que la seguridad es primordial, una regla de API CRD puede ofrecer una serie de estrategias de acceso para ayudar a restringir el acceso a los puntos finales expuestos. Por el bien de este resumen, opté por usar el JWT estrategia de acceso como una forma de proteger los puntos finales de una regla API del acceso no solicitado. |
La parte más importante de la siguiente definición de regla API es la configuración de estrategias de acceso como sigue:
apiVersion: gateway.kyma-project.io/v1beta1
kind: APIRule
metadata:
name: "{{ .Values.services.srv.name }}-{{ .Release.Namespace }}"
spec:
gateway: {{ .Values.gateway }}
host: "{{ .Values.services.srv.name }}-{{ .Release.Namespace }}.{{ .Values.clusterDomain }}"
rules:
- accessStrategies:
- config:
jwks_urls:
- https://<tenant>.authentication.<region>.hana.ondemand.com/token_keys
trusted_issuers:
- https://<tenant>.authentication.<region>.hana.ondemand.com/oauth/token
required_scope:
- openid
handler: jwt
methods:
- GET
- PUT
- DELETE
- POST
- PATCH
- HEAD
path: /.*
service:
name: {{ .Values.services.srv.name }}
port: {{ .Values.services.srv.port }}
El arrendatario y el región los valores son los del aprobador administrado. (Y también se pueden administrar como valores de gráfico de timón).
Del mismo modo, para restringir aún más el acceso a la regla API solo a categorías de usuarios específicas, es posible incluir autorizaciones de usuario adicionales (alcances) que se administran en una subcuenta BTP a través de Roles y Colecciones de Roles asignados a usuarios comerciales.
Supongamos la siguiente definición de destino dinámico:
Cuenta con dos propiedades adicionales:
Eventualmente, el destino anterior se puede consumir como un destino dinámico de la siguiente manera:
https://<tenant>.launchpad.cfapps.<region>.hana.ondemand.com/dynamic_dest/poster_dest/
Esto dará como resultado la llamada de una regla API de Kyma con el JWT del usuario BTP pasado en el encabezado de Autorización. Posteriormente, la regla API intentará validar el acceso al punto final siguiendo las estrategias de acceso definidas. Después de una validación exitosa, se otorgará el acceso; de lo contrario, se generará un error 401.
P. ¿Qué pasa si quisiera usar mi propio proveedor OIDC en este flujo de trabajo, en lugar de depender de un token de usuario reenviado?
R. Esa es una pregunta muy justa. Aquí es donde OAuth2JWTPortador El tipo de destino puede ayudar a intercambiar el token JWT del usuario en un token de acceso al portador OAuth2 con los alcances requeridos…
Para permitir que una aplicación llame a otra aplicación, pase el contexto del usuario y obtenga recursos, la aplicación que llama debe pasar un token de acceso. En este flujo de autorización, el token de usuario inicial se pasa al servidor de OAuth como datos de entrada. El servicio de destino realiza automáticamente este proceso, lo que ayuda a simplificar el desarrollo de la aplicación: solo tiene que construir la solicitud correcta para la URL de destino, utilizando el resultado (otro token de acceso) de la automatización del lado del servicio.
Tomemos lo anterior palabras por sentado y construir tal definición de destino. Utilizaremos una instancia del servicio XSUAA que actúa como proveedor de OIDC…
¡Y bingo! ¡Esto funciona como se anuncia! (más detalles en la sección del apéndice a continuación…)
|
Llamar a un microservicio alojado en kyma desde la comodidad de un servicio de plataforma de lanzamiento administrado con la seguridad integrada de SAP BTP nunca ha sido tan fácil;
Llamar a las API de las aplicaciones LOB de SAP se ha convertido en un «pan comido»…
Todo eso con poco o ningún código.
Por último, pero no menos importante, espero que hayas disfrutado leyendo esta publicación de blog. Siéntase libre de proporcionar comentarios en la sección de comentarios a continuación.
1a. el token de usuario JWT inicial…
{
"alg": "RS256",
"jku": "https://<tenant>.authentication.<region>.hana.ondemand.com/token_keys",
"kid": "<kid>",
"typ": "JWT",
"jid": "<jid>"
}.{
"jti": "<jti>",
"ext_attr": {
"enhancer": "XSUAA",
"subaccountid": "<subaccountid>",
"zdn": "<zdn>"
},
"xs.system.attributes": {
"xs.rolecollections": [
"Subaccount Service Administrator",
"SAP HANA Cloud Administrator",
"Subscription Management Dashboard Administrator",
"Subaccount Administrator",
"Launchpad_Admin",
"faas-faas_hc-faas"
]
},
"given_name": "Foo",
"xs.user.attributes": {},
"family_name": "Bar",
"sub": "<sub>",
"scope": [
"openid",
"faas-faas!t6455.Admin",
"faas-faas!t6455.User",
"uaa.user"
],
"client_id": "sb-faas-faas!t6455",
"cid": "sb-faas-faas!t6455",
"azp": "sb-faas-faas!t6455",
"grant_type": "authorization_code",
"user_id": "<user_id>",
"origin": "ldap",
"user_name": "foo.bar@sap.com",
"email": "foo.bat@sap.com",
"auth_time": <auth_time>,
"rev_sig": "<rev_sig>",
"iat": <iat>,
"exp": <exp>,
"iss": "https://<tenant>.authentication.<region>.hana.ondemand.com/oauth/token",
"zid": "<zid>",
"aud": [
"uaa",
"openid",
"faas-faas!t6455",
"sb-faas-faas!t6455"
]
}.[Signature]
1b… se intercambia por un token de acceso al portador. El punto final de emisión del token de acceso del portador es el de su proveedor OIDC personalizado (que puede ser una instancia de servicio XSUAA, una aplicación SAP IAS OIDC o cualquier otro proveedor OIDC de terceros).
En aras de la simplicidad, el siguiente fragmento de definición de destino utiliza una instancia del servicio XSUAA [on the same BTP sub-account as the managed approuter].
{
"owner": {
"SubaccountId": "<SubaccountId>",
"InstanceId": null
},
"destinationConfiguration": {
"Name": "quovadis-anywhere",
"Type": "HTTP",
"URL": "https://poster.<business_domain>.com/",
"Authentication": "OAuth2JWTBearer",
"ProxyType": "Internet",
"tokenServiceURLType": "Dedicated",
"HTML5.DynamicDestination": "true",
"clientId": "<clientId>",
"Description": "poster",
"scope": "openid",
"HTML5.Timeout": "60000",
"clientSecret": "<clientSecret>",
"tokenServiceURL": "https://<tenant>.authentication.<region>.hana.ondemand.com/oauth/token"
},
"authTokens": [
{
"type": "bearer",
"value": "eyJhbGciOiJSUzI1NiIsImprdSI6Imh0dHBzOi8vYXRlYW0uYXV0aGVudGljYXRpb24uc2FwLmhhbmEub25kZW1hbmQuY29tJN5W0TMNG32nVayH5yMwKHClhH3OW5Asx61KSE1hTu4HpwgDp4a-P-HG3Fw0XQmQIUe_m8YuQ0s6WFQHsbPlLLaINxfPL-Q",
"http_header": {
"key": "Authorization",
"value": "Bearer eyJhbGciOiJSUzI1NiIsImprdSI6Imh0dHBzOi8vYXRlYW0uYXV0aGVudGljYXRpb24uc2FwLmhhbmEub25kZW1hbmQuY29tLJN5W0TMNG32nVayH5yMwKHClhH3OW5Asx61KSE1hTu4HpwgDp4a-P-HG3Fw0XQmQIUe_m8YuQ0s6WFQHsbPlLLaINxfPL-Q"
},
"expires_in": "42389",
"scope": "openid"
}
]
}
2. Aquí va el token de acceso al portador recuperado y decodificado:
{
"alg": "RS256",
"jku": "https://<tenant>.authentication.<region>.hana.ondemand.com/token_keys",
"kid": "<kid>",
"typ": "JWT",
"jid": "<jid>"
}.{
"jti": "<jti>",
"ext_attr": {
"enhancer": "XSUAA",
"subaccountid": "<subaccountid>",
"zdn": "<zdn>"
},
"xs.system.attributes": {
"xs.rolecollections": [
"Subaccount Service Administrator",
"SAP HANA Cloud Administrator",
"Subscription Management Dashboard Administrator",
"Subaccount Administrator",
"Launchpad_Admin",
"faas-faas_hc-faas"
]
},
"given_name": "Foo",
"xs.user.attributes": {},
"family_name": "Bar",
"sub": "<sub>",
"scope": [
"openid"
],
"client_id": "<client_id>",
"cid": "<cid>",
"azp": "<azp>",
"grant_type": "urn:ietf:params:oauth:grant-type:jwt-bearer",
"user_id": "<user_id>",
"origin": "ldap",
"user_name": "foo.bar@sap.com",
"email": "foo.bar@sap.com",
"rev_sig": "<rev_sig>",
"iat": <iat>,
"exp": <exp>,
"iss": "https://<tenant>.authentication.<region>.hana.ondemand.com/oauth/token",
"zid": "<zid>",
"aud": [
"openid",
"<client_id>"
]
}.[Signature]
que el aprobador administrado con la ruta dynamic_dest utilizará para llamar a la URL comercial.
Comunidad SAP: https://community.sap.com/
Enlace de la página del tema de la comunidad de SAP: https://community.sap.com/topics/kyma
Etiquetas de preguntas y respuestas de la comunidad de SAP:
Código abierto de Kyma: https://answers.sap.com/tags/2936b97d-6a90-4cd8-b635-0e51441611eb
SAP BTP, tiempo de ejecución de Kyma: https://answers.sap.com/tags/73554900100800003012
Sígueme en la comunidad SAP: Piotr Tesny
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