Megosztás a következőn keresztül:

Hitelesítés és engedélyezés az Azure Container Appsben

  • Cikk

Az Azure Container Apps beépített hitelesítési és engedélyezési funkciókat (más néven egyszerű hitelesítést) biztosít a külső bejövőforgalom-kompatibilis tárolóalkalmazás minimális vagy kód nélküli védelméhez.

A hitelesítés és az engedélyezés részleteiért tekintse meg az alábbi útmutatókat a szolgáltató kiválasztásához.

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. A hitelesítés (bejelentkezési 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 azonban 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.

A Container Apps beépített hitelesítési funkciója időt és energiát takarít meg azáltal, hogy beépített hitelesítést biztosít az összevont identitásszolgáltatókkal. Ezek a funkciók lehetővé teszik, hogy több időt összpontosítson az alkalmazás fejlesztésére, és kevesebb időt a biztonsági rendszerek kiépítésére.

Ez a következő előnyöket nyújtja:

  • Az Azure Container Apps hozzáférést biztosít a különböző beépített hitelesítésszolgáltatókhoz.
  • A beépített hitelesítési funkciók nem igényelnek semmilyen nyelvet, SDK-t, biztonsági szakértelmet vagy akár bármilyen írandó kódot.
  • Több szolgáltatóval is integrálható, beleértve a Microsoft Entra ID-t, a Facebookot, a Google-t és a Twittert.

Identitásszolgáltatók

A Container Apps ö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 Microsoft Identitásplatform
Facebook /.auth/login/facebook Facebook
GitHub /.auth/login/github GitHub
Google /.auth/login/google Google
Twitter /.auth/login/twitter Twitter
Bármely OpenID Csatlakozás szolgáltató /.auth/login/<providerName> OpenID Connect

Ha ezen szolgáltatók egyikét használja, a bejelentkezési végpont elérhető a szolgáltatótól származó felhasználói hitelesítéshez és hitelesítési jogkivonat-érvényesítéshez. A felhasználók számára tetszőleges számú szolgáltatói lehetőséget biztosíthat.

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

Ez a funkció csak HTTPS-lel használható. Győződjön meg arról, hogy allowInsecure le van tiltva a tárolóalkalmazás bejövő konfigurációjában.

Konfigurálhatja a tárolóalkalmazást hitelesítésre a webhelytartalomhoz és API-khoz való hozzáférés korlátozásával vagy anélkül. Ha csak hitelesített felhasználókra szeretné korlátozni az alkalmazáshozzáférést, állítsa be a Hozzáférés korlátozása beállítást hitelesítés megkövetelésére. A hitelesítéshez, de a hozzáférés korlátozásához állítsa a Hozzáférés korlátozása beállítást a hitelesítés nélküli hozzáférés engedélyezésére.

Alapértelmezés szerint minden tárolóalkalmazás saját egyedi cookie-t vagy jogkivonatot ad ki a hitelesítéshez. Saját aláírási és titkosítási kulcsokat is megadhat.

Funkcióarchitektúra

A hitelesítési és engedélyezési köztes szoftverösszetevő a platform egyik funkciója, amely oldalkocsi-tárolóként fut az alkalmazás minden replikáján. Ha engedélyezve van, az alkalmazás minden bejövő HTTP-kérést kezel, miután az áthaladt a biztonsági rétegen.

Egy architektúradiagram, amely azt mutatja be, hogy egy sidecar-tároló elfogja a kéréseket, amely interakcióba lép az identitásszolgáltatókkal, mielőtt engedélyezi az alkalmazástároló felé irányuló forgalmat

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

  • Felhasználók és ügyfelek hitelesítése a megadott identitásszolgáltatókkal
  • A hitelesített munkamenet kezelése
  • Identitásadatok beszúrása HTTP-kérelemfejlécekbe

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 a biztonsági tároló nem fut folyamatban, nem lehetséges a konkrét nyelvi keretrendszerekkel való közvetlen integráció. Az alkalmazás igényeinek megfelelő információkat azonban a jelen cikkben ismertetett kérésfejlécekben találja.

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 (kiszolgáló által irányított folyamat vagy kiszolgálói folyamat): Az alkalmazás összevont bejelentkezést delegál a Container Appsbe. A delegálás általában a böngészőalkalmazások esetében fordul elő, amelyek a szolgáltató bejelentkezési oldalát mutatják be a felhasználónak.

  • Szolgáltatói SDK -val (ügyfél által irányított folyamat vagy ügyfélfolyamat): Az alkalmazás manuálisan bejelentkezteti a felhasználókat a szolgáltatóba, majd elküldi a hitelesítési jogkivonatot a Container Appsnek ellenőrzés céljából. Ez a módszer olyan böngésző nélküli alkalmazások esetében jellemző, amelyek nem mutatják be a szolgáltató bejelentkezési oldalát a felhasználónak. Ilyen például egy natív mobilalkalmazás, amely bejelentkezteti a felhasználókat a szolgáltató SDK-jának használatára.

A Container Apps megbízható böngészőalkalmazásából egy másik REST API-ba irányuló hívások a Container Appsben a kiszolgáló által irányított folyamattal hitelesíthetők. További információ: Bejelentkezés és kijelentkezés testreszabása.

A 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 A Container Apps hitelesített cookie-t ad hozzá a válaszhoz. A Container Apps a saját hitelesítési jogkivonatát adja vissza az ügyfélkódhoz.
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 a Container Apps automatikusan átirányíthatja az összes nem hitelesített 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 szerkesztheti a tárolóalkalmazás hitelesítési beállításait, hogy különböző viselkedésekkel konfigurálja, amikor egy bejövő kérés nincs hitelesítve. Az alábbi címsorok a beállításokat írják le.

  • Hitelesítés nélküli hozzáférés 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 a Container Apps a HTTP-fejlécekben található hitelesítési információkat is átadja. Az alkalmazás a fejlécekben található információk segítségével engedélyezési döntéseket hozhat egy kéréshez.

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

    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

    Alapértelmezés szerint a Microsoft Entra-bérlő bármely felhasználója jogkivonatot kérhet az alkalmazáshoz a Microsoft Entra-azonosítóból. Konfigurálhatja az alkalmazást a Microsoft Entra-azonosítóban, ha korlátozni szeretné az alkalmazáshoz való hozzáférést egy meghatározott felhasználói csoportra.

Bejelentkezés és kijelentkezés testreszabása

A Container Apps-hitelesítés beépített végpontokat biztosít a bejelentkezéshez és a kijelentkezéshez. Ha a funkció engedélyezve van, ezek a végpontok a /.auth tárolóalkalmazás útvonalelőtagja alatt érhetők el.

Több bejelentkezési szolgáltató használata

A portál konfigurációja nem kínál kulcsrakész módot arra, hogy több bejelentkezési szolgáltatót jelenítsen meg a felhasználók számára (például a Facebookot és a Twittert is). A funkciót azonban nem nehéz hozzáadni az alkalmazáshoz. A lépések ismertetése alább látható:

Először az Azure Portal Hitelesítés/Engedélyezés lapján konfigurálja az összes engedélyezni kívánt identitásszolgáltatót.

Ha nem hitelesíti a kérést, válassza a Névtelen kérések engedélyezése (művelet nélkül) lehetőséget.

A bejelentkezési oldalon, a navigációs sávon vagy az alkalmazás bármely más helyén adjon hozzá egy bejelentkezési hivatkozást az összes engedélyezett szolgáltatóhoz (/.auth/login/<provider>). Példa:

<a href="/.auth/login/aad">Log in with the Microsoft Identity Platform</a>
<a href="/.auth/login/facebook">Log in with Facebook</a>
<a href="/.auth/login/google">Log in with Google</a>
<a href="/.auth/login/twitter">Log in with Twitter</a>

Amikor a felhasználó kiválasztja az egyik hivatkozást, a megfelelő szolgáltatók felhasználói felülete megjelenik a felhasználó számára.

Ha a bejelentkezést követően a felhasználót egyéni URL-címre szeretné átirányítani, használja a post_login_redirect_uri lekérdezési sztring paramétert (nem tévesztendő össze az identitásszolgáltató konfigurációjában szereplő átirányítási URI-val). Ha például a bejelentkezés után a felhasználóhoz /Home/Index szeretne navigálni, használja a következő HTML-kódot:

<a href="/.auth/login/<provider>?post_login_redirect_uri=/Home/Index">Log in</a>

Ügyfél által irányított bejelentkezés

Egy ügyfél által irányított bejelentkezésben az alkalmazás egy szolgáltatóspecifikus SDK használatával jelentkezik be a felhasználóba az identitásszolgáltatóhoz. Az alkalmazáskód ezután elküldi az eredményül kapott hitelesítési jogkivonatot a Container Appsnek ellenőrzés céljából (lásd a hitelesítési folyamatot) egy HTTP POST-kéréssel.

A szolgáltatói jogkivonat érvényesítéséhez először konfigurálnia kell a tárolóalkalmazást a kívánt szolgáltatóval. Futásidőben, miután lekérte a hitelesítési jogkivonatot a szolgáltatótól, tegye közzé a jogkivonatot /.auth/login/<provider> az ellenőrzéshez. Példa:

POST https://<hostname>.azurecontainerapps.io/.auth/login/aad HTTP/1.1
Content-Type: application/json

{"id_token":"<token>","access_token":"<token>"}

A jogkivonat formátuma a szolgáltatótól függően kissé eltérő. Részletekért tekintse meg az alábbi táblázatot:

Szolgáltatói érték Kötelező a kérelem törzsében Megjegyzések
aad {"access_token":"<ACCESS_TOKEN>"} A id_token, refresh_tokenés expires_in a tulajdonságok megadása nem kötelező.
microsoftaccount {"access_token":"<ACCESS_TOKEN>"} vagy {"authentication_token": "<TOKEN>" authentication_tokenelőnyben részesítve.access_token A expires_in tulajdonság megadása nem kötelező.
Amikor a jogkivonatot az Élő szolgáltatásoktól kéri le, mindig kérje le a hatókört wl.basic .
google {"id_token":"<ID_TOKEN>"} A authorization_code tulajdonság megadása nem kötelező. authorization_code Az érték megadása hozzáférési jogkivonatot és frissítési jogkivonatot ad hozzá a jogkivonattárhoz. Ha meg van adva, authorization_code opcionálisan egy tulajdonság is csatolható redirect_uri .
facebook {"access_token":"<USER_ACCESS_TOKEN>"} Használjon érvényes felhasználói hozzáférési jogkivonatot a Facebookról.
twitter {"access_token":"<ACCESS_TOKEN>", "access_token_secret":"<ACCES_TOKEN_SECRET>"}

Ha a szolgáltatói jogkivonat érvényesítése sikeresen megtörtént, az API a válasz törzsében egy, a munkamenet-jogkivonattal együtt authenticationToken tér vissza.

{
    "authenticationToken": "...",
    "user": {
        "userId": "sid:..."
    }
}

Miután megkapta ezt a munkamenet-jogkivonatot, hozzáférhet a védett alkalmazáserőforrásokhoz úgy, hogy hozzáadja a fejlécet a X-ZUMO-AUTH HTTP-kérésekhez. Példa:

GET https://<hostname>.azurecontainerapps.io/api/products/1
X-ZUMO-AUTH: <authenticationToken_value>

Kijelentkezés munkamenetből

A felhasználók kijelentkezhetnek, ha kérést GET küldenek az alkalmazás végpontjára /.auth/logout . A GET kérés a következő műveleteket hajtja végre:

  • Törli a hitelesítési cookie-kat az aktuális munkamenetből.
  • Törli az aktuális felhasználó jogkivonatait a jogkivonattárból.
  • Kiszolgálóoldali kijelentkezés végrehajtása a Microsoft Entra ID és a Google identitásszolgáltatóján.

Íme egy egyszerű kijelentkezés hivatkozás egy weblapon:

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

A sikeres kijelentkezés alapértelmezés szerint átirányítja az ügyfelet az URL-címre /.auth/logout/done. A kijelentkezés utáni átirányítási lapot a post_logout_redirect_uri lekérdezési paraméter hozzáadásával módosíthatja. Példa:

GET /.auth/logout?post_logout_redirect_uri=/index.html

Ügyeljen arra, hogy kódolja a következő post_logout_redirect_uriértékét: .

Az URL-címet ugyanabban a tartományban kell üzemeltetni, ha teljes körűen minősített URL-címeket használ.

Felhasználói jogcímek elérése az alkalmazáskódban

Minden nyelvi keretrendszer esetében a Container Apps elérhetővé teszi a bejövő jogkivonatban lévő jogcímeket az alkalmazáskód számára. A jogcímek be lesznek ágyazva a kérelemfejlécekbe, amelyek egy hitelesített végfelhasználótól vagy egy ügyfélalkalmazástól származnak. A külső kérések nem állíthatják be ezeket a fejléceket, ezért csak akkor jelennek meg, ha a Container Apps állítja be őket. Néhány példafejléc:

  • X-MS-CLIENT-PRINCIPAL-NAME
  • X-MS-CLIENT-PRINCIPAL-ID

A bármilyen nyelven vagy keretrendszerben írt kód ezekből a fejlécekből lekérheti a szükséges információkat.

Feljegyzés

A különböző nyelvi keretrendszerek ezeket az élőfejeket különböző formátumokban, például kisbetűs vagy címes formában jeleníthetik meg az alkalmazás kódjában.

Következő lépések

A tárolóalkalmazás biztonságossá tételével kapcsolatos részletekért tekintse meg az alábbi cikkeket.