Configurer les informations d’identification et l’authentification du réseau CDN cdn-credentials-authentication

Le réseau CDN fourni par Adobe dispose de plusieurs fonctionnalités et services, dont certains reposent sur des informations d’identification et d’authentification afin d’assurer un niveau approprié de sécurité d’entreprise. En déclarant des règles dans un fichier de configuration déployé à l’aide du pipeline Cloud Manager config, les clients peuvent configurer les éléments suivants en libre-service :

Chacune de ces options, y compris la syntaxe de configuration, est décrite dans sa propre section ci-dessous.

Il existe une section sur la rotation de clés, qui est une bonne pratique de sécurité.

Valeur de l’en-tête HTTP du réseau CDN géré par le client CDN-HTTP-value

Comme indiqué dans la page Réseau CDN dans AEM as a Cloud Service, les clients peuvent choisir d’acheminer le trafic via leur propre réseau CDN, qui est appelé réseau CDN client (également parfois appelé BYOCDN).

Dans le cadre de la configuration, le réseau CDN d’Adobe et le réseau CDN client doivent convenir d’une valeur de l’en-tête HTTP X-AEM-Edge-Key. Cette valeur est définie sur chaque requête sur le réseau CDN client, avant d’être acheminée vers le réseau CDN Adobe, qui valide ensuite que la valeur est comme prévu, afin qu’il puisse approuver d’autres en-têtes HTTP, y compris ceux qui permettent d’acheminer la requête vers l’origine AEM appropriée.

La valeur X-AEM-Edge-Key est référencée par les propriétés edgeKey1 et edgeKey2 dans un fichier nommé cdn.yaml ou similaire, quelque part sous un dossier de config de niveau supérieur. Lisez Utilisation des pipelines de configuration pour plus d’informations sur la structure de dossiers et sur le déploiement de la configuration. La syntaxe est décrite dans l’exemple ci-dessous.

Pour plus d’informations sur le débogage et les erreurs courantes, consultez la section Erreurs courantes.

kind: "CDN"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  authentication:
    authenticators:
      - name: edge-auth
        type: edge
        edgeKey1: ${{CDN_EDGEKEY_052824}}
        edgeKey2: ${{CDN_EDGEKEY_041425}}
    rules:
      - name: edge-auth-rule
        when: { reqProperty: tier, equals: "publish" }
        action:
          type: authenticate
          authenticator: edge-auth

Voir la section Utiliser les pipelines de configuration pour obtenir une description des propriétés situées au-dessus du nœud data. La valeur de la propriété kind doit être CDN et la propriété version doit être définie sur 1.

Pour plus d’informations🔗 consultez l’étape de tutoriel Configurer et déployer une règle CDN de validation d’en-tête HTTP .

Les propriétés supplémentaires sont les suivantes :

Migration en toute sécurité pour réduire le risque de trafic bloqué migrating-safely

Si votre site est déjà actif, soyez prudent lors de la migration vers le réseau CDN géré par le client, car une mauvaise configuration peut bloquer le trafic public. En effet, seules les requêtes présentant la valeur d’en-tête X-AEM-Edge-Key attendue seront acceptées par le réseau CDN Adobe. Une approche est recommandée lorsqu’une condition supplémentaire est temporairement incluse dans la règle d’authentification, ce qui entraîne le blocage de la requête uniquement si un en-tête de test est inclus ou si un chemin d’accès correspond :

    - name: edge-auth-rule
        when:
          allOf:
            - { reqProperty: tier, equals: "publish" }
            - { reqHeader: x-edge-test, equals: "test" }
        action:
          type: authenticate
          authenticator: edge-auth

    - name: edge-auth-rule
        when:
          allOf:
            - { reqProperty: tier, equals: "publish" }
            - { reqProperty: path, like: "/test*" }
        action:
          type: authenticate
          authenticator: edge-auth

Le modèle de requête curl suivant peut être utilisé :

