Enrutamiento de destinos fácil con SAP Build Work Zone, edición estándar

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:

• Todos los tipos de destinos son compatibles.
• Por favor, asegúrese de que todos sus destino_dinámico los destinos tienen la HTML5.DynamicDestination magia propiedad establecida en verdadero.

Puedes referirte a Pautas de configuración de destinos de la documentación oficial de SAP para obtener más detalles.

Fácil enrutamiento con destinos OAuth2SAMLBearerAssertion

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:

Nube SAP S/4HANA

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

Factores de éxito de SAP

https://ateam.launchpad.cfapps.sap.hana.ondemand.com/dynamic_dest/Quovadis-SAP-JWT/User?$top=1&$format=json

Nube de análisis de SAP

https://<tenant>.launchpad.cfapps.<region>.hana.ondemand.com/dynamic_dest/ateam-partnereng/stories

dynamic_dest con SAP Build Work Zone, edición estándar

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.

Fácil enrutamiento con SAP BTP, reglas API de tiempo de ejecución de Kyma

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.

Regla API de Kyma como una URL comercial en una definición de destino

Supongamos la siguiente definición de destino dinámico:

una definición de destino hacia una regla API de kyma

Cuenta con dos propiedades adicionales:

• HTML5.DynamicDestination: verdadero — eso lo convierte en un destino dinámico
• HTML5.ForwardAuthToken: verdadero — que le dice al aprobador administrado que reenvíe el token JWT del usuario comercial a la regla API en el Autorización encabezado como un token de acceso al portador

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.

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.

Apéndice

Fabricación de OAuth2JWTPortador tipo de destino

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