Hitelesítés és engedélyezés a Azure-alkalmazás Service-ben és az Azure Functionsben

Feljegyzés

2024. június 1-től az összes újonnan létrehozott App Service-alkalmazás létrehozhat egy egyedi alapértelmezett gazdagépnevet az elnevezési konvencióval <app-name>-<random-hash>.<region>.azurewebsites.net. A meglévő alkalmazásnevek változatlanok maradnak.

Példa: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

További részletekért tekintse meg az App Service-erőforrás egyedi alapértelmezett gazdagépnevét.

Azure-alkalmazás szolgáltatás beépített hitelesítési és engedélyezési képességeket (más néven egyszerű hitelesítést) biztosít, így bejelentkezhet a felhasználókba, és hozzáférhet az adatokhoz úgy, hogy a webalkalmazásban, a RESTful API-ban és a mobil háttérrendszerben minimális vagy semmilyen kódot nem ír.Azure Functions. Ez a cikk azt ismerteti, hogyan segíti az App Service az alkalmazás hitelesítésének és engedélyezésének egyszerűsítését.

Miért érdemes a beépített hitelesítést használni?

Ezt a funkciót nem kell használnia hitelesítéshez és engedélyezéshez. Használhatja a csomagban lévő biztonsági funkciókat a választott webes keretrendszerben, vagy írhat saját segédprogramokat. Azonban gondoskodnia kell arról, hogy a megoldás naprakész maradjon a legújabb biztonsági, protokoll- és böngészőfrissítésekkel.

A hitelesítés (bejelentkező felhasználók) és az engedélyezés (biztonságos adatokhoz való hozzáférés biztosítása) biztonságos megoldásának megvalósítása jelentős erőfeszítést igényelhet. Mindenképpen követnie kell az iparági ajánlott eljárásokat és szabványokat, és naprakészen kell tartania a megvalósítást. Az App Service és az Azure Functions beépített hitelesítési funkciója időt és energiát takaríthat meg azáltal, hogy beépített hitelesítést biztosít az összevont identitásszolgáltatókkal, így az alkalmazás többi részére összpontosíthat.

• Azure-alkalmazás Szolgáltatással számos hitelesítési képességet integrálhat a webalkalmazásba vagy API-ba anélkül, hogy saját maga valósítja meg őket.
• Közvetlenül a platformba van beépítve, és nem igényel semmilyen nyelvet, SDK-t, biztonsági szakértelmet vagy akár bármilyen kódot.
• Több bejelentkezési szolgáltatóval is integrálható. Például: Microsoft Entra, Facebook, Google, X.

Előfordulhat, hogy az alkalmazásnak összetettebb forgatókönyveket kell támogatnia, például a Visual Studio integrációját vagy a növekményes hozzájárulást. Ezekhez a forgatókönyvekhez számos különböző hitelesítési megoldás érhető el. További információkért olvassa el az identitásforgatókönyveket.

Identitásszolgáltatók

Az App Service összevont identitást használ, amelyben egy külső identitásszolgáltató kezeli a felhasználói identitásokat és a hitelesítési folyamatot. Alapértelmezés szerint a következő identitásszolgáltatók érhetők el:

Szolgáltató	Bejelentkezési végpont	Útmutató útmutató
Microsoft Entra	/.auth/login/aad	App Service Microsoft Entra platform bejelentkezés
Facebook	/.auth/login/facebook	App Service Facebook-bejelentkezés
Google	/.auth/login/google	App Service Google-bejelentkezés
X	/.auth/login/x	App Service X-bejelentkezés
GitHub	/.auth/login/github	App Service GitHub-bejelentkezés
Bejelentkezés az Apple-lel	/.auth/login/apple	App Service Bejelentkezés Apple-bejelentkezéssel (előzetes verzió)
Bármely OpenID Connect-szolgáltató	/.auth/login/<providerName>	App Service OpenID Connect-bejelentkezés

Ha ezen szolgáltatók egyikével konfigurálja ezt a funkciót, a bejelentkezési végpontja elérhető a felhasználói hitelesítéshez és a szolgáltatótól származó hitelesítési jogkivonatok érvényesítéséhez. A felhasználók számára tetszőleges számú bejelentkezési lehetőséget biztosíthat.

A beépített hitelesítés használatának szempontjai

