DokumentationAEM as a Cloud ServiceAnvändarhandbok

Konfigurera CDN-autentiseringsuppgifter och autentisering cdn-credentials-authentication

Last update: Mon Jun 02 2025 00:00:00 GMT+0000 (Coordinated Universal Time)
  • Gäller:
  • Experience Manager as a Cloud Service

Skapat för:

  • Administratör

CDN som tillhandahålls av Adobe har flera funktioner och tjänster, varav vissa är beroende av autentiseringsuppgifter och autentisering för att säkerställa en lämplig nivå av företagssäkerhet. Genom att deklarera regler i en konfigurationsfil som distribuerats med hjälp av Cloud Manager config pipeline kan kunderna på ett självbetjäningssätt konfigurera följande:

  • HTTP-huvudvärdet för X-AEM-Edge-Key som används av Adobe CDN för att validera begäranden som kommer från ett kundhanterat CDN.
  • Den API-token som används för att rensa resurser i CDN-cachen.
  • En lista över kombinationer av användarnamn och lösenord som kan få åtkomst till begränsat innehåll genom att skicka ett grundläggande autentiseringsformulär.

Var och en av dessa, inklusive konfigurationssyntaxen, beskrivs i sitt eget avsnitt nedan.

Det finns ett avsnitt om hur du roterar nycklar, vilket är en bra säkerhetspraxis.

NOTE
Hemligheter som definieras som miljövariabler bör betraktas som oföränderliga. I stället för att ändra deras värde bör du skapa en ny hemlighet med ett nytt namn och en referens till hemligheten i konfigurationen. Om du inte gör det kommer hemligheterna att uppdateras på ett otillförlitligt sätt.
WARNING
Ta inte bort de miljövariabler som refereras i CDN-konfigurationen. Detta kan orsaka fel vid uppdatering av CDN-konfigurationen (till exempel uppdatering av regler eller anpassade domäner och certifikat).

Kundhanterat CDN HTTP-huvudvärde CDN-HTTP-value

Så som beskrivs på CDN-sidan i AEM as a Cloud Service kan kunderna välja att dirigera trafik genom sitt eget CDN, som kallas kundens CDN (kallas ibland även BYOCDN).

Som en del av konfigurationen måste Adobe CDN och kundens CDN komma överens om ett värde för HTTP-huvudet X-AEM-Edge-Key. Värdet anges för varje begäran hos Customer CDN, innan det dirigeras till Adobe CDN, som sedan validerar att värdet är som förväntat, så att det kan lita på andra HTTP-huvuden, inklusive de som hjälper till att dirigera begäran till rätt AEM-ursprung.

Värdet X-AEM-Edge-Key refereras av egenskaperna edgeKey1 och edgeKey2 i en fil med namnet cdn.yaml eller liknande, någonstans under en config -mapp på översta nivån. Läs Använda konfigurationsförlopp om du vill ha mer information om mappstrukturen och hur du distribuerar konfigurationen. Syntaxen beskrivs i exemplet nedan.

Mer felsökningsinformation och vanliga fel finns i Vanliga fel.

WARNING
Direktåtkomst utan korrekt X-AEM-Edge-Key nekas för alla begäranden som matchar villkoret (i exemplet nedan betyder det alla begäranden till publiceringsnivån). Om du behöver införa autentisering gradvis läser du avsnittet Migrera säkert för att minska risken för blockerad trafik.
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

Se Använda konfigurationsförlopp för en beskrivning av egenskaperna ovanför noden data. Egenskapsvärdet kind ska vara CDN och egenskapen version ska vara 1.

Mer information finns i Konfigurera och distribuera CDN-regel för HTTP-huvudvalidering.

Ytterligare egenskaper är:

  • Data-nod som innehåller en underordnad authentication-nod.

  • Under authentication, en authenticators-nod och en rules-nod, som båda är arrayer.

  • Autentiserare: Gör att du kan deklarera en typ av token eller autentiseringsuppgifter, som i det här fallet är en edge-nyckel. Den innehåller följande egenskaper:

    • name - en beskrivande sträng.
    • type - måste vara edge.
    • edgeKey1 - värdet för X-AEM-Edge-Key som måste referera till en Cloud Manager-miljövariabel av hemlig typ. Välj Alla för fältet Tjänst används. Vi rekommenderar att värdet (till exempel ${{CDN_EDGEKEY_052824}}) återspeglar den dag det lades till.
    • edgeKey2 - används för att rotera hemligheter, vilket beskrivs i avsnittet roterande hemligheter nedan. Definiera den på liknande sätt som edgeKey1. Minst en av edgeKey1 och edgeKey2 måste deklareras.

  • Regler: Gör att du kan deklarera vilka autentiserare som ska användas och om det är för publicerings- och/eller förhandsgranskningsnivån. Den innehåller följande uppgifter:

    • name - en beskrivande sträng.
    • when - ett villkor som bestämmer när regeln ska utvärderas, enligt syntaxen i artikeln Traffic Filter Rules . Vanligtvis innehåller det en jämförelse av den aktuella nivån (till exempel publicera) så att all livtrafik valideras som routning via kundens CDN.
    • action - måste ange "authenticate" med referens till den avsedda autentiseraren.
