Contrôle d'authentification et d'accès REST

Les services REST peuvent nécessiter un contrôle d'authentification ou d'accès en fonction de leur type.

Authentification

Certains services REST nécessitent une authentification. Pour utiliser ces services REST, vous devez d'abord obtenir des données d'authentification à l'aide de l'un des trois services d'identité :
loginidentity
Utilise un nom d'utilisateur et un mot de passe pour authentifier un utilisateur enregistré.
guestidentity
Crée une identité pour un utilisateur invité.
ltpaidentity
Utilise un jeton LTPA pour authentifier un utilisateur.
Vous devez envoyer une demande POST à l'une des ressources REST où la réponse contient les données suivantes :

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

Après avoir obtenu les données d'authentification, vous devez transmettre les jetons WCToken et WCTustedToken dans l'en-tête HTTP de chaque demande qui nécessite une authentification. Si une demande est envoyée via HTTP, transmettez le jeton WCToken dans l'en-tête HTTP. Autrement dit, ne transmettez pas le jeton WCTrustedToken dans des demandes HTTP car il risquerait de s'afficher. En revanche, les deux jetons WCToken et WCTrustedToken doivent être envoyés si une demande est envoyée via HTTPS.

Le fragment suivant est un exemple de définition des jetons WCToken et WCTrustedToken dans l'en-tête HTTP :

HttpPost request = new HttpPost(secureUrl);

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

Authentification de base HTTP

L'utilisation de la norme d'authentification de base HTTP permet d'éviter de maintenir une session. Au lieu de cela, l'API REST du serveur HCL Commerce peut être appelée, en spécifiant le nom d'utilisateur et le mot de passe sur chaque requête. HCL Commerce valide automatiquement les informations d'identification de l'utilisateur, et une erreur est générée si les informations d'identification ne sont pas valides.

Pour ce faire, on utilise l'en-tête Authorization de la manière suivante :
  1. Le nom d'utilisateur et le mot de passe sont combinés dans une chaîne appelée username:password. Les noms d'utilisateur et mots de passe qui contiennent un caractère deux points (:) ne sont pas pris en charge.
  2. Le littéral chaîne résultant est ensuite codé à l'aide de la variante RFC2045-MIME de Base64, sauf qu'elle n'est pas limitée à 76 caractères par ligne.
  3. La méthode d'autorisation et un espace sont ensuite placés devant la chaîne codée. Par exemple, Basic .
Par exemple, si l'agent utilisateur utilise Aladdin comme nom d'utilisateur et open sesame comme mot de passe, l'en-tête est formé de la manière suivante :

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Contrôle d'accès

Le comportement de contrôle d'accès suivant existe pour les services REST :

Pour les opérations Créer, Mettre à jour et Supprimer :
  • Les services REST doivent encapsuler les commandes BOD ou les commandes de contrôleur pour que le contrôle d'accès soit appliqué. Il s'agit de la seule option prise en charge et sécurisée.
Pour les opérations GET :
  • Les services REST doivent encaspuler les commandes BOD ou les beans de données pour que le contrôle d'accès soit appliqué.
  • REST sur les beans de données : Le contrôle d'accès est appliqué si le bean de données sous-jacent implémente l'interface Delegator. Si le bean de données n'implémente pas l'interface Delegator, il peut être appelé à l'aide de liaison locale via des fichiers JSP, en supposant que le bean de données n'expose pas les données sensibles à l'utilisateur final. Si vous utilisez la liaison à distance via les appels de service REST et que le bean de données n'implémente pas l'interface Delegator, seul un administrateur de site peut exécuter l'appel de service par défaut. Ce paramètre peut être personnalisé en remplaçant la méthode isSiteResource(DataBean) de la classe du gestionnaire de ressources REST.