Konfigurera din App Service- eller Azure Functions-app så att den använder Azure AD inloggning

  • Artikel

Välj en annan autentiseringsprovider för att hoppa till den.

Den här artikeln visar hur du konfigurerar autentisering för Azure App Service eller Azure Functions så att appen loggar in användare med Microsofts identitetsplattform (Azure AD) som autentiseringsprovider.

Funktionen App Service-autentisering kan automatiskt skapa en appregistrering med Microsofts identitetsplattform. Du kan också använda en registrering som du eller en katalogadministratör skapar separat.

Anteckning

Alternativet att skapa en ny registrering automatiskt är inte tillgängligt för myndighetsmoln eller när du använder Azure Active Directory för kunder (förhandsversion). Definiera i stället en registrering separat.

Alternativ 1: Skapa en ny appregistrering automatiskt

Använd det här alternativet om du inte behöver skapa en appregistrering separat. Det gör det enkelt att aktivera autentisering och kräver bara några klick. Du kan anpassa appregistreringen i Azure AD när den har skapats.

  1. Logga in på Azure Portal och gå till din app.

  2. Välj Autentisering i menyn till vänster. Klicka på Lägg till identitetsprovider.

  3. Välj Microsoft i listrutan identitetsprovider. Alternativet för att skapa en ny registrering är valt som standard. Du kan ändra namnet på registreringen eller de kontotyper som stöds.

    En klienthemlighet skapas och lagras som en slot-sticky-programinställning med namnet MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Du kan uppdatera den inställningen senare för att använda Key Vault referenser om du vill hantera hemligheten i Azure Key Vault.

  4. Om det här är den första identitetsprovidern som konfigurerats för programmet uppmanas du också att ange ett App Service avsnittet autentiseringsinställningar. Annars kan du gå vidare till nästa steg.

    De här alternativen avgör hur ditt program svarar på oautentiserade begäranden, och standardvalen omdirigerar alla begäranden för att logga in med den nya providern. Du kan ändra anpassa det här beteendet nu eller justera inställningarna senare från huvudskärmen för autentisering genom att välja Redigera bredvid Autentiseringsinställningar. Mer information om de här alternativen finns i Autentiseringsflöde.

  5. (Valfritt) Klicka på Nästa: Behörigheter och lägg till de Microsoft Graph-behörigheter som krävs av programmet. Dessa läggs till i appregistreringen, men du kan också ändra dem senare.

  6. Klicka på Lägg till.

Nu är du redo att använda Microsofts identitetsplattform för autentisering i din app. Providern visas på skärmen Autentisering . Därifrån kan du redigera eller ta bort den här providerkonfigurationen.

Ett exempel på hur du konfigurerar Azure AD inloggning för en webbapp som har åtkomst till Azure Storage och Microsoft Graph finns i den här självstudien.

Alternativ 2: Använd en befintlig registrering som skapats separat

Du kan konfigurera App Service autentisering för att använda en befintlig appregistrering. Följande situationer är de vanligaste fallen för att använda en befintlig appregistrering:

  • Ditt konto har inte behörighet att skapa appregistreringar i din Azure AD klientorganisation.
  • Du vill använda en appregistrering från en annan Azure AD klientorganisation än den som appen finns i.
  • Alternativet för att skapa en ny registrering är inte tillgängligt för myndighetsmoln.

Steg 1: Skapa en appregistrering i Azure AD för din App Service-app

När du skapar appregistreringen samlar du in följande information som du behöver senare när du konfigurerar autentiseringen i App Service appen:

  • Klient-ID
  • Klientorganisations-ID
  • Klienthemlighet (valfritt, men rekommenderas)
  • Program-ID-URI

Anvisningarna för att skapa en appregistrering beror på om du använder en personalklientorganisation eller en kundklient (förhandsversion). Använd flikarna nedan för att välja rätt uppsättning instruktioner för ditt scenario.