NOTE
Edge-nyckeln måste konfigureras som en hemlig Cloud Manager-miljövariabel innan konfigurationen som refererar till den distribueras. Vi rekommenderar att du använder en unik slumpmässig nyckel på minst 32 byte. Det kryptografiska biblioteket Open SSL kan till exempel generera en slumpmässig nyckel genom att köra kommandot openssl rand -hex 32.

Migrera säkert för att minska risken för blockerad trafik migrating-safely

Om webbplatsen redan är aktiv bör du vara försiktig när du migrerar till kundhanterad CDN eftersom en felkonfiguration kan blockera allmän trafik. Detta beror på att endast begäranden med det förväntade X-AEM-Edge-Key-huvudvärdet accepteras av Adobe CDN. Ett tillvägagångssätt rekommenderas när ytterligare ett villkor tillfälligt inkluderas i autentiseringsregeln, vilket gör att den blockerar begäran endast om en testrubrik ingår eller om en sökväg matchar:

    - 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

Följande curl-begärandemönster kan användas:

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"

När testningen är klar kan det ytterligare villkoret tas bort och konfigurationen distribueras på nytt.

Rensa API-token purge-API-token

Kunder kan rensa CDN-cachen genom att använda en deklarerad rensnings-API-token. Token har deklarerats i en fil med namnet cdn.yaml eller liknande, någonstans under en config-mapp på översta nivån. Läs Använda konfigurationsförlopp om du vill ha mer information om mappstrukturen och hur du distribuerar konfigurationen.

Syntaxen beskrivs nedan:

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

Se Använda konfigurationsförlopp för en beskrivning av egenskaperna ovanför noden data. Egenskapsvärdet kind ska vara CDN och egenskapen version ska vara 1.

Ytterligare egenskaper är:

  • data-nod som innehåller en underordnad authentication-nod.

  • Under authentication, en authenticators-nod och en rules-nod, som båda är arrayer.

  • Autentiserare: Gör att du kan deklarera en typ av token eller autentiseringsuppgifter, som i det här fallet är en rensningsnyckel. Den innehåller följande egenskaper:

    • name - en beskrivande sträng.
    • type - måste tömmas.
    • purgeKey1 - dess värde måste referera till en Cloud Manager-miljövariabel av hemlig typ. Välj Alla för fältet Tjänst används. Vi rekommenderar att värdet (till exempel ${{CDN_PURGEKEY_031224}}) återspeglar den dag det lades till.
    • purgeKey2 - används för att rotera hemligheter, vilket beskrivs i avsnittet roterande hemligheter nedan. Minst en av purgeKey1 och purgeKey2 måste deklareras.

  • Regler: Gör att du kan deklarera vilka autentiserare som ska användas och om det är för publicerings- och/eller förhandsgranskningsnivån. Den innehåller följande uppgifter:

    • name - en beskrivande sträng
    • when - ett villkor som bestämmer när regeln ska utvärderas, enligt syntaxen i artikeln Traffic Filter Rules . Vanligtvis innehåller det en jämförelse av den aktuella nivån (till exempel publicera).
    • action - måste ange "authenticate" med referens till den avsedda autentiseraren.
NOTE
Töm nyckel måste konfigureras som en hemlig typ av Cloud Manager-miljövariabel innan konfigurationen som refererar till den distribueras. Vi rekommenderar att du använder en unik slumpmässig nyckel med en längd på minst 32 byte. Open SSL-kryptografibiblioteket kan till exempel generera en slumpmässig nyckel genom att köra kommandot openssl rand -hex 32

Du kan referera till en självstudie som fokuserar på att konfigurera rensningsnycklar och utföra rensning av CDN-cache.

Grundläggande autentisering basic-auth

Skydda vissa innehållsresurser genom att öppna en enkel dialogruta för autentisering som kräver ett användarnamn och lösenord. Den här funktionen är främst avsedd för enkla autentiseringssituationer, som granskning av innehåll av intressenter i företag, i stället för som en fullständig lösning för slutanvändares åtkomsträttigheter.

Slutanvändaren får en grundläggande autentiseringsdialogruta som ser ut så här:

basicauth-dialog

Syntaxen är följande:

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

Se Använda konfigurationsförlopp för en beskrivning av egenskaperna ovanför noden data. Egenskapsvärdet kind ska vara CDN och egenskapen version ska vara 1.