A funkció engedélyezésével az alkalmazáshoz érkező összes kérés automatikusan https-ra lesz átirányítva, függetlenül attól, hogy az App Service konfigurációs beállítása kényszeríti-e a HTTPS-t. Ezt a V2-konfiguráció beállításával requireHttps letilthatja. Javasoljuk azonban a HTTPS használatát, és győződjön meg arról, hogy a biztonsági jogkivonatok soha nem lesznek továbbítva nem biztonságos HTTP-kapcsolatokon keresztül.

Az App Service használható a webhelytartalomhoz és API-khoz való hozzáférés korlátozásával vagy anélkül történő hitelesítéshez. A hozzáférési korlátozások a webalkalmazás Hitelesítési>beállítások szakaszában állíthatók be. Ha csak hitelesített felhasználókra szeretné korlátozni az alkalmazáshozzáférést, állítsa be a műveletet, ha a kérés nincs hitelesítve , és jelentkezzen be az egyik konfigurált identitásszolgáltatónál. Ha hitelesíteni szeretné a hitelesítést, de nem korlátozza a hozzáférést, állítsa a művelet végrehajtására, ha a kérés nincs hitelesítve a "Névtelen kérések engedélyezése (nincs művelet").

Fontos

Minden alkalmazásregisztrációnak saját engedélyt és hozzájárulást kell adnia. Kerülje a környezetek közötti engedélymegosztást, használjon külön alkalmazásregisztrációkat a külön üzembehelyezési pontokhoz. Az új kód tesztelése során ez a gyakorlat segíthet megelőzni az éles alkalmazást érintő problémákat.

Hogyan működik?

Funkcióarchitektúra

Hitelesítési folyamat

Engedélyezési viselkedés

Jogkivonat-tároló

Naplózás és nyomkövetés

Funkcióarchitektúra

A hitelesítési és engedélyezési köztes szoftver összetevő a platform azon funkciója, amely ugyanazon a virtuális gépen fut, mint az alkalmazás. Ha engedélyezve van, minden bejövő HTTP-kérés áthalad rajta, mielőtt az alkalmazás kezelené.

A platform köztes szoftvere számos dolgot kezel az alkalmazáshoz:

• Hitelesíti a felhasználókat és az ügyfeleket a megadott identitásszolgáltató(ka)val
• Ellenőrzi, tárolja és frissíti a konfigurált identitásszolgáltató(k) által kibocsátott OAuth-jogkivonatokat
• A hitelesített munkamenet kezelése
• Identitásadatok beszúrása HTTP-kérelemfejlécekbe

A modul az alkalmazáskódtól külön fut, és az Azure Resource Manager beállításaival vagy konfigurációs fájllal konfigurálható. Nincs szükség SDK-kra, adott programozási nyelvekre vagy az alkalmazáskód módosítására.

Szolgáltatásarchitektúra Windows rendszeren (nem tárolóalapú üzembe helyezés)

A hitelesítési és engedélyezési modul natív IIS-modulként fut ugyanabban a tesztkörnyezetben, mint az alkalmazás. Ha engedélyezve van, minden bejövő HTTP-kérés áthalad rajta, mielőtt az alkalmazás kezelené.

Funkcióarchitektúra Linuxon és tárolókon

A hitelesítési és engedélyezési modul egy külön tárolóban fut, az alkalmazáskódtól elkülönítve. Az Úgynevezett Ambassador-mintát használva a bejövő forgalommal együttműködve hasonló funkciókat hajt végre, mint a Windowsban. Mivel nem fut a folyamaton belül, nem lehetséges a konkrét nyelvi keretrendszerekkel való közvetlen integráció; az alkalmazásnak szükséges releváns információkat azonban az alábbiakban ismertetett kérésfejlécek segítségével továbbítjuk.

Hitelesítési folyamat

A hitelesítési folyamat minden szolgáltató esetében azonos, de attól függően eltérő, hogy a szolgáltató SDK-jával szeretne-e bejelentkezni:

