Autentisering och auktorisering för Azure Static Web Apps

Artikel
10/14/2021
7 minuter för att läsa

Azure Static Web Apps ger en smidig autentiseringsupplevelse. Som standard har du åtkomst till en serie förkonfigurerade providers eller alternativet att registrera en anpassad provider.

Alla användare kan autentisera med en aktiverad provider.
När du har loggat in tillhör användarna anonymous authenticated rollerna och som standard.
Behöriga användare får åtkomst till begränsade vägar genom regler som definieras i staticwebapp.config.json-filen.
Användare tilldelas anpassade roller med hjälp av det inbyggda systemet för inbjudningar.
Användare kan tilldelas programmatiskt anpassade roller vid inloggning med en API-funktion.
Alla autentiseringsproviders är aktiverade som standard.
- Om du vill begränsa en autentiseringsprovider blockerar du åtkomst med en anpassad vägregel.
Förkonfigurerade providers omfattar:
- Azure Active Directory
- GitHub
- Twitter

Ämnena för autentisering och auktorisering överlappar avsevärt routningsbegreppen, som beskrivs i programkonfigurationsguiden.

Roller

Varje användare som har åtkomst till en statisk webbapp tillhör en eller flera roller. Det finns två inbyggda roller som användare kan tillhöra:

anonym: Alla användare tillhör automatiskt den anonyma rollen.
autentiserad: Alla användare som är inloggade tillhör den autentiserade rollen.

Utöver de inbyggda rollerna kan du tilldela anpassade roller till användare och referera till dem i filenstaticwebapp.config.json.

Lägga till en användare i en roll

Om du vill lägga till en användare till en roll skapar du inbjudningar som gör att du kan associera användare till specifika roller. Roller definieras och underhålls i filenstaticwebapp.config.json.

Skapa en inbjudan

Inbjudningar är specifika för enskilda auktoriseringsleverantörer, så överväg behoven i din app när du väljer vilka leverantörer som ska stödjas. Vissa leverantörer exponerar en användares e-postadress, medan andra bara anger webbplatsens användarnamn.

Auktoriseringsprovider	Exponerar en användares
Azure Active Directory	e-postadress
GitHub	användarnamn
Twitter	användarnamn

Gå till Static Web Apps resurs i Azure Portal.
Under Inställningar klickar du på Rollhantering.
Klicka på knappen Bjud in.
Välj en auktoriseringsprovider i listan med alternativ.
Lägg antingen till mottagarens användarnamn eller e-postadress i rutan Inbjudningsinformation.
- För GitHub och Twitter anger du användarnamnet. För alla andra anger du mottagarens e-postadress.
Välj domänen för den statiska platsen i listrutan Domän.
- Den domän som du väljer är den domän som visas i inbjudan. Om du har en anpassad domän som är associerad med webbplatsen vill du förmodligen välja den anpassade domänen.
Lägg till en kommaavgränsad lista med rollnamn i rutan Roll.
Ange det maximala antalet timmar som du vill att inbjudan ska förbli giltig.
- Den högsta möjliga gränsen är 168 timmar, vilket är 7 dagar.
Klicka på knappen Generate (Generera).
Kopiera länken från rutan Bjud in länk.
Skicka inbjudningslänken via e-post till den person som du beviljar åtkomst till din app.

När användaren klickar på länken i inbjudan uppmanas de att logga in med sitt motsvarande konto. När användaren har loggat in associeras den med de valda rollerna.

Varning

Kontrollera att dina vägregler inte står i konflikt med dina valda autentiseringsproviders. Om en leverantör blockeras med en vägregel kan användarna inte acceptera inbjudningar.

Uppdatera rolltilldelningar

Gå till Static Web Apps resurs i Azure Portal.
Under Inställningar klickar du på Rollhantering.
Klicka på användaren i listan.
Redigera listan över roller i rutan Roll.
Klicka på knappen Uppdatera.

Ta bort användare

