XSUAA – Nivel básico

El artículo de hoy nace de una duda que me surgía siempre que realizaba tutoriales de CAPm en la página oficial de SAP. Así que me he decidido a publicar este post para contar 2 de las autorizaciones básicas que nos brinda el servicio de XSUAA.

Para los que no lo conozcáis, el servicio de XSUAA nos permite conectar los servicios de autorizaciones de nuestras cuentas BTP con nuestras aplicaciones de manera rápida y fácil.

Y… ¿como funciona? En el caso de CAPm, la cosa es bastante sencilla, únicamente tenemos que añadir una coletilla de seguridad al servicio:

service CustomerService @(requires: 'authenticated-user'){
  entity Orders @(restrict: [ 
    { grant: ['READ','WRITE'], to: 'admin' },
  ])
  entity Approval @(restrict: [
    { grant: 'WRITE'} 
  ])
}

En este ejemplo sencillo vemos que para obtener la información del servicio necesitamos un usuario conectado.

¿Qué tipo de seguridad tenemos?

A modo rápido en CAPm podemos añadir:

• Seguridad básica con Key: utiliza with @(requires: ‘system-user’);
• Seguridad usando usuario: with @(requires: ‘authenticated-user’);
• Seguridad usando scopes: with @(requires: [‘Vendor’, ‘ProcurementManager’]);

Los scopes los veremos mas adelante, pero ahora nos vamos a centrar en los dos primeros ya que los manuales, siempre comenta que después de añadir la seguridad tu usuario debería tener un tipo de scope llamado openid.

Pero como lo hacemos para que nos aparezca. Aquí entra el motivo de esta entrada. Como accedemos a los servicios con los distintos tipos de seguridad.

Acceso según tipo de seguridad

System-user

Esta es la manera más básica y la que usaremos si lo que queremos son APIs para integraciones o para conectar aplicaciones cuando los sistemas no están bajo el paraguas del mismo SSO. O dicho en otras palabras, cuando queremos un usuario y un password y no complicarnos mucho la vida.

Para este tipo de seguridad solo necesitaremos crear una instancia de XSUAA sin parámetros adicionales y crear una key.

Los datos para obtener el token los tenemos disponibles en la Key:

Estos son los datos que utilizáremos para obtener el token, recordar que este «Bearer Token» es el que necesitamos para tener autorización para usar las APIs.

Para la llamada vamos a utilizar el valor de la URL + «/oauth/token». Tambien necesitaremos un parametro «?grant_type=client_credentials» y el usuario y contraseña.

La llamada en postman quedaría así:

Y aquí viene el punto interesante, cuando nos devuelve la información aparece el scpoe uaa.resource, este esta asignado a las service key. Esto no es critico cuando estamos con CAPm, ya que la anotación que os he comentado convierte este scope, pero si estáis trasteando con alguna otra API (node.js, Java, Python) necesitareis indicar este scope y no el openid.

Authenticated-user

Este método os lo explico mas por el concepto que porque lo tengáis que usar ya que es típico usarlo cuando existe un puente entre aplicaciones o sistemas, es decir, están bajo el paraguas de un SSO. Lo veréis rápido el porque.

Para este tipo de seguridad, tampoco es necesario añadir ningún parámetro en la creación del XSUAA ya que solo queremos conocer si el usuario tiene acceso al sistema.

Aquí entra en juego el openid, ya que en el caso que el usuario pueda acceder al sistema, tendrá el scope openid por defecto.

Como estamos en un mundo de microservicios, también necesitaremos los datos del servicio XSUAA que hemos usado en el punto anterior, pero ahora a demás sumaremos los datos de login del usuario.

Volveremos a usar el parametro URL + «/oauth/token» y necesitaremos un parámetro extra «?grant_type=password». Esta sera la llamada:

Y al realizar la llamada, este será el resultado:

Como veis el scope ha cambiado. Esto es importante, porque como os he comentado, cuando nos salimos de las CDS, podemos diferenciar que queremos dar acceso con «usuarios genéricos» o permitir usuarios nominales.

Scopes concretos asignados a rol

Este último punto lo paddies tomar como un extra, pero ya que estamos hablando de seguridad, he visto interesante comentarlo.

Pues bien, si lo que queremos es hacer una criba de accesos, para por exemplo limitar el acceso a determinados usuarios, podemos utilizar roles.

Para no extenderme en el concepto de Roles – Rol collection – Scope, os dejo esta entrada donde comentaba su estructura.

Deconstrucción de una aplicación UI5 en Cloud Foundry

En este caso, si que necesitamos añadir parámetros en la creación del servicio XSUAA. Os muestro un ejemplo, este json, en caso de un proyecto que despleguéis mediante MTAR estaría en el fichero security.json de vuestro proyecto.

{
  "xsappname" : "node-hello-world", 
  "scopes"     : [ { 
                    "name" : "$XSAPPNAME.Display", 
                    "description" : "display" }, 
                    { 
                    "name" : "$XSAPPNAME.Edit", 
                    "description" : "edit" },
                    { 
                    "name" : "$XSAPPNAME.Delete", 
                    "description" : "delete" }
],
 "role-templates": [ { 
                    "name"                : "ViewerAuth", 
                    "description"         : "View all books", 
                    "default-role-name": "Viewer: Authorized to Read All Books",
                    "scope-references"    : [ "$XSAPPNAME.Display" ]
                    }, 
                   { 
                    "name"               : "EditorAuth", 
                    "description"        : "Edit, delete books", 
                    "scope-references"   : [ 
                                          "$XSAPPNAME.Edit", 
                                          "$XSAPPNAME.Delete" ]
                    } 
                   ],
"role-collections": [
        {
         "name": "DisplayTest",
         "description": "Test for display",
         "role-template-references": [
                                    "$XSAPPNAME.ViewerAuth"
                                     ]
        },
                {
         "name": "EditTest",
         "description": "Test for edit",
         "role-template-references": [
                                    "$XSAPPNAME.EditorAuth"
                                     ]
        }
    ]
}

Vamos a deconstruir este fichero:

• Lo primero es darle un nombre al servicio, que la mayoría de veces coincidirá con el nombre de nuestro proyecto/aplicación
• Lo segundo son los Scopes, esta es la parte que va ligada a los controles que añadimos a nuestra aplicación. En el caso del ejemplo, podriamos tener en nuestra definicion de servicio de CAPm algo como with @(requires: [‘Display’]); que obligaría al usuario a tener este scope para acceder a la entidad.
• Lo siguiente que definimos son los roles o role-templates, que son la union entre el Scope (aplicación) y el role collection ( donde asignamos los usuarios). De esta manera, tendremos el servicio definido y no tendremos que crear colecciones de roles a mano.

El resultado de añadir esta configuración a la creación de un XSUAA es que automáticamente tendremos en nuestro coockpid los roles apunto:

Ahora solo tenemos que ir a uno de los roles o a los dos y añadir el usuario que quedemos que tenga visibilidad:

Si realizamos la misma llamada que en el punto anterior, ahora veremos que nos aparecen scopes extra:

Como veis, ahora podéis jugar con los scopes para que un usuario pueda o no pueda entrar.

Reset password de tu usuario

Un truco extra para los que aguantáis el post hasta el final. Des de que SAP saco el universal ID, es difícil resetear el password de un usuario (necesario por ejemplo para usar el cliente de CF o jugar con las APIS de autentificación).

Pues bien, si queréis resetear vuestro password sin afectar al universal ID solo tenéis que acceder a la pagina oficial de vuestra cuenta SAP:

• https://accounts.sap.com/

Y hasta aquí esta breve clase sobre scopes y XSUAA

Como siempre suscribete, dale a la campanita de notificaciones y comparte en redes para estar a la última