Guide administrateur : Autorisation de Journey

Qu’est-ce que l’autorisation de Journey ?

L’autorisation de Journey ne concerne pas la connexion de vos clients. Il s’agit de protéger la façon dont votre Journey est consulté et affiché.

Lorsque vous activez l’autorisation sur un Custom Journey (avec un composant d’entrée), vous garantissez que le Journey ne peut s’exécuter que via votre couche web approuvée (appelée le renderer) — là où s’appliquent vos règles métier, votre logique de personnalisation et vos contrôles de conformité.

Sans autorisation, quelqu’un pourrait tenter d’accéder directement au Journey et de contourner ces règles. Cela pourrait :

  • Afficher un contenu incorrect
  • Ignorer des contrôles juridiques ou la validation d’une offre
  • Perturber l’expérience client prévue

L’autorisation de Journey empêche cela.

Pourquoi est-ce important pour les marketeurs ?

L’activation de l’autorisation de Journey vous aide à :

  • Protéger votre marque et la conformité : Les contrôles juridiques, les règles d’éligibilité et la logique de personnalisation sont toujours appliqués.

  • Garantir une expérience cohérente : Les clients ne peuvent pas accéder à des versions incomplètes ou non souhaitées de votre Journey.

  • Éliminer les failles de sécurité : Une fois activée, le Journey ne peut plus être consulté d’une manière qui contourne les règles que vous avez configurées.

En bref : votre Journey s’exécute toujours comme vous l’avez conçu.

 

Ce qui se passe en coulisses

Lorsque l’autorisation est activée :

  • Le Journey est épinglé à un renderer (couche web sécurisée).
  • Si quelqu’un tente d’accéder directement au Journey :
    • il est automatiquement redirigé via le renderer sécurisé, ou
    • l’accès est refusé.
  • Le trafic client normal n’est pas affecté.
  • Les tentatives d’accès non autorisées sont bloquées.

Pour l’utilisateur final, rien ne change — il voit simplement la bonne expérience.

 

Configurer l’autorisation de Journey

Suivez les étapes ci-dessous pour activer l’autorisation sur un Custom Journey.

1. Dans les propriétés d’un Custom Journey avec un composant d’entrée, ouvrez le menu de gauche Advanced :

2. Activez l’option Require authorization for all online actions.

3. Ensuite, cliquez sur le Input Component du Custom Journey pour accéder aux propriétés et sauvegarder le lien anonyme qui devient disponible après la publication du Journey. Ce lien anonyme est votre point d’accès à ce Journey.

4. Une fois l’autorisation activée pour un Journey, vous devez configurer un compte de service de type Rendering.

5. Allez dans Admin configuration/Access Mgmt et activez l’entrée Service account.
Créez un nouveau compte de service de type rendering.

6. Une fois enregistré, copiez la clé et le secret pour une utilisation ultérieure.

 

Appliquer l’autorisation de Journey pour sécuriser vos Journeys

Il existe deux scénarios principaux lorsque vous utilisez l’autorisation de Journey pour sécuriser l’accès aux Journeys :

  • utiliser le content renderer générique de Selligent
  • utiliser des applications web personnalisées ou d’autres applications Selligent

Scénario 1 : Sécuriser les Journeys avec le content renderer générique de Selligent

L’autorisation au niveau du Journey impose l’utilisation du chemin sécurisé

  • Avec l’autorisation activée au niveau du Journey, ces Journeys ne peuvent être chargés que via le chemin sécurisé.
  • Seuls les utilisateurs provenant d’IP autorisées peuvent accéder au contenu du Journey.
  • L’utilisation du lien non sécurisé renvoie une erreur au lieu de charger le contenu.

Ce que cela signifie pour les marketeurs

  • Seuls les environnements approuvés peuvent charger votre Journey.
  • L’utilisation accidentelle de liens incorrects n’exposera pas le contenu.
  • La sécurité est appliquée automatiquement.

 

Modifier la configuration du content renderer sécurisé

Introduction