Utför följande steg för att registrera appen:

  1. Logga in på Azure Portal, sök efter och välj App Services och välj sedan din app. Anteckna appens URL. Du använder den för att konfigurera din Azure Active Directory-appregistrering.

  2. Gå till din klientorganisation i portalen:

    Välj Azure Active Directory på portalmenyn. Om klientorganisationen som du använder skiljer sig från den du använder för att konfigurera App Service-programmet måste du först ändra kataloger.

  3. På skärmen Översikt noterar du klientorganisations-ID:t och den primära domänen.

  4. I det vänstra navigeringsfältet väljer du Appregistreringar>Ny registrering.

  5. På sidan Registrera ett program anger du ett Namn för din appregistrering.

  6. I Kontotyper som stöds väljer du den kontotyp som kan komma åt det här programmet.

  7. I avsnittet Omdirigerings-URI:er väljer du Webb för plattform och skriver <app-url>/.auth/login/aad/callback. Till exempel https://contoso.azurewebsites.net/.auth/login/aad/callback.

  8. Välj Register (Registrera).

  9. När appregistreringen har skapats kopierar du program-ID:t (klient)-ID :t och katalog-ID:t (klientorganisation) för senare.

  10. Under Implicit beviljande och hybridflöden aktiverar du ID-token för att tillåta OpenID Connect-användarinloggningar från App Service. Välj Spara.

  11. (Valfritt) I det vänstra navigeringsfönstret väljer du Egenskaper för varumärkesanpassning&. I Webbadressen till startsidan anger du URL:en för din App Service-app och väljer Spara.

  12. I det vänstra navigeringsfönstret väljer du Exponera enAPI-uppsättning>>Spara. Det här värdet identifierar programmet unikt när det används som en resurs, vilket gör att token kan begäras som beviljar åtkomst. Det används som ett prefix för omfång som du skapar.

    För en app med en enda klientorganisation kan du använda standardvärdet, som är i formuläret api://<application-client-id>. Du kan också ange en mer läsbar URI baserat https://contoso.com/api på en av de verifierade domänerna för din klientorganisation. För en app för flera klientorganisationer måste du ange en anpassad URI. Mer information om accepterade format för app-ID-URI:er finns i referensen för metodtips för appregistreringar.

  13. Välj Lägg till omfång.

    1. I Omfångsnamn anger du user_impersonation.
    2. I Vem kan samtycka väljer du Administratörer och användare om du vill tillåta användare att godkänna det här omfånget.
    3. I textrutorna anger du namnet på medgivandeomfånget och beskrivningen som du vill att användarna ska se på sidan medgivande. Ange till exempel Access-programnamn<>.
    4. Välj Lägg till omfång.

  14. (Valfritt) Så här skapar du en klienthemlighet:

    1. I det vänstra navigeringsfönstret väljer duCertifikathemligheter Klienthemligheter>&Ny klienthemlighet.>
    2. Ange en beskrivning och förfallodatum och välj Lägg till.
    3. I fältet Värde kopierar du klienthemlighetsvärdet. Den visas inte igen när du har navigerat bort från den här sidan.

  15. (Valfritt) Om du vill lägga till flera svars-URL:er väljer du Autentisering.

  16. Slutför konfigurationen av appregistreringen:

    Inga ytterligare steg krävs för en personalklientorganisation.

Steg 2: Aktivera Azure Active Directory i din App Service-app

  1. Logga in på Azure Portal och gå till din app.

  2. I det vänstra navigeringsfältet väljer du Autentisering>Lägg till identitetsprovider>Microsoft.

  3. Välj Klientorganisationstyp för appregistreringen som du skapade.

  4. Konfigurera appen så att den använder den registrering som du skapade med hjälp av anvisningarna för lämplig klienttyp:

    För Appregistreringstyp väljer du något av följande:

    • Välj en befintlig appregistrering i den här katalogen: Välj en appregistrering från den aktuella klientorganisationen och samla automatiskt in nödvändig appinformation. Systemet försöker skapa en ny klienthemlighet mot appregistreringen och konfigurerar automatiskt appen så att den använder den. En standardutfärdar-URL anges baserat på de kontotyper som stöds och som konfigurerats i appregistreringen. Om du tänker ändra det här standardvärdet läser du tabellen nedan.
    • Ange information om en befintlig appregistrering: Ange information för en appregistrering från en annan klientorganisation eller om ditt konto inte har behörighet i den aktuella klientorganisationen att köra frågor mot registreringarna. För det här alternativet måste du manuellt fylla i konfigurationsvärdena enligt tabellen nedan.

    Autentiseringsslutpunkten för en arbetsstyrkas klientorganisation bör vara ett värde som är specifikt för molnmiljön. En personalklientorganisation i globala Azure skulle till exempel använda "https://login.microsoftonline.com" som dess autentiseringsslutpunkt. Anteckna värdet för autentiseringsslutpunkten eftersom det behövs för att skapa rätt utfärdar-URL.

    När du fyller i konfigurationsinformationen direkt använder du de värden som du samlade in när du skapade appregistreringen:

    Fält Beskrivning
    Program-ID (klient) Använd program-ID:t (klient) för appregistreringen.
    Client Secret (Klienthemlighet) Använd klienthemligheten som du genererade i appregistreringen. Med en klienthemlighet används hybridflödet och App Service returnerar åtkomst- och uppdateringstoken. När klienthemligheten inte har angetts används implicit flöde och endast en ID-token returneras. Dessa token skickas av providern och lagras i App Service autentiseringstokenarkiv.
    Utfärdar-URL Använd <authentication-endpoint>/<tenant-id>/v2.0och ersätt <authentication-endpoint> med den autentiseringsslutpunkt som du fastställde i föregående steg för din klienttyp och molnmiljö, och ersätt <även klient-ID> med katalog-ID:t (klientorganisation) där appregistreringen skapades. För program som använder Azure AD v1 utelämnar /v2.0 du i URL:en.

    Det här värdet används för att omdirigera användare till rätt Azure AD klientorganisation, samt för att ladda ned lämpliga metadata för att till exempel fastställa lämpliga tokensigneringsnycklar och anspråksvärde för token utfärdare. Alla andra konfigurationer än en klientspecifik slutpunkt behandlas som flera klientorganisationer. I konfigurationer för flera klientorganisationer utförs ingen validering av utfärdaren eller klientorganisations-ID:t av systemet, och dessa kontroller bör hanteras fullständigt i appens auktoriseringslogik.
    Tillåtna tokenmålgrupper Det här fältet är valfritt. Det konfigurerade program-ID:t (klient) anses alltid implicit vara en tillåten målgrupp. Om ditt program representerar ett API som anropas av andra klienter bör du även lägga till den program-ID-URI som du konfigurerade vid appregistreringen. Det finns en gräns på totalt 500 tecken i listan över tillåtna målgrupper.

    Klienthemligheten lagras som en slot-sticky-programinställning med namnet MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Du kan uppdatera den inställningen senare för att använda Key Vault referenser om du vill hantera hemligheten i Azure Key Vault.

  5. Om det här är den första identitetsprovidern som konfigurerats för programmet uppmanas du också att ange ett avsnitt om App Service autentiseringsinställningar. Annars kan du gå vidare till nästa steg.

    De här alternativen avgör hur programmet svarar på oautentiserade begäranden, och standardvalen omdirigerar alla begäranden för att logga in med den nya providern. Du kan ändra anpassa det här beteendet nu eller justera inställningarna senare från huvudskärmen för autentisering genom att välja Redigera bredvid Autentiseringsinställningar. Mer information om de här alternativen finns i Autentiseringsflöde.

  6. Klicka på Lägg till.

Nu är du redo att använda Microsofts identitetsplattform för autentisering i din app. Providern visas på skärmen Autentisering . Därifrån kan du redigera eller ta bort den här providerkonfigurationen.

Auktorisera begäranden

Som standard hanterar App Service-autentisering endast autentisering och avgör om anroparen är den som de säger att de är. Auktorisering, som avgör om anroparen ska ha åtkomst till en resurs, är ytterligare ett steg bortom autentiseringen. Du kan lära dig mer om dessa begrepp från Microsofts identitetsplattform auktoriseringsgrunder.

Din app kan fatta auktoriseringsbeslut i kod. App Service autentisering tillhandahåller vissa inbyggda kontroller som kan hjälpa, men de kanske inte ensamt räcker för att täcka appens auktoriseringsbehov.

Tips

Program med flera klientorganisationer bör verifiera utfärdaren och klientorganisations-ID:t för begäran som en del av den här processen för att se till att värdena tillåts. När App Service-autentisering har konfigurerats för ett scenario med flera klientorganisationer valideras inte vilken klientorganisation begäran kommer från. En app kan till exempel behöva begränsas till specifika klientorganisationer, baserat på om organisationen har registrerat sig för tjänsten. Se Microsofts identitetsplattform vägledning för flera klientorganisationer.

Utföra valideringar från programkod

När du utför auktoriseringskontroller i appkoden kan du använda anspråksinformationen som App Service autentisering gör tillgänglig. Den inmatade x-ms-client-principal rubriken innehåller ett Base64-kodat JSON-objekt med anspråken som hävdas om anroparen. Som standard går dessa anspråk igenom en anspråksmappning, så anspråksnamnen kanske inte alltid matchar det som visas i token. Till exempel mappas anspråket tid till http://schemas.microsoft.com/identity/claims/tenantid i stället.

Du kan också arbeta direkt med den underliggande åtkomsttoken från den inmatade x-ms-token-aad-access-token rubriken.

Använda en inbyggd auktoriseringsprincip

Den skapade appregistreringen autentiserar inkommande begäranden för din Azure AD klientorganisation. Som standard kan alla i klientorganisationen få åtkomst till programmet, vilket är bra för många program. Vissa program måste dock begränsa åtkomsten ytterligare genom att fatta auktoriseringsbeslut. Programkoden är ofta den bästa platsen för att hantera anpassad auktoriseringslogik. Men för vanliga scenarier tillhandahåller Microsofts identitetsplattform inbyggda kontroller som du kan använda för att begränsa åtkomsten.

Det här avsnittet visar hur du aktiverar inbyggda kontroller med hjälp av V2-API:et för App Service-autentisering. För närvarande är det enda sättet att konfigurera dessa inbyggda kontroller via Azure Resource Manager-mallar eller REST-API:et.

I API-objektet har Azure Active Directory-identitetsproviderkonfigurationen ett validation avsnitt som kan innehålla ett defaultAuthorizationPolicy -objekt som i följande struktur:

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}
Egenskap Beskrivning
defaultAuthorizationPolicy En gruppering av krav som måste uppfyllas för att få åtkomst till appen. Åtkomst beviljas baserat på en logisk AND över var och en av dess konfigurerade egenskaper. När allowedApplications och allowedPrincipals är båda konfigurerade måste den inkommande begäran uppfylla båda kraven för att godkännas.
allowedApplications En lista över klient-ID :t för strängprogram som representerar klientresursen som anropar till appen. När den här egenskapen har konfigurerats som en icke-slutförd matris godkänns endast token som hämtas av ett program som anges i listan.

Den här principen utvärderar eller azp anspråket appid för den inkommande token, som måste vara en åtkomsttoken. Se anspråksreferensen för Microsoft Identity Platform.
allowedPrincipals En gruppering av kontroller som avgör om huvudkontot som representeras av den inkommande begäran kan komma åt appen. Nöjdhet allowedPrincipals baseras på en logisk OR över dess konfigurerade egenskaper.
identities (under allowedPrincipals) En lista över strängobjekt-ID: er som representerar användare eller program som har åtkomst. När den här egenskapen har konfigurerats som en matris utan fel allowedPrincipals kan kravet uppfyllas om användaren eller programmet som representeras av begäran anges i listan.

Den här principen utvärderar anspråket för oid den inkommande token. Se anspråksreferensen för Microsoft Identity Platform.

Dessutom kan vissa kontroller konfigureras via en programinställning, oavsett vilken API-version som används. Programinställningen WEBSITE_AUTH_AAD_ALLOWED_TENANTS kan konfigureras med en kommaavgränsad lista med upp till 10 klient-ID:n (t.ex. "559a2f9c-c6f2-4d31-b8d6-5ad1a13f8330,5693f64a-3ad5-4be7-b846-e9d1141bcebc") för att kräva att den inkommande token kommer från en av de angivna klientorganisationer som anges av anspråket tid . Programinställningen WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL kan konfigureras till "true" eller "1" för att kräva att den inkommande token inkluderar ett oid anspråk. Den här inställningen ignoreras och behandlas som true om allowedPrincipals.identities den har konfigurerats (eftersom anspråket kontrolleras mot den oid här tillhandahållna listan med identiteter).

Begäranden som misslyckas med dessa inbyggda kontroller får ett HTTP-svar 403 Forbidden .

Konfigurera klientappar för åtkomst till din App Service

I föregående avsnitt registrerade du din App Service eller Azure-funktion för att autentisera användare. Det här avsnittet beskriver hur du registrerar interna klienter eller daemonappar i Azure AD så att de kan begära åtkomst till API:er som exponeras av din App Service för användare eller sig själva, till exempel i en N-nivåarkitektur. Du behöver inte slutföra stegen i det här avsnittet om du bara vill autentisera användare.

Internt klientprogram

Du kan registrera interna klienter för att begära åtkomst till din App Service-appens API:er för en inloggad användare.

  1. Välj Azure Active Directory på portalmenyn.

  2. I det vänstra navigeringsfältet väljer du Appregistreringar>Ny registrering.

  3. På sidan Registrera ett program anger du ett Namn för din appregistrering.

  4. I Omdirigerings-URI väljer du Offentlig klient (mobilt & skrivbord) och skriver URL:en <app-url>/.auth/login/aad/callback. Till exempel https://contoso.azurewebsites.net/.auth/login/aad/callback.

  5. Välj Register (Registrera).

  6. När appregistreringen har skapats kopierar du värdet för program-ID (klient).

    Anteckning

    För ett Microsoft Store-program använder du paket-SID som URI i stället.

  7. I det vänstra navigeringsfönstret väljer du API-behörigheter>Lägg till en behörighet>Mina API:er.

  8. Välj den appregistrering som du skapade tidigare för din App Service-app. Om du inte ser appregistreringen kontrollerar du att du har lagt till user_impersonation-omfånget i Skapa en appregistrering i Azure AD för din App Service-app.

  9. Under Delegerade behörigheter väljer du user_impersonation och sedan Lägg till behörigheter.

Nu har du konfigurerat ett internt klientprogram som kan begära åtkomst till din App Service app för en användares räkning.

Daemon-klientprogram (tjänst-till-tjänst-anrop)

I en N-nivåarkitektur kan klientprogrammet hämta en token för att anropa en App Service- eller funktionsapp för själva klientappen (inte för en användares räkning). Det här scenariot är användbart för icke-interaktiva daemonprogram som utför uppgifter utan en inloggad användare. Den använder OAuth 2.0-standardklientens autentiseringsuppgifter .

  1. Välj Azure Active Directory på portalmenyn.
  2. I det vänstra navigeringsfältet väljer du Appregistreringar>Ny registrering.
  3. På sidan Registrera ett program anger du ett Namn för din appregistrering.
  4. För ett daemonprogram behöver du ingen omdirigerings-URI så du kan hålla den tom.
  5. Välj Register (Registrera).
  6. När appregistreringen har skapats kopierar du värdet för program-ID (klient).
  7. I det vänstra navigeringsfönstret väljer duCertifikathemligheter Klienthemligheter>&Ny klienthemlighet.>
  8. Ange en beskrivning och förfallodatum och välj Lägg till.
  9. I fältet Värde kopierar du klienthemlighetsvärdet. Den visas inte igen när du navigerar bort från den här sidan.

Du kan nu begära en åtkomsttoken med klient-ID och klienthemlighet genom att ange parametern resource till program-ID-URI för målappen. Den resulterande åtkomsttoken kan sedan visas för målappen med OAuth 2.0-standardauktoriseringshuvudet och App Service autentisering validerar och använder token som vanligt för att nu ange att anroparen (ett program i det här fallet inte en användare) har autentiserats.

För närvarande gör detta att alla klientprogram i din Azure AD klientorganisation kan begära en åtkomsttoken och autentisera till målappen. Om du också vill framtvinga auktorisering för att endast tillåta vissa klientprogram måste du utföra ytterligare konfiguration.

  1. Definiera en approll i manifestet för appregistreringen som representerar den App Service eller funktionsapp som du vill skydda.
  2. På appregistreringen som representerar klienten som behöver auktoriseras väljer du API-behörigheter>Lägg till en behörighet>Mina API:er.
  3. Välj den appregistrering som du skapade tidigare. Om du inte ser appregistreringen kontrollerar du att du har lagt till en approll.
  4. Under Programbehörigheter väljer du den approll som du skapade tidigare och väljer sedan Lägg till behörigheter.
  5. Se till att klicka på Bevilja administratörsmedgivande för att auktorisera klientprogrammet för att begära behörigheten.
  6. På samma sätt som i föregående scenario (innan några roller lades till) kan du nu begära en åtkomsttoken för samma mål resource, och åtkomsttoken innehåller ett roles anspråk som innehåller de approller som har auktoriserats för klientprogrammet.
  7. Inom mål-App Service eller funktionsappens kod kan du nu verifiera att de förväntade rollerna finns i token (detta utförs inte av App Service autentisering). Mer information finns i Åtkomstanspråk för användare.

Nu har du konfigurerat ett daemon-klientprogram som kan komma åt din App Service-app med hjälp av sin egen identitet.

Bästa praxis

Oavsett vilken konfiguration du använder för att konfigurera autentisering kommer följande metodtips att skydda klientorganisationen och programmen:

  • Konfigurera varje App Service app med en egen appregistrering i Azure AD.
  • Ge varje App Service app sina egna behörigheter och medgivande.
  • Undvik behörighetsdelning mellan miljöer genom att använda separata appregistreringar för separata distributionsplatser. När du testar ny kod kan den här metoden förhindra att problem påverkar produktionsappen.

Nästa steg