DokumentationAEM as a Cloud ServiceAnvändarhandbok

Konfigurera CDN-autentiseringsuppgifter och autentisering cdn-credentials-authentication

Last update: Mon Jul 15 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

Skapat för:

  • Administratör
NOTE
Den här funktionen är ännu inte allmänt tillgänglig. Om du vill gå med i det tidiga adopterprogrammet skickar du e-post aemcs-cdn-config-adopter@adobe.com.

CDN som tillhandahålls av Adobe har flera funktioner och tjänster, varav vissa förlitar sig på 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 Configuration Pipeline kan kunderna själva konfigurera följande:

  • Det HTTP-huvudvärde som används av CDN i Adobe för att validera begäranden 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. Avsnittet Vanliga inställningar illustrerar de inställningar som är gemensamma för både och distributionen. Slutligen finns det ett avsnitt om hur du roterar nycklar, vilket anses vara en bra säkerhetspraxis.

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, på kundens 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.

Värdet X-AEM-Edge-Key deklareras med syntaxen nedan, med de faktiska värdena som refereras av egenskaperna edgeKey1 och edgeKey2. Mer information om hur du distribuerar konfigurationen finns i avsnittet Vanliga inställningar.

kind: "CDN"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  experimental_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

Syntaxen för värdet X-AEM-Edge-Key innehåller:

  • Typ, version och metadata.

  • Datanod som innehåller en underordnad experimental_authentication-nod (det experimentella prefixet tas bort när funktionen släpps).

  • Under experimental_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 hemlig token, som inte ska lagras i Git, utan deklareras som en Cloud Manager-miljövariabel av typen hemlig. 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 Cloud Manager-miljövariabel av typen secret (med Alla valt för Tjänsten används) innan konfigurationen som refererar till den distribueras.

Rensa API-token purge-API-token

Kunder kan rensa CDN-cachen genom att använda en deklarerad rensnings-API-token. Token deklareras med syntaxen nedan. Mer information om hur du distribuerar Common Setup finns i avsnittet Common Setup.

kind: "CDN"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  experimental_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

Syntaxen innehåller:

  • typ, version och metadata.

  • datanod som innehåller en underordnad experimental_authentication-nod (det experimentella prefixet tas bort när funktionen släpps).

  • Under experimental_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 hemlig token, som inte ska lagras i Git, utan snarare deklareras som Cloud Manager-miljövariabler av typen secret.
    • 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
Edge-nyckeln måste konfigureras som en Cloud Manager-miljövariabelav typen secret innan konfigurationen som refererar till den distribueras.

Grundläggande autentisering basic-auth

Protect vissa innehållsresurser genom att öppna en enkel autentiseringsdialogruta som kräver 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 deklareras enligt beskrivningen nedan. Se avsnittet Vanliga inställningar nedan för information om hur du distribuerar det.

kind: "CDN"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  experimental_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

Syntaxen innehåller:

  • typ, version och metadata.

  • en datanod som innehåller en experimental_authentication-nod (det experimentella prefixet tas bort när funktionen släpps).

  • Under experimental_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 autentiseringsuppgifter, som vart och ett innehåller följande namn/värde-par, som slutanvändarna kan ange i den grundläggande autentiseringsdialogrutan:

      • användare - namnet på användaren
      • password - dess värde måste referera till en hemlig token, som inte ska lagras i Git, utan istället deklareras som Cloud Manager Environment Variables av typen secrets (med All markerat som tjänstfält)

  • 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
Edge-nyckeln måste konfigureras som en Cloud Manager-miljövariabelav typen secret innan konfigurationen som refererar till den distribueras.

Vanliga inställningar common-setup

Alla autentiserare konfigureras enligt följande:

  • Skapa först följande mapp- och filstruktur i den översta mappen i Git-projektet:
config/
     cdn.yaml

  • För det andra bör konfigurationsfilen cdn.yaml innehålla de noder som beskrivs i exemplen nedan. Egenskapen kind ska anges till CDN och versionen ska anges till schemaversionen, som för närvarande är 1. Metadatanoden har en envTypes-egenskap som anger på vilka miljötyper (dev, stage, prod) som den här konfigurationen ska utvärderas.

  • Skapa en riktad pipeline för driftsättningskonfiguration i Cloud Manager. Se konfigurera produktionspipelines och konfigurera icke-produktionspipelines.

Observera att:

  • De lokala lagringsplatserna stöder för närvarande inte konfigurationsflödet.
  • Du kan använda yq för att lokalt validera YAML-formateringen av konfigurationsfilen (till exempel yq cdn.yaml).

Rotera hemligheter rotating-secrets

Det är god säkerhetspraxis att emellanåt ändra autentiseringsuppgifter. Detta kan åstadkommas enligt exemplet nedan med hjälp av en kantnyckel, även om samma strategi används för tömningsnycklar.

  • 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.
experimental_authentication:
  authenticators:
    - name: edge-auth
      type: edge
      edgeKey1: ${{CDN_EDGEKEY_052824}}
  • När det är dags att rotera nyckeln skapar du en ny Cloud Manager-hemlighet, till exempel ${{CDN_EDGEKEY_041425}}.
  • I konfigurationen refererar du till den från edgeKey2 och distribuerar den.
experimental_authentication:
  authenticators:
    - name: edge-auth
      type: edge
      edgeKey1: ${{CDN_EDGEKEY_052824}}
      edgeKey2: ${{CDN_EDGEKEY_041425}}
  • 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.
experimental_authentication:
  authenticators:
    - name: edge-auth
      type: edge
      edgeKey2: ${{CDN_EDGEKEY_041425}}
  • Ta bort den gamla hemliga referensen (${{CDN_EDGEKEY_052824}}) från Cloud Manager och distribuera.
  • 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}}.
experimental_authentication:
  authenticators:
    - name: edge-auth
      type: edge
      edgeKey2: ${{CDN_EDGEKEY_041425}}
      edgeKey1: ${{CDN_EDGEKEY_031426}}
recommendation-more-help
fbcff2a9-b6fe-4574-b04a-21e75df764ab