• Szolgáltatói SDK nélkül: Az alkalmazás delegáltjai összevonták a bejelentkezést az App Service-be. Ez általában a böngészőalkalmazások esetében fordul elő, amelyek bemutatják a szolgáltató bejelentkezési oldalát a felhasználónak. A kiszolgálókód kezeli a bejelentkezési folyamatot, ezért kiszolgáló által irányított folyamatnak vagy kiszolgálói folyamatnak is nevezik. Ez az eset azokra a böngészőalkalmazásokra és mobilalkalmazásokra vonatkozik, amelyek beágyazott böngészőt használnak a hitelesítéshez.
• Szolgáltató SDK-val: Az alkalmazás manuálisan bejelentkezteti a felhasználókat a szolgáltatóba, majd elküldi a hitelesítési jogkivonatot az App Service-nek ellenőrzés céljából. Ez általában a böngésző nélküli alkalmazások esetében fordul elő, amelyek nem tudják megjeleníteni a szolgáltató bejelentkezési oldalát a felhasználónak. Az alkalmazáskód kezeli a bejelentkezési folyamatot, ezért ügyfél által irányított folyamatnak vagy ügyfélfolyamatnak is nevezik. Ez az eset a REST API-kra, az Azure Functionsre és a JavaScript böngészőügyfelekre, valamint azokra a böngészőalkalmazásokra vonatkozik, amelyek nagyobb rugalmasságot igényelnek a bejelentkezési folyamat során. Azokra a natív mobilalkalmazásokra is vonatkozik, amelyek bejelentkeztetik a felhasználókat a szolgáltató SDK-jával.

Az App Service megbízható böngészőalkalmazásából egy másik REST API-ra irányuló hívások az App Service-ben vagy az Azure Functionsben a kiszolgáló által irányított folyamattal hitelesíthetők . További információ: Bejelentkezések és kijelentkezések testreszabása.

Az alábbi táblázat a hitelesítési folyamat lépéseit mutatja be.

Lépés	Szolgáltatói SDK nélkül	Szolgáltatói SDK-val
1. Felhasználó bejelentkezése	Átirányítja az ügyfelet a /.auth/login/<provider>.	Az ügyfélkód közvetlenül a szolgáltató SDK-jával jelentkezteti be a felhasználót, és hitelesítési jogkivonatot kap. További információt a szolgáltató dokumentációjában talál.
2. Hitelesítés utáni	A szolgáltató átirányítja az ügyfelet a /.auth/login/<provider>/callback.	Az ügyfélkód jogkivonatot küld a szolgáltatótól az /.auth/login/<provider> ellenőrzéshez.
3. Hitelesített munkamenet létrehozása	Az App Service hitelesített cookie-t ad hozzá a válaszhoz.	Az App Service a saját hitelesítési jogkivonatát adja vissza az ügyfélkódnak.
4. Hitelesített tartalom kiszolgálása	Az ügyfél a hitelesítési cookie-t a későbbi kérésekben is tartalmazza (a böngésző automatikusan kezeli).	Az ügyfélkód bemutatja a hitelesítési jogkivonatot a fejlécben X-ZUMO-AUTH .

Az ügyfélböngészők esetében az App Service automatikusan átirányítja az összes hitelesítés nélküli felhasználót a következőre /.auth/login/<provider>: . A felhasználókat egy vagy több /.auth/login/<provider> hivatkozással is megjelenítheti az alkalmazásba való bejelentkezéshez a választott szolgáltatójukkal.

Engedélyezési viselkedés

Fontos

Alapértelmezés szerint ez a funkció csak hitelesítést biztosít, nem engedélyezést. Előfordulhat, hogy az alkalmazásnak továbbra is engedélyezési döntéseket kell hoznia az itt konfigurált ellenőrzések mellett.

Az Azure Portalon számos viselkedéssel konfigurálhatja az App Service-t, ha a bejövő kérés nincs hitelesítve. Az alábbi címsorok a beállításokat írják le.

Hozzáférés korlátozása

• Hitelesítés nélküli kérések engedélyezése: Ez a beállítás letiltja az alkalmazáskódba irányuló nem hitelesített forgalom engedélyezését. Hitelesített kérések esetén az App Service a HTTP-fejlécekben található hitelesítési információkat is átadja.

  Ez a beállítás nagyobb rugalmasságot biztosít a névtelen kérések kezeléséhez. Lehetővé teszi például, hogy több bejelentkezési szolgáltatót is megjelenítsen a felhasználók számára. Azonban kódot kell írnia.

