Autenticación de REST y control de acceso

En función de los servicios REST, pueden requerir autenticación o control de acceso.

Autenticación

Algunos servicios REST requieren autenticación. Para poder utilizar estos servicios REST debe, en primer lugar, obtener los datos de autenticación utilizando uno de los tres servicios de identidad:

loginidentity: Utiliza un nombre de usuario y una contraseña para autenticar a un usuario registrado.
guestidentity: Crea una identidad para un usuario invitado.
ltpaidentity: Utiliza una señal LTPA para autenticar a un usuario.

Debe enviar una solicitud POST a uno de los recursos REST, donde la respuesta contenga los datos siguientes:


{
  "WCToken": "xxxxxxxxxxxxxxxxxxx",
  "WCTrustedToken": "xxxxxxxxxxxxx",
  "personalizationID": "1321550980363-1",
  "userId": "2"
}

Tras obtener los datos de autenticación de forma satisfactoria, deberá pasar los elementos WCToken y WCTustedToken de la cabecera HTTP para cada solicitud que requiera autenticación. Si se envía una solicitud a través de HTTP, pase el elemento WCToken en la cabecera HTTP. Es decir, no pase el elemento WCTrustedToken en las solicitudes HTTP, porque podría mostrarse. No obstante, si se envía una solicitud a través de HTTPS, deben enviarse tanto WCToken como WCTrustedToken.

El fragmento de código siguiente es un ejemplo para establecer los elementos WCToken y WCTrustedToken en la cabecera HTTP:


HttpPost request = new HttpPost(secureUrl);

request.addHeader("Content-Type", "application/json");
request.addHeader("WCToken", wcToken);
request.addHeader("WCTrustedToken", wcTrustedToken);

Autenticación básica HTTP

El uso del estándar de autenticación básica de HTTP evita mantener una sesión. En su lugar, se puede llamar a la API de REST en el servidor HCL Commerce, especificando el nombre de usuario y la contraseña en cada solicitud. HCL Commerce valida las credenciales de usuario automáticamente y se genera un error si las credenciales no son válidas.

Esto se lleva a cabo utilizando la cabecera Authorization de la siguiente manera:

El nombre de usuario y la contraseña se combinan en una serie denominada username:password. No se soportan los nombres de usuario y las contraseñas que contienen un carácter de dos puntos (:).
Entonces la literal de serie resultante se codifica utilizando la variante RFC2045-MIME de Base64, excepto que no está limitado a 76 caracteres por línea.
El método de autorización y un espacio se ponen entonces antes de la serie codificada. Por ejemplo, Basic .

Por ejemplo, si el agente de usuario utiliza Aladdin como nombre de usuario y open sesame como contraseña, la cabecera se forma de la siguiente manera:


Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Control de acceso

Existe el comportamiento de control de acceso siguiente para los servicios REST:

Para operaciones Create, Update y Delete:

Los servicios REST deben envolver los mandatos BOD o mandatos de controlador para imponer el control de acceso. Ésta es la única opción soportada y segura.

Para operaciones Get:

Los servicios REST deben envolver los mandatos BOD o beans de datos para que se imponga el control de acceso.
REST sobre beans de datos: El control de acceso se impone si el bean de datos subyacente implementa la interfaz Delegator. Si el bean de datos no implementa la interfaz Delegator, se puede llamar utilizando el enlace local a través de archivos JSP, suponiendo que el bean de datos no exponga datos confidenciales al usuario final. Si está utilizando el enlace remoto a través de llamadas de servicio REST y el bean de datos no implementa la interfaz Delegator, solo un Administrador de sitio puede ejecutar la llamada de servicio de forma predeterminada. Esto se puede personalizar alterando el método isSiteResource(DataBean) de la clase de manejador de recursos REST.