Un Journey qui utilise le content renderer générique de Selligent avec filtrage IP intégré (via l’URL /secure/ — cf. Https://your_domain/renderers/swagger/ui/index#/Content) peut être verrouillé plus strictement en appliquant l’autorisation de Journey.

Comme le Journey utilise le content renderer avec filtrage IP, la table CFG_CR_IPSEC contient déjà la configuration de filtrage IP nécessaire pour ce Journey.

Pour épingler le renderer au Journey via l’autorisation de Journey, la seule modification requise est d’étendre l’enregistrement de configuration existant pour le Journey avec un compte de service de rendu valide.

Les étapes ci-dessous expliquent précisément comment procéder.

Mettre à jour la table de configuration du content renderer

La table CFG_CR_IPSEC est utilisée pour inclure le rendu sécurisé des Journeys. L’enregistrement de configuration contient :

  • ID(s) de Journey
  • Adresses IP approuvées
  • Clé du compte de service

Le champ ‘SERVICEACCOUNT_KEY’ est un champ optionnel qui peut être utilisé pour choisir quel Journey doit utiliser les identifiants du compte de service créé ci-dessus. Toutefois, lorsque vous souhaitez charger le contenu d’un Journey pour lequel l’authentification est activée, vous devez ajouter une configuration dans cette table :

Champ Exemple Description
ID 1 Identifiant de l’enregistrement (renseigné automatiquement)
NAME Invoice Nom du paramètre de configuration
JMS 451,815 Liste des ID de Journeys. Utilisez une virgule pour séparer plusieurs ID.
IIPS 10.0.5.8,172.0.5.7 Liste des IP autorisées. Utilisez une virgule pour séparer plusieurs IP.
SERVICEACCOUNT_KEY FIreOJ545fezvv87Qz4vez== Clé générée pour le compte de service de type Rendering

Note:
Pour récupérer l’ID du Journey créé à l’étape 1 :
SELECT ID FROM CAMPAIGNS WITH(NOLOCK) WHERE NAME = '{YourJourneyName}' ORDER BY ID DESC
Utilisez cet ID pour insérer un enregistrement dans la table CFG_CR_IPSEC.
INSERT INTO CFG_CR_IPSEC(NAME, IPS, JMS, SERVICEACCOUNT_KEY)
VALUES('{YourConfigurationName}','{OneOrMore_Ips}', '{OneOrMoreJourneys}' , '{YourServiceAccountKEY_From_Step_2}')

 

Tester la configuration du content renderer sécurisé

L’utilisation de l’autorisation de Journey garantit que l’utilisation du lien anonyme du Custom Journey sans le chemin /secure/ se traduit par une erreur : 200 - aucun contenu. Lorsque vous utilisez le lien anonyme avec le chemin ‘secure’, vous obtenez le contenu réel (sauf si votre IP ne figure pas dans la liste CFG_CR_IPSEC. Lors de ce contrôle, le fichier de log enregistre l’IP si l’authentification échoue).

Accéder au Journey via le renderer sécurisé (chemin /secure/)

Suivez les étapes ci-dessous pour vérifier que les paramètres d’accès du Journey fonctionnent comme prévu : lorsque vous utilisez le renderer sécurisé, les adresses IP sont comparées à la liste des IP approuvées :

Ouvrez le lien du Journey sécurisé en utilisant le lien du renderer sécurisé (par exemple via l’API Explorer).

Résultat attendu :

  • pour les requêtes effectuées depuis une IP approuvée (whitelistée) => le contenu se charge correctement et vous pouvez afficher le contenu du Journey sans erreur

  • pour les requêtes effectuées depuis une IP non approuvée (par exemple, un réseau personnel sans VPN) => l’accès doit être refusé. Vous verrez un message d’erreur ou recevrez un “Access Denied”.

Tenter d’accéder directement au Journey

Suivez les étapes ci-dessous pour vérifier que le renderer rend impossible l’accès au Journey sans passer par le renderer, ce qui signifie que l’accès depuis des IP non whitelistées n’est plus possible :

Ouvrez le lien du Journey sécurisé en utilisant l’API /content/default (ou en utilisant un lien optiextension direct).

Résultat attendu :

  • Auparavant, les requêtes provenant d’IP non whitelistées accédant au contenu via tout moyen autre que le renderer sécurisé auraient pu aboutir.

  • Après avoir épinglé le renderer au Journey, les requêtes provenant d’IP non whitelistées accédant au contenu via tout moyen autre que le renderer sécurisé sont désormais rejetées (accès refusé)

 

Sécuriser les Journeys via des applications web personnalisées ou d’autres applications Selligent

Modifier l’application

Une application qui utilise le contenu d’un Journey effectue généralement les opérations suivantes :

  1. Appliquer la logique métier

  2. Effectuer un appel côté serveur vers le endpoint optiextension (directement ou via une bibliothèque) pour récupérer le contenu

  3. Intégrer le contenu récupéré dans l’application et le présenter à l’utilisateur

 

Pour empêcher le contournement de la logique métier de ces applications, nous épinglons l’application au Journey à l’étape 2 en fournissant un en-tête d’autorisation (Basic) supplémentaire.

Format de l’en-tête d’autorisation :

Copier 
'Authorization: basic base64(<serviceaccount_key + ':' + <serviceaccount_secret>)'.

Exemple : Pour un compte de service avec key = 'mykey' et secret = 'mysecret', l’en-tête devient :
'Authorization: Basic bXlrZXk6bXlzZWNyZXQ='

IMPORTANT :
L’en-tête d’autorisation doit être ajouté UNIQUEMENT côté serveur entre l’application et l’optiextension.
Ne divulguez jamais :
- La clé du compte de service
- Le secret du compte de service
En cas d’exposition, la sécurité est compromise.

Tester l’application

Après la configuration :

  • Accédez au Journey via l’application. Le contenu attendu se charge normalement.

  • Accédez au Journey directement, sans en-tête d’autorisation. La requête est rejetée (accès refusé), car une requête directe normale n’inclut pas le bon en-tête d’autorisation.

Note : À des fins de test, vous pouvez utiliser Postman, Bruno, Curl ou tout autre outil client HTTP pour injecter l’en-tête Authorization dans une requête directe vers l’optiextension afin de vérifier si le Journey est bien verrouillé ou non, selon la présence ou l’absence d’un en-tête Authorization valide.

Voici un exemple avec Postman.
1. En utilisant le lien anonyme sans autorisation, on obtient l’erreur suivante :

2. En utilisant le même lien anonyme mais avec une autorisation Basic basée sur la clé et le secret générés par le compte de service, le contenu est renvoyé correctement :