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

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, Twitter.

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 Identitásplatform /.auth/login/aad App Service Microsoft Identitásplatform bejelentkezés
Facebook /.auth/login/facebook App Service Facebook-bejelentkezés
Google /.auth/login/google App Service Google-bejelentkezés
Twitter /.auth/login/twitter App Service Twitter-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 Csatlakozás szolgáltató /.auth/login/<providerName> App Service OpenID Csatlakozás 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.

Működés

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é.

Egy architektúradiagram, amely azt mutatja be, hogy a kéréseket egy folyamat elfogja a hely tesztkörnyezetében, amely interakcióba lép az identitásszolgáltatókkal, mielőtt engedélyezi az üzembe helyezett hely felé irányuló forgalmat

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.

Restric-hozzáférés

  • 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.

Megfontolandó szempontok az Azure Front Door használatakor

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

  1. Gyorsítótárazás letiltása 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.

  2. A Front Door-végpont használata átirányításokhoz

    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.

  3. 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

Minták: