Clientes confidenciales

Visión general

Las aplicaciones móviles puede utilizar los SDK de cliente de MobileFirst para realizar una solicitud de acceso a los recursos protegidos.
También lo pueden hacer otras entidades que no sean aplicaciones móviles. Dichas entidades se consideran Clientes confidenciales.

Los clientes confidenciales son clientes capaces de mantener la confidencialidad de las credenciales de autenticación. Puede utilizar el servidor de autorización de MobileFirst para garantizar el acceso de clientes confidencial a recursos protegidos, de acuerdo con la especificación OAuth. Esta característica le permite acceder a los recursos de clientes no móviles como, por ejemplo, las aplicaciones de pruebas de rendimiento y cualquier otro tipo de fondo que necesite una solicitud a un recurso protegido o utilice una de las API REST de Mobile Foundation como, por ejemplo, la API REST para las notificaciones push.

Empiece con registrar un cliente confidencial con MobileFirst Server. Como parte del registro, proporcione las credenciales del cliente confidencial, que consisten en un ID y un secreto. Además, defina el ámbito permitido del cliente, que determina los ámbitos que se pueden conceder al cliente. Cuando un cliente confidencial registrado solicita una señal de acceso del servidor de autorización, el servidor autentica el cliente utilizando las credenciales registradas y verifica que el ámbito solicitado coincide con el ámbito permitido del cliente.

Los clientes confidenciales registrados pueden obtener una señal para utilizarla en todas las solicitudes en MobileFirst Server. Este flujo se basa en el flujo de credenciales de cliente de la especificación OAuth. Tenga en cuenta que la señal de acceso para un cliente confidencial es válida durante una hora. Si utiliza un cliente confidencial para una tarea que dura más de una hora, renueve la señal cada hora enviando una solicitud de señal nueva.

Registro del cliente confidencial

En la barra de navegación de MobileFirst Operations Console, pulse Valores de entorno de ejecución → Clientes confidenciales. Pulse Nuevo para añadir una nueva entrada.
Debe proporcionar la información siguiente:

• Nombre de visualización: Se utiliza un nombre de visualización opcional para hacer referencia al cliente confidencial. El nombre de visualización predeterminado es el valor del parámetro de ID. Por ejemplo: Servidor de nodo de fondo.
• ID: Un identificador único para el cliente confidencial (puede considerarse como “nombre de usuario”). El ID solo puede contener caracteres ASCII.
• Secreto: Una contraseña privada que permite autorizar el acceso del cliente confidencial (puede considerarse una clave de API). El secreto solo puede contener caracteres ASCII.
• Ámbito permitido: Al cliente confidencial que utiliza esta combinación de ID y secreto se le concede de forma automática el ámbito que se define aquí. Para obtener más información acerca de los ámbitos, consulte Ámbitos.
  • Un elemento de un ámbito permitido puede incluir el carácter comodín asterisco especial (*), que representa cualquier secuencia de cero o más caracteres. Por ejemplo, si el elemento de ámbito es send*, el cliente confidencial puede acceder a los ámbitos que contiene cualquier elemento de ámbito que empieza con “send” como, por ejemplo, “sendMessage”. El comodín asterisco puede colocarse en cualquier posición en el elemento de ámbito, y también puede aparecer más de una vez.
  • Un parámetro de ámbito permitido que consiste en un único carácter asterisco (*) indica que el cliente confidencial puede conceder una señal para cualquier ámbito.

Ejemplos de ámbitos:

• Protección de recursos externos utiliza el ámbito authorization.introspect.
• El envío de una notificación push mediante la API REST utiliza los elementos de ámbito separados por espacios messages.write y push.application. <applicationId>.
• Un elemento de ámbito personalizado puede proteger a los adaptadores, como por ejemplo accessRestricted.
• El ámbito * es un ámbito general que concede acceso a cualquier ámbito solicitado.

Clientes confidenciales predefinidos

MobileFirst Server tiene algunos clientes confidenciales predefinidos:

test

El cliente test solo está disponible en modo de desarrollo. Le permite probar los recursos de forma sencilla.

• ID: test
• Secreto: test
• Ámbito permitido: * (cualquier ámbito)

admin

El servicio de administración de Mobile Foundation utiliza el cliente admin de manera interna.

push

El servicio de push de Mobile Foundation utiliza el cliente push de manera interna.

Obtención de una señal de acceso

Se puede obtener una señal del MobileFirst Server punto final de señal.

Para realizar pruebas, puede utilizar Postman tal y como se describe a continuación.
En una situación real, implemente Postman en la lógica de fondo con la tecnología que desee.

1. Realice una solicitud POST a http(s)://[ipaddress-or-hostname]:[port]/[runtime]/api/az/v1/token.
   Por ejemplo: http://localhost:9080/mfp/api/az/v1/token
   • En un entorno de desarrollo, MobileFirst Server utiliza un tiempo de ejecución mfp preexistente.
   • En un entorno de producción, sustituya el valor de tiempo de ejecución con el nombre de tiempo de ejecución.
2. Establezca la solicitud con el tipo de contenido de application/x-www-form-urlencoded.
3. Establezca los dos parámetros de forma siguientes:
   • grant_type - Establezca el valor en client_credentials.

   • scope - Establezca el valor en un ámbito de protección del recurso. Si el recurso no se asigna a un ámbito de protección, omita este parámetro para aplicar el ámbito predeterminado (RegisteredClient). Para obtener más información, consulte Ámbitos.

     

4. Para autenticar la solicitud, utilice Autenticación básica. Utilice el ID y el secreto del cliente confidencial.

   

   Fuera de Postman, si utiliza el cliente confidencial test, establezca la cabecera HTTP ** en Authorization: Basic dGVzdDp0ZXN0 (test:test codificado utilizando **base64).

La respuesta para esta solicitud incluirá un objeto JSON, entre otros, la señal de acceso y la hora de caducidad (1 hora).

{
  "access_token": "eyJhbGciOiJSUzI1NiIsImp ...",
  "token_type": "Bearer",
  "expires_in": 3599,
  "scope": "sendMessage accessRestricted"
}

Utilización de la señal de acceso

A partir de este momento, puede realizar solicitudes a los recursos deseados añadiendo la cabecera HTTP: Authorization: Bearer eyJhbGciOiJSUzI1NiIsImp ..., sustituyendo la señal de acceso por una de las extraídas del objeto JSON anterior.

Respuestas posibles

Además de las respuestas normales que es posible que genere el recurso, estas son algunas de las respuestas que MobileFirst Server genera.

Bearer

Un estado de respuesta HTTP 401 con la cabecera HTTP WWW-Authenticate : Bearer significa que no se ha encontrado ninguna señal en la cabecera Authorization de la solicitud original.

invalid_token

Un estado de respuesta HTTP 401 con la cabecera HTTP WWW-Authenticate: Bearer error="invalid_token" significa que la señal que se ha enviado es inválida o ha expirado.

insufficient_scope

Un estado de respuesta HTTP 403 con la cabecera HTTP WWW-Authenticate : Bearer error="insufficient_scope", scope="RegisteredClient scopeA scopeB" significa que la señal encontrada en la solicitud original no coincide con la señal que el recurso necesita. La cabecera también incluye el ámbito esperado.

Cuando emite una solicitud, si no sabe qué ámbito necesita el recurso, utilice insufficient_scope para determinar el ámbito necesario. Por ejemplo, solicite una señal sin especificar un alcance y realice una solicitud al recurso. A continuación, puede extraer el ámbito necesario de la respuesta 403 y solicitar una nueva señal para este ámbito.