A hitelesítés és az engedélyezés felfedezése az App Service-ben

Befejeződött

Azure-alkalmazás szolgáltatás beépített hitelesítést és engedélyezést biztosít, így a felhasználók bejelentkezhetnek, és hozzáférhetnek az adatokhoz úgy, hogy a webalkalmazásban, a RESTful API-ban, a mobil háttérrendszerben és az Azure Functionsben minimális vagy kód nélküli kódot írnak.

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

Nem kell az App Service-t használnia a hitelesítéshez és az engedélyezéshez. Számos webes keretrendszer rendelkezik biztonsági funkciókkal, és tetszés szerint használhatja őket. Ha az App Service-nél nagyobb rugalmasságra van szüksége, saját segédprogramokat is írhat.

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ás lehetővé teszi a különböző hitelesítési képességek integrálását a webalkalmazásba vagy AZ 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 kódot.
  • Több bejelentkezési szolgáltatóval is integrálható. Például: Microsoft Entra ID, Facebook, Google, Twitter.

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:

Provider 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
Bármely OpenID Csatlakozás-szolgáltató /.auth/login/<providerName> App Service OpenID Csatlakozás bejelentkezés
GitHub /.auth/login/github App Service GitHub-bejelentkezés

Ha engedélyezi a hitelesítést és az engedélyezést ezen szolgáltatók egyikével, annak 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.

How it works

A hitelesítési és engedélyezési modul ugyanabban a tesztkörnyezetben fut, mint az alkalmazás kódja. Ha engedélyezve van, minden bejövő HTTP-kérés áthalad rajta, mielőtt az alkalmazáskód kezelené. Ez a modul 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.

Megjegyzés:

Linux és tárolók esetén 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. Mivel nem fut a folyamaton belül, nem lehetséges a konkrét nyelvi keretrendszerekkel való közvetlen integráció.

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.

  • 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 a REST API-kra, az Azure Functionsre, a JavaScript böngészőügyfelekre és a felhasználókat a szolgáltató SDK-jával bejelentkező natív mobilalkalmazásokra vonatkozik.

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

Step Szolgáltatói SDK nélkül Szolgáltatói SDK-val
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.
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.
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.
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 (amelyet a Mobile Apps ügyféloldali SDK-k automatikusan kezelnek).

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

Az Azure Portalon számos viselkedéssel konfigurálhatja az App Service-t, ha egy bejövő kérés nincs hitelesítve.

  • 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 több bejelentkezési szolgáltató bemutatását a felhasználók számára.

  • Hitelesítés megkövetelése: Ez a beállítás elutasítja az alkalmazásba irányuló nem hitelesített forgalmat. Ez az elutasítás egy átirányítási művelet lehet 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. 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 egy HTTP 401 Unauthorized vagy HTTP 403 Forbidden minden kérés legyen.

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

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.

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

Ha engedélyezi az alkalmazásnaplózást, a rendszer közvetlenül a naplófájlokban gyűjti a hitelesítési és engedélyezési nyomkövetéseket. 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.