En el mundo actual, casi no se construye ninguna aplicación en la que no haya distinción entre diferentes usuarios, roles o derechos. Por supuesto, lo mismo también se aplica a las aplicaciones SAP UI5 que se ejecutan en SAP Business Technology Platform. En este pequeño post me gustaría entrar en más detalle sobre la configuración de una aplicación para el acceso basado en roles.

Comencemos con el escenario de destino: el punto de partida es una aplicación SAP UI5, que se desarrolló utilizando una herramienta de su elección y se ejecuta en el BTP. Solo los usuarios que tienen un rol específico deben tener acceso a esta aplicación. Los usuarios con sus grupos se mantienen en un inquilino IAS propio y la aplicación en sí está disponible a través de una plataforma de lanzamiento (o SAP Build Workzone). La siguiente figura muestra el escenario esquemáticamente. Un líder de equipo tendrá acceso a la aplicación y un miembro normal del equipo no tiene acceso.

Escenario de acceso basado en roles

Descargo de responsabilidad: describo los pasos individuales requeridos y hago referencia a otras fuentes de información si es necesario. Esta publicación de blog no es una guía completa para asegurar su propia aplicación.

Primero, la aplicación UI5 debe estar protegida. Puede encontrar un buen comienzo para crear la aplicación y configurar los aspectos de seguridad en:

El archivo xs-security.json se usa para asignar su propio rol. Este archivo se crea automáticamente al generar el AppRouter (administrado o independiente) para la aplicación.

Ajustes en xs-security.json

La mejor unidad para controlar los permisos es el alcance. Esto debe crearse en xs-security.json. En nuestro caso, ahí definimos al líder del equipo. El nombre del ámbito contiene una referencia al nombre de la aplicación, por lo que al final el ámbito es específico de la aplicación.

"scopes": [
    ...,
    {
      "name": "$XSAPPNAME.Teamlead",
      "description": "Teamlead"
    }
  ],

Una aplicación puede definir cualquier número de ámbitos. A continuación, los ámbitos se pueden agrupar en roles. Esto permite un control de autorización detallado.

A continuación, se crea la plantilla para el rol correspondiente. Luego, este rol está disponible en la cabina de BTP para su asignación a colecciones de roles. La plantilla de función hace referencia a todos los ámbitos para los que se debe autorizar la función.

"role-templates": [
    ...,
    {
      "name": "Teamlead",
      "description": "Teamlead within the project",
      "scope-references": [
        "$XSAPPNAME.Teamlead"
      ],
      "attribute-references": []
    }
  ]

Atención: las colecciones de roles también se pueden definir en xs-security.json. Si hace esto, las colecciones de roles creadas con él no se pueden usar en el Launchpad. Así que es mejor prescindir de esta función.

Ajustes en xs-app.json

Ahora se definen el alcance y la plantilla de roles para el líder del equipo. Ahora debe asegurarse de que la aplicación solo pueda ser utilizada por el líder del equipo. Para hacer esto, se debe adaptar xs-app.json. Este archivo define qué rutas son atendidas por la aplicación y cómo deben protegerse.

{
  "welcomeFile": "/index.html",
  "authenticationMethod": "route",
  "routes": [
    ...,   
    {
      "source": "^(.*)$",
      "target": "$1",
      "service": "html5-apps-repo-rt",
      "authenticationType": "xsuaa",
      "scope": [ "$XSAPPNAME.Teamlead" ]
    }
  ]
}

Ahora solo el líder del equipo puede usar la aplicación. Por lo tanto, el alcance envía el acceso a la ruta en la aplicación. Si se definen varias rutas, también se puede actuar allí con restricciones en función del alcance.

Nota: si la aplicación utiliza datos de sistemas de terceros, el acceso a estos datos y los roles correspondientes también deben estar restringidos allí. Esto significa que verificar si un usuario puede ver datos no debe dejarse solo en manos de la aplicación UI5. En el caso del Modelo de Programación de Aplicaciones en la Nube, recomiendo echar un vistazo al recetario correspondiente: https://cap.cloud.sap/docs/guides/authorization

La aplicación ahora es autoprotegida. A continuación, se debe crear un grupo en el IAS que agrupe los derechos necesarios. Teóricamente, los grupos se pueden definir de forma completamente independiente en el IAS sin tener una referencia específica a roles/ámbitos en la aplicación UI5. La forma más fácil es asignar nombres de grupos directamente a nombres de colecciones de roles en BTP. Esto facilita el seguimiento de qué grupo tiene qué derechos.

En el IAS, la definición de grupo es muy simple debajo del mosaico Usuario y autorizaciones => Grupos de usuarios, se pueden gestionar todos los grupos de usuarios. Aquí es donde crea el nuevo grupo para la aplicación.

Definición de grupo en IAS

El grupo ahora se puede asignar a los usuarios que deberían tener acceso a la aplicación. La administración de grupos y usuarios está muy bien documentada en la ayuda: Grupos de Usuarios

El siguiente paso es configurar los roles requeridos en el Launchpad. Supuesto: la aplicación ya se ha configurado y está disponible para su uso. Se puede almacenar un nuevo rol a través del sitio Administrador => Administrador de contenido. El rol tiene un nombre y una identificación única. Al igual que con la configuración del grupo en el IAS, el nombre se puede asignar libremente y no necesariamente tiene que estar relacionado con las configuraciones de roles/grupos existentes. Por supuesto, es más fácil volver a utilizar los mismos nombres. No olvide asignar las aplicaciones accesibles por un usuario con el nuevo rol.

Configuración de roles en el launchpad

El nuevo rol ahora se ha definido de forma genérica en el servicio Launchpad y, por lo tanto, está disponible para todos los sitios específicos. Para que el sitio pueda usar el rol, aún debe agregarse. Esto se hace a través de la configuración del sitio. Editar esto permite agregar el rol al sitio.

Asignar rol al sitio

Todos los servicios y aplicaciones involucrados ahora conocen el nuevo rol. Para que estos funcionen juntos, aún se deben hacer algunas cosas en la cabina de SAP BTP. Cuando se creó el rol en la plataforma de lanzamiento, se creó una colección de roles correspondiente en la cabina. La colección de funciones ahora está ampliada:

El rol necesario de la aplicación SAPUI5 se agrega en el área Roles. Esto significa que cualquier persona que tenga acceso a la Colección de roles también tiene acceso a la aplicación correspondiente. A continuación, el grupo de usuarios de IAS se debe agregar al área Grupos de usuarios. Cada usuario con el grupo de usuarios de IAS correspondiente ahora se asigna automáticamente a la colección de funciones.

Asignación de grupos de usuarios de IAS

Si todos los pasos se han llevado a cabo correctamente, solo los usuarios con el rol necesario ahora verán la aplicación, independientemente de si acceden a ella directamente o a través del Launchpad.

Con unos pocos pasos simples, se puede configurar un escenario en el que el acceso a una aplicación SAPUI5 se controla a través de IAS y luego se tiene en cuenta en todos los puntos relevantes. Es importante que se lleven a cabo todos los pasos y no se configure demasiado. Como se mencionó anteriormente, si la colección de roles se crea directamente en xs-security.json, no se puede configurar fácilmente en el Launchpad. El Launchpad mostrará una excepción si se agrega una función con el mismo nombre de una colección de funciones existente.

Si ahora necesita atributos adicionales del IAS en la aplicación, puedo recomendar la siguiente publicación de blog: Mapeo de atributos SAML con XSUAA JWT en Cloud Foundry También es esencial pensar en los atributos necesarios en una etapa temprana. Si crea plantillas de roles sin referencias de atributos en la aplicación UI5, los roles se crean automáticamente con la implementación. Si luego agrega atributos, los roles en SAP BTP Cockpit no se pueden ajustar automáticamente en consecuencia, por lo que aquí es necesaria la intervención manual.

Otro aspecto importante a la hora de definir la configuración de seguridad es el tipo de credencial. Aquí puedes encontrar algunos aspectos interesantes: ¿Por qué los desarrolladores deberían preocuparse por los tipos de credenciales para xsuaa?.

¿Cuáles son sus experiencias y trucos al configurar roles/derechos en el universo SAPUI5, BTP, launchpad/workzone?