curl https://publish-p<PROGRAM_ID>-e<ENV-ID>.adobeaemcloud.com -H "X-Forwarded-Host: example.com" -H "X-AEM-Edge-Key: <CONFIGURED_EDGE_KEY>" -H "x-edge-test: test"

Une fois le test réussi, la condition supplémentaire peut être supprimée et la configuration redéployée.

Processus de migration si la prise en charge d’Adobe a précédemment généré la valeur d’en-tête HTTP X-AEM-Edge-Key migrating-legacy

Auparavant, le processus d’intégration à un réseau CDN géré par le client impliquait que les clients demandant une valeur d’en-tête HTTP X-AEM-Edge-Key à l’assistance Adobe, plutôt que de définir la valeur eux-mêmes. Pour migrer vers la nouvelle approche en libre-service dans laquelle vous définissez vos propres valeurs de clé Edge, procédez comme suit pour assurer une transition fluide sans temps d’arrêt :

Purger le jeton API purge-API-token

Les clients peuvent purger le cache du réseau CDN en utilisant un jeton API de purge déclaré. Le jeton est déclaré dans un fichier nommé cdn.yaml ou similaire, quelque part sous un dossier de config de niveau supérieur. Lisez Utilisation des pipelines de configuration pour plus d’informations sur la structure de dossiers et sur le déploiement de la configuration.

La syntaxe est décrite ci-dessous :

kind: "CDN"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  authentication:
    authenticators:
       - name: purge-auth
         type: purge
         purgeKey1: ${{CDN_PURGEKEY_031224}}
         purgeKey2: ${{CDN_PURGEKEY_021225}}
    rules:
       - name: purge-auth-rule
         when: { reqProperty: tier, equals: "publish" }
         action:
           type: authenticate
           authenticator: purge-auth

Voir la section Utiliser les pipelines de configuration pour obtenir une description des propriétés situées au-dessus du nœud data. La valeur de la propriété kind doit être CDN et la propriété version doit être définie sur 1.

Les propriétés supplémentaires sont les suivantes :

Vous pouvez consulter un tutoriel axé sur la configuration des clés de purge et l’exécution de la purge du cache du réseau CDN.

Authentification de base basic-auth

Protégez certaines ressources de contenu en affichant une boîte de dialogue d’authentification de base nécessitant un nom d’utilisateur ou d’utilisatrice et un mot de passe. Cette fonctionnalité est principalement destinée aux cas d’utilisation d’authentification légers tels que l’examen du contenu par les parties prenantes de l’entreprise, plutôt qu’à une solution complète pour les droits d’accès des utilisateurs finaux.

Une boîte de dialogue d’authentification de base s’affiche pour l’utilisateur final, comme suit :

La syntaxe est la suivante :

kind: "CDN"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  authentication:
    authenticators:
       - name: my-basic-authenticator
         type: basic
         credentials:
           - user: johndoe
             password: ${{JOHN_DOE_PASSWORD}}
           - user: janedoe
             password: ${{JANE_DOE_PASSWORD}}
    rules:
       - name: basic-auth-rule
         when: { reqProperty: path, like: "/summercampaign" }
         action:
           type: authenticate
           authenticator: my-basic-authenticator

Voir la section Utiliser les pipelines de configuration pour obtenir une description des propriétés situées au-dessus du nœud data. La valeur de la propriété kind doit être CDN et la propriété version doit être définie sur 1.

En outre, la syntaxe comprend :

Rotation des secrets rotating-secrets

Il est recommandé de modifier régulièrement les informations d’identification. N’oubliez pas que les variables d’environnement ne doivent pas être modifiées directement, mais créez plutôt un secret et référencez le nouveau nom dans la configuration.

Ce cas d’utilisation est illustré ci-dessous, en utilisant l’exemple d’une clé Edge, bien que la même stratégie puisse également être utilisée pour purger les clés.

Lors de la rotation de secrets définis dans les en-têtes de requête, par exemple pour l’authentification sur un serveur principal, il est recommandé d’effectuer la rotation en deux étapes afin de garantir que la valeur de l’en-tête est commutée sans interruptions temporaires.