Gå till Static Web Apps resurs i Azure Portal.
Under Inställningar klickar du på Rollhantering.
Leta upp användaren i listan.
Markera kryssrutan på användarens rad.
Klicka på knappen Ta bort.

Tänk på följande när du tar bort en användare:

Om du tar bort en användare ogiltigförklaras deras behörigheter.
Spridning över hela världen kan ta några minuter.
Om användaren läggs till i appen igen userId ändras.

I stället för att använda det inbyggda inbjudningssystemet kan du använda en serverlös funktion för att programmatiskt tilldela roller till användare när de loggar in.

Om du vill tilldela anpassade roller i en funktion kan du definiera en API-funktion som anropas automatiskt efter varje gång en användare autentiseras med en identitetsprovider. Funktionen skickas användarens information från providern. Den måste returnera en lista över anpassade roller som har tilldelats användaren.

Exempel på användning av den här funktionen är:

Fråga en databas för att avgöra vilka roller en användare ska tilldelas
Anropa Microsoft Graph API för att fastställa en användares roller baserat på deras Active Directory-gruppmedlemskap
Fastställa en användares roller baserat på anspråk som returneras av identitetsprovidern

Anteckning

Möjligheten att tilldela roller via en funktion är bara tillgänglig när anpassad autentisering har konfigurerats.

När den här funktionen är aktiverad ignoreras alla roller som tilldelas via det inbyggda inbjudningssystemet.

Konfigurera en funktion för att tilldela roller

Om du Static Web Apps att använda en API-funktion som rolltilldelningsfunktion lägger du till en egenskap i avsnittet i rolesSource auth appens konfigurationsfil. Värdet för egenskapen rolesSource är sökvägen till API-funktionen.

{
  "auth": {
    "rolesSource": "/api/GetRoles",
    "identityProviders": {
      // ...
    }
  }
}

Anteckning

När rolltilldelningsfunktionen har konfigurerats kan den inte längre nås av externa HTTP-begäranden.

Skapa en funktion för att tilldela roller

När du har rolesSource definierat egenskapen i appens konfiguration lägger du till en API-funktion i din statiska webbapp på den sökväg som du angav. Du kan använda en hanterad funktionsapp eller en Bring Your Own Function-app.

Varje gång en användare autentiseras med en identitetsprovider anropas den angivna funktionen. Funktionen skickas ett JSON-objekt i begärandetexten som innehåller användarens information från providern. För vissa identitetsproviders innehåller användarinformationen även en som funktionen kan använda för att accessToken göra API-anrop med hjälp av användarens identitet.

Det här är ett exempel på en nyttolast från Azure Active Directory:

{
  "identityProvider": "aad",
  "userId": "72137ad3-ae00-42b5-8d54-aacb38576d76",
  "userDetails": "ellen@contoso.com",
  "claims": [
      {
          "typ": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
          "val": "ellen@contoso.com"
      },
      {
          "typ": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname",
          "val": "Contoso"
      },
      {
          "typ": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
          "val": "Ellen"
      },
      {
          "typ": "name",
          "val": "Ellen Contoso"
      },
      {
          "typ": "http://schemas.microsoft.com/identity/claims/objectidentifier",
          "val": "7da753ff-1c8e-4b5e-affe-d89e5a57fe2f"
      },
      {
          "typ": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
          "val": "72137ad3-ae00-42b5-8d54-aacb38576d76"
      },
      {
          "typ": "http://schemas.microsoft.com/identity/claims/tenantid",
          "val": "3856f5f5-4bae-464a-9044-b72dc2dcde26"
      },
      {
          "typ": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
          "val": "ellen@contoso.com"
      },
      {
          "typ": "ver",
          "val": "1.0"
      }
  ],
  "accessToken": "eyJ0eXAiOiJKV..."
}

Funktionen kan använda användarens information för att avgöra vilka roller som ska tilldelas till användaren. Det måste returnera ett HTTP 200-svar med en JSON-brödtext som innehåller en lista över anpassade rollnamn som ska tilldelas användaren.

Om du till exempel vill tilldela användaren till Reader Contributor rollerna och returnerar du följande svar:

{
  "roles": [
    "Reader",
    "Contributor"
  ]
}

Om du inte vill tilldela ytterligare roller till användaren returnerar du en tom roles matris.

Mer information finns i Självstudie: Tilldela anpassade roller med en funktion och Microsoft Graph.

Ta bort personlig identifieringsinformation

När du beviljar medgivande till ett program som slutanvändare har programmet åtkomst till din e-postadress eller ditt användarnamn beroende på identitetsprovidern. När den här informationen har angetts avgör programmets ägare hur personligt identifierande information ska hanteras.

Slutanvändare måste kontakta administratörer för enskilda webbappar för att återkalla den här informationen från sina system.

Om du vill ta bort personligt identifierande information från Azure Static Web Apps plattformen och förhindra plattformen från att tillhandahålla den här informationen om framtida begäranden skickar du en begäran med hjälp av URL:en:

https://identity.azurestaticapps.net/.auth/purge/<AUTHENTICATION_PROVIDER_NAME>

För att förhindra att plattformen tillhandahåller den här informationen om framtida begäranden till enskilda appar skickar du en begäran till följande URL:

https://<WEB_APP_DOMAIN_NAME>/.auth/purge/<AUTHENTICATION_PROVIDER_NAME>

Observera att om du använder Azure Active Directory använder aad du som värde för <AUTHENTICATION_PROVIDER_NAME> platshållaren.

Systemmapp

Azure Static Web Apps använder /.auth systemmappen för att ge åtkomst till auktoriseringsrelaterade API:er. I stället för att exponera någon av vägarna under mappen direkt för slutanvändarna bör du överväga att /.auth skapa routningsregler för att skapa egna URL:er.

Använd följande tabell för att hitta den providerspecifika vägen.

Auktoriseringsprovider	Inloggningsväg
Azure Active Directory	`/.auth/login/aad`
GitHub	`/.auth/login/github`
Twitter	`/.auth/login/twitter`

Om du till exempel vill logga in GitHub kan du inkludera en länk som liknar följande kodfragment:

<a href="/.auth/login/github">Login</a>

Om du väljer att stödja fler än en leverantör måste du exponera en providerspecifik länk för varje på din webbplats.

Du kan använda en vägregel för att mappa en standardprovider till en användarvänlig väg som /login.

{
  "route": "/login",
  "redirect": "/.auth/login/github"
}

Om du vill att en användare ska återgå till en specifik sida efter inloggningen anger du en fullständig kvalificerad URL i post_login_redirect_uri frågesträngsparametern.

Ett exempel:

<a href="/.auth/login/github?post_login_redirect_uri=https://zealous-water.azurestaticapps.net/success">Login</a>

Utloggning

Vägen /.auth/logout loggar ut användare från webbplatsen. Du kan lägga till en länk till webbplatsnavigeringen så att användaren kan logga ut enligt följande exempel.

<a href="/.auth/logout">Log out</a>

Du kan använda en vägregel för att mappa en användarvänlig väg som /logout.

{
  "route": "/logout",
  "redirect": "/.auth/logout"
}

Omdirigering efter utloggning

Om du vill att en användare ska återgå till en specifik sida efter utloggningen anger du en URL i post_logout_redirect_uri frågesträngsparametern.

Blockera en auktoriseringsprovider

Du kanske vill begränsa appen från att använda en auktoriseringsprovider. Din app kanske till exempel bara vill standardisera på leverantörer som exponerar e-postadresser.

Om du vill blockera en leverantör kan du skapa vägregler för att returnera 404 för begäranden till den blockerade providerspecifika vägen. Om du till exempel vill begränsa Twitter som provider lägger du till följande vägregel.

{
  "route": "/.auth/login/twitter",
  "statusCode": 404
}

Begränsningar

I artikeln Kvoter finns allmänna begränsningar och begränsningar.

Nästa steg

Få åtkomst till användarautentisering och auktoriseringsdata

¹ Väntar på extern certifiering.