Propagación de usuarios técnicos: SAP BTP a S4 en las instalaciones

Caso de uso: necesidad de propagar el usuario técnico al sistema S4 local mediante la metodología de propagación principal. Las aplicaciones autenticadas que se ejecutan en BTP Cloud Foundry ahora pueden propagar usuarios técnicos utilizando SAP-Conectividad-Técnica-Autenticación encabezamiento.

Recientemente tuvimos un requisito en el que necesitaríamos propagar el usuario técnico, pero no queríamos usar la autenticación básica como seguridad.

A partir de Conector en la nube versión 2.15, los consumidores del servicio de Conectividad pueden propagar usuarios técnicos desde la aplicación en la nube hacia los sistemas locales. Para lograr esto, se utiliza un token JWT que representa al usuario técnico, a través del SAP-Conectividad-Técnica-Autenticación encabezado. Esto es similar a propagación principalpero en este caso, se propaga un usuario técnico en lugar de un usuario comercial.

En el siguiente blog, intentaría esbozar un enfoque para lograr lo mismo, aunque es algo que hemos usado para lograr los resultados y es posible que no esté listo para la producción (por supuesto), porque el código debe ser más refinado mientras se logra lo mismo. 🙂

Para verificar y demostrar la funcionalidad, donde se usa un servicio OData bajo la premisa de que busco al usuario actual en la llamada y lo devuelvo a la persona que llama. Desde la perspectiva de Cloud Foundry, hay una aplicación que servirá como punto de entrada para el usuario y la llamada se reenvía a otro middleware, donde los encabezados se transformarán para la solicitud.

Requisito previo – La propagación principal ya está configurada.

Comencemos con la configuración en el lado local.

1. Cree un servicio de odata: en este caso específico para probar la conexión, se crea un servicio de odata de muestra, que leerá al usuario que inició sesión y regresará a la persona que llama. Adjuntar una implementación de muestra: utilizar las estructuras DDIC actuales para el mismo y usar sy-uname.
2. Creación de un Usuario en Su01
   
3. En el paso anterior, la parte más importante es la alias – este es el usuario técnico para su comunicación y puede encontrarlo en la clave de servicio BTP, en el caso anterior, esta es la clave de servicio id de cliente del servicio de conectividad de la subcuenta donde ha conectado su conector de nube. Obtenemos vinculando la aplicación de middleware con el servicio de conectividad y usando las variables de entorno para leer los datos.
4. Ahora necesitaría mapear al usuario a través de la transacción. certrula, como el usuario técnico está administrado en un alias, mapearíamos al usuario a través de un alias, y el conector de la nube tendrá Propagación principal como medio de autenticación.

Desde la perspectiva On-premise, tendríamos que hacer solo unas pocas configuraciones adicionales además de la configuración de propagación principal estándar.

Requisito previo: aplicación de Cloud Foundry con autenticación XSUAA y capaz de llamar a un destino.

En nuestro POC, tenemos un enrutador de aplicaciones, que llamará al destino (aplicación de software intermedio).

XS-app.json de la aplicación se configura de la siguiente manera,

{
  "welcomeFile": "/index.html",
  "authenticationMethod": "route",
  "logout": {
    "logoutEndpoint": "/do/logout"
  },
  "routes": [
    {

      "csrfProtection": false,
      "source": "^/sap/opu/odata/sap/Z_MUNISH_SSO_SRV/(.*)$",
      "target": "$1",
      "destination": "middleware_sso"
    },
    {
      "source": "^(.*)$",
      "target": "$1",
      "service": "html5-apps-repo-rt",
      "authenticationType": "xsuaa"
    }
  ]
}

esta apuntando a middleware_ssoque no es más que un destino creado en la subcuenta BTP para el procesamiento de middleware, aunque esto se puede lograr mediante concepto de encadenamiento de middleware, pero estoy sacando la lógica del middleware para este POC.

Configuración de middleware_sso destino se muestran a continuación.

Hasta ahora, hemos configurado la propagación principal y tenemos una aplicación disponible que está limitada a XSUAA y puede llamar al destino.

Pasando a la parte principal de ahora llamar al destino del servicio Odata, para ese propósito tenemos un middleware de nodo js para agregar el encabezado y llamar al destino del backend.

Inicio.js

const express = require("express");
const app = express();

const SapCfAxios = require("sap-cf-axios").default;

const passport = require("passport");
const { JWTStrategy } = require("@sap/xssec");
const xsenv = require("@sap/xsenv");
const xml = require("xml");

passport.use(new JWTStrategy(xsenv.getServices({ uaa: { tag: "xsuaa" } }).uaa));
app.use(passport.initialize());
app.use(passport.authenticate("JWT", { session: false }));
var axiosSimple = require('axios');

const oVCAP_SERVICES = JSON.parse(process.env.VCAP_SERVICES);
const oConnectivityServiceCredentials =
  oVCAP_SERVICES.connectivity[0].credentials;

const handleRequest = async (req, res) => {
 
  const axios = SapCfAxios("Dest_s4_he4_sso");
  var authorization = req.headers.authorization;

  var params = new URLSearchParams();
  params.append("client_id", oConnectivityServiceCredentials.clientid);
  params.append("client_secret", oConnectivityServiceCredentials.clientsecret);
  params.append("grant_type", "client_credentials");

  var tokentechnical = ""
  try{
  var response1 = await axiosSimple({
    method: "post",
    url: oConnectivityServiceCredentials.token_service_url + "/oauth/token",
    params: params,
    headers: {
      "Content-Type": "application/x-www-form-urlencoded",
      Accept: "application/json",
    },
  });

  tokentechnical = response1.data.access_token
}catch(e){
  console.log(e)
}

  try{

    console.log("auth",authorization)
  const response = await axios({
    method: "GET",
    url: "/ZMUNISH001Set",
    headers: {
      "content-type": "application/json",
      "SAP-Connectivity-Technical-Authentication":"Bearer "+tokentechnical
    },
   
  });
  console.log(response.data);
  res.set('Content-Type','application/json')
  res.send(JSON.stringify(response.data));

  }catch(e){
    console.log(JSON.stringify(e))
    res.send(JSON.stringify(e))
  }
 
};

app.get("/", handleRequest);
const port = process.env.PORT || 3000;
app.listen(port, function () {
  console.log("myapp listening on port " + port);
});

Para la implementación, necesitaría un archivo de manifiesto.

---
applications:
- name: myapp
  routes:
    - route: <your_host>.cfapps.eu10.hana.ondemand.com
  path: myapp
  memory: 128M
  buildpack: nodejs_buildpack
  services:
    - name: conn_principalpropagation
    - name: dest_principalpropagation
    - name: principalpropagation-xsuaa-service

referencia de Github

En el código anterior estamos utilizando destino Dest_s4_he4_sso, esto se ha creado en sus destinos BTP que apuntan al host virtual local.

Ahora es el momento de probar el flujo, puede llamar a la URL del enrutador de la aplicación y debería apuntar al middleware, desde donde debería poder conectarse al sistema local a través de un usuario técnico y si todo está bien, el usuario técnico debería devolverse en la respuesta si está configurado correctamente.

En la configuración actual de min, puede ver los atributos de la tabla VBAK y el usuario técnico, solo utilicé un componente de tabla estándar, no se confunda aquí.

Conclusión: la configuración de la propagación del usuario técnico se realizó a través de una aplicación de software intermedio y la alineación del sistema backend para aceptar los certificados según el alias definido en las configuraciones del usuario técnico.