Dessutom innehåller syntaxen:

  • en data-nod som innehåller en authentication-nod.

  • Under authentication, en authenticators-nod och en rules-nod, som båda är arrayer.

  • Autentiserare: i det här scenariot deklarerar du en grundläggande autentiserare med följande struktur:

    • name - en beskrivande sträng

    • type - måste vara basic

    • en array med upp till 10 autentiseringsuppgifter, som vart och ett innehåller följande namn/värde-par, som slutanvändarna kan ange i den grundläggande autentiseringsdialogrutan:

  • Regler: Här kan du deklarera vilka autentiserare som ska användas och vilka resurser som ska skyddas. Varje regel innehåller:

    • name - en beskrivande sträng
    • when - ett villkor som bestämmer när regeln ska utvärderas, enligt syntaxen i artikeln Traffic Filter Rules . Vanligtvis innehåller det en jämförelse av publiceringsnivån eller specifika sökvägar.
    • action - måste ange "authenticate", med den avsedda autentiseraren refererad, som är basautentisering för detta scenario
NOTE
Lösenorden måste konfigureras som hemlig typ av Cloud Manager-miljövariabler, innan konfigurationen som refererar till den distribueras.

Rotera hemligheter rotating-secrets

Det är en god säkerhetspraxis att ändra inloggningsuppgifter regelbundet. Kom ihåg att miljövariabler inte ska ändras direkt, utan i stället skapa en ny hemlighet och referera till det nya namnet i konfigurationen.

Det här användningsexemplet visas nedan med hjälp av en kantnyckel, men samma strategi kan även användas för tömningsnycklar.

  1. Till att börja med har bara edgeKey1 definierats, i det här fallet refererat till ${{CDN_EDGEKEY_052824}}, vilket som en rekommenderad konvention, visar datumet då det skapades.

    code language-none 
    authentication:
  authenticators:
    - name: edge-auth
      type: edge
      edgeKey1: ${{CDN_EDGEKEY_052824}}

  2. När det är dags att rotera nyckeln skapar du en ny Cloud Manager-hemlighet, till exempel ${{CDN_EDGEKEY_041425}}.

  3. I konfigurationen refererar du till den från edgeKey2 och distribuerar den.

    code language-none 
    authentication:
  authenticators:
    - name: edge-auth
      type: edge
      edgeKey1: ${{CDN_EDGEKEY_052824}}
      edgeKey2: ${{CDN_EDGEKEY_041425}}

  4. När du är säker på att den gamla kantnyckeln inte längre används tar du bort den genom att ta bort edgeKey1 från konfigurationen.

    code language-none 
    authentication:
  authenticators:
    - name: edge-auth
      type: edge
      edgeKey2: ${{CDN_EDGEKEY_041425}}

  5. Ta bort den gamla hemliga referensen (${{CDN_EDGEKEY_052824}}) från Cloud Manager och distribuera.

  6. När du är redo för nästa rotation följer du samma procedur, men den här gången lägger du till edgeKey1 i konfigurationen och refererar till en ny Cloud Manager-miljöhemlighet med namnet, till exempel, ${{CDN_EDGEKEY_031426}}.

    code language-none 
    authentication:
  authenticators:
    - name: edge-auth
      type: edge
      edgeKey2: ${{CDN_EDGEKEY_041425}}
      edgeKey1: ${{CDN_EDGEKEY_031426}}

När hemligheter som anges i begärandehuvuden roteras, t.ex. för autentisering mot en serverdel, bör du rotera i två steg för att säkerställa att rubrikvärdet byts utan tillfälliga luckor.

  1. Inledande konfiguration före rotationen. I det här läget skickas den gamla nyckeln till backend-objektet.

    code language-none 
    requestTransformations:
  rules:
    - name: set-api-key-header
      actions:
        - type: set
          reqHeader: x-api-key
          value ${{API_KEY_1}}

  2. Introducera den nya nyckeln API_KEY_2 genom att ange samma rubrik två gånger (den nya nyckeln ska anges efter den gamla nyckeln). När du har distribuerat detta visas den nya nyckeln i serverdelen.

    code language-none 
    requestTransformations:
  rules:
    - name: set-api-key-header
      actions:
        - type: set
          reqHeader: x-api-key
          value ${{API_KEY_1}}
        - type: set
          reqHeader: x-api-key
          value ${{API_KEY_2}}

  3. Ta bort den gamla nyckeln API_KEY_1 från konfigurationen. När du har distribuerat detta ser du den nya nyckeln i serverdelen och det är säkert att ta bort den gamla nyckelns miljövariabel.

    code language-none 
    requestTransformations:
  rules:
    - name: set-api-key-header
      actions:
        - type: set
          reqHeader: x-api-key
          value ${{API_KEY_2}}
recommendation-more-help
fbcff2a9-b6fe-4574-b04a-21e75df764ab