• Hitelesítés megkövetelése: Ez a beállítás elutasítja az alkalmazásba irányuló nem hitelesített forgalmat. A konkrét végrehajtandó művelet a Hitelesítés nélküli kérelmek szakaszban van megadva.

  Ezzel a beállítással nem kell hitelesítési kódot írnia az alkalmazásban. A finomabb engedélyezés, például a szerepkörspecifikus engedélyezés a felhasználó jogcímeinek vizsgálatával kezelhető (lásd : Access felhasználói jogcímek).

  Figyelemfelhívás

  A hozzáférés ilyen módon való korlátozása az alkalmazás összes hívására vonatkozik, ami nem feltétlenül kívánatos olyan alkalmazások esetében, amelyek nyilvánosan elérhető kezdőlapot szeretnének, mint sok egyoldalas alkalmazásban.

  Feljegyzés

  Ha a Microsoft identitásszolgáltatóját használja a szervezet felhasználói számára, az alapértelmezett viselkedés az, hogy a Microsoft Entra-bérlő bármely felhasználója tokent kérhet az alkalmazáshoz. Az alkalmazást konfigurálhatja a Microsoft Entra-ban , ha korlátozni szeretné az alkalmazáshoz való hozzáférést egy meghatározott felhasználói csoportra. Az App Service néhány alapvető beépített engedélyezési ellenőrzést is kínál, amelyek segíthetnek bizonyos ellenőrzésekkel. A Microsoft Entra engedélyezésével kapcsolatos további információkért tekintse meg a Microsoft Entra engedélyezési alapjait.

Nem hitelesített kérések

• HTTP 302 Talált átirányítás: ajánlott a webhelyek átirányítási műveletéhez az egyik konfigurált identitásszolgáltatóhoz. Ezekben az esetekben a rendszer átirányít egy böngészőügyfélt /.auth/login/<provider> a választott szolgáltatóhoz.
• HTTP 401 Jogosulatlan: API-khoz ajánlott Ha a névtelen kérés natív mobilalkalmazásból származik, a visszaadott válasz egy HTTP 401 Unauthorized. Az elutasítást úgy is konfigurálhatja, hogy minden kéréshez tartoznia kell HTTP 401 Unauthorized .
• A HTTP 403 Forbidden az elutasítást HTTP 403 Forbidden minden kéréshez konfigurálja.
• HTTP 404 Nem található , az elutasítást HTTP 404 Not found minden kéréshez konfigurálja.

Jogkivonat-tároló

Az App Service egy beépített jogkivonat-tárolót biztosít, amely a webalkalmazások, API-k vagy natív mobilalkalmazások felhasználóihoz társított jogkivonatok adattára. Ha engedélyezi a hitelesítést bármely szolgáltatónál, ez a jogkivonat-tároló azonnal elérhető az alkalmazás számára. Ha az alkalmazáskódnak hozzá kell férnie ezektől a szolgáltatóktól származó adatokhoz a felhasználó nevében, például:

• közzététel a hitelesített felhasználó Facebook-idővonalán
• a felhasználó vállalati adatainak beolvasása a Microsoft Graph API használatával

A jogkivonatok gyűjtéséhez, tárolásához és frissítéséhez általában kódot kell írnia az alkalmazásban. A jogkivonat-tárolóval egyszerűen lekérheti a jogkivonatokat , amikor szüksége van rájuk, és az App Service-nek kell frissítenie őket , amikor érvénytelenné válnak.

Az azonosító jogkivonatok, a hozzáférési jogkivonatok és a frissítési jogkivonatok gyorsítótárazva vannak a hitelesített munkamenethez, és csak a társított felhasználó érheti el őket.

Ha nem kell jogkivonatokkal dolgoznia az alkalmazásban, letilthatja a jogkivonat-tárolót az alkalmazás Hitelesítés/ Engedélyezés lapján.

Naplózás és nyomkövetés

Ha engedélyezi az alkalmazásnaplózást, a hitelesítési és engedélyezési nyomkövetések közvetlenül a naplófájlokban jelennek meg. Ha olyan hitelesítési hibát lát, amely nem várt, a meglévő alkalmazásnaplókban kényelmesen megtalálhatja az összes részletet. Ha engedélyezi a sikertelen kérések nyomon követését, láthatja, hogy a hitelesítési és engedélyezési modul milyen szerepet játszhatott egy sikertelen kérelemben. A nyomkövetési naplókban keressen hivatkozásokat egy nevű EasyAuthModule_32/64modulra.

Helyek közötti hamisítás mérséklése

Az App Service-hitelesítés a CSRF-et a következő feltételek ügyfélkéréseinek vizsgálatával csökkenti:

• Ez egy OLYAN POST-kérés, amely munkamenet-cookie-k használatával hitelesítve van.
• A kérés egy ismert böngészőből érkezett (a HTTP-fejléc User-Agent alapján).
• A HTTP Origin - vagy HTTP-fejléc Referer hiányzik, vagy nem szerepel az átirányításhoz jóváhagyott külső tartományok konfigurált listájában.
• A HTTP-fejléc Origin hiányzik, vagy nem szerepel a CORS-források konfigurált listájában.

Ha egy kérés teljesíti ezeket a feltételeket, az App Service-hitelesítés automatikusan elutasítja azt. Ezt a kockázatcsökkentési logikát úgy lehet megkerülni, hogy hozzáadja a külső tartományt az átirányítási listához a hitelesítési>beállítások>hitelesítésének szerkesztéséhez Engedélyezett külső átirányítási URL-címekhez.

Megfontolandó szempontok az Azure Front Door használatakor

Ha Azure-alkalmazás szolgáltatást az Azure Front Door mögötti hitelesítéssel vagy más fordított proxykkal használ, néhány további dolgot is figyelembe kell venni.

• Tiltsa le a gyorsítótárazást a hitelesítési munkafolyamathoz.

  A hitelesítési munkafolyamat gyorsítótárának letiltása című cikkből megtudhatja, hogyan konfigurálhat szabályokat az Azure Front Doorban a hitelesítéshez és az engedélyezéshez kapcsolódó lapok gyorsítótárazásának letiltásához.

• Az átirányításokhoz használja a Front Door végpontot.

  Az App Service általában nem érhető el közvetlenül, ha az Azure Front Dooron keresztül érhető el. Ez megelőzhető például az App Service privát kapcsolaton keresztüli felfedésével az Azure Front Door Premiumban. Ha meg szeretné akadályozni, hogy a hitelesítési munkafolyamat közvetlenül átirányítsa a forgalmat az App Service-be, fontos konfigurálnia az alkalmazást a visszairányításra https://<front-door-endpoint>/.auth/login/<provider>/callback.

• Győződjön meg arról, hogy az App Service a megfelelő átirányítási URI-t használja

  Bizonyos konfigurációkban az App Service az App Service teljes tartománynevét használja átirányítási URI-ként a Front Door teljes tartománynév helyett. Ez azt eredményezi, hogy az ügyfél a Front Door helyett az App Service-be lesz átirányítva. Ennek módosításához a beállítást úgy kell beállítaniStandard, hogy az forwardProxy App Service tiszteletben tartsa az X-Forwarded-Host Azure Front Door által beállított fejlécet.

  Más fordított proxyk, például Azure-alkalmazás átjáró vagy külső termékek eltérő fejléceket használhatnak, és más forwardProxy-beállításra van szükségük.

  Ezt a konfigurációt ma nem lehet elvégezni az Azure Portalon, és a következő módon az restkell elvégezni:

  Exportálási beállítások

  az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method get > auth.json

  Frissítési beállítások

  Keresés:

  "httpSettings": {
    "forwardProxy": {
      "convention": "Standard"
    }
  }
  

  és győződjön meg arról, hogy convention ez az Azure Front Door által használt fejléc tiszteletben tartására X-Forwarded-Host van beállítvaStandard.

  Importálási beállítások

  az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method put --body @auth.json

További erőforrások

• Útmutató: Az App Service vagy az Azure Functions alkalmazás konfigurálása a Microsoft Entra-bejelentkezés használatára
• Bejelentkezések és kijelentkezések testreszabása

• OAuth-jogkivonatok és munkamenetek
• Felhasználói és alkalmazásjogcímek elérése
• Fájlalapú konfiguráció

Minták:

• Oktatóanyag: Hitelesítés hozzáadása a Azure-alkalmazás Service-en futó webalkalmazáshoz
• Oktatóanyag: Végfelhasználók hitelesítése és engedélyezése a Azure-alkalmazás szolgáltatásban (Windows vagy Linux)
• A Azure-alkalmazás Service EasyAuth .NET Core-integrációja (külső fél)
• Azure-alkalmazás szolgáltatáshitelesítés használata a .NET Core-nal (külső féltől)