Bejelentkezés és kijelentkezés testreszabása Azure-alkalmazás Szolgáltatáshitelesítésben

  • Cikk

Ez a cikk bemutatja, hogyan szabhatja testre a felhasználói bejelentkezéseket és kijelentkezéseket az App Service beépített hitelesítése és engedélyezése során.

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>
<a href="/.auth/login/apple">Log in with Apple</a>

Amikor a felhasználó az egyik hivatkozásra kattint, megnyílik a megfelelő bejelentkezési oldal a felhasználó bejelentkezéséhez.

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 az App Service-nek ellenőrzés céljából (lásd a hitelesítési folyamatot) egy HTTP POST-kéréssel. Ez az ellenőrzés valójában nem biztosít hozzáférést a kívánt alkalmazáserőforrásokhoz, de a sikeres érvényesítés egy munkamenet-jogkivonatot ad, amellyel hozzáférhet az alkalmazás erőforrásaihoz.

A szolgáltatói jogkivonat érvényesítéséhez az App Service-alkalmazást először a kívánt szolgáltatóval kell konfigurálni. 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://<appname>.azurewebsites.net/.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 egy hozzáférési jogkivonatot és egy 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":"<access_token_secret>"}

Feljegyzés

Az App Service-hitelesítés GitHub-szolgáltatója nem támogatja a testreszabott bejelentkezést és kijelentkezéseket.

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://<appname>.azurewebsites.net/api/products/1
X-ZUMO-AUTH: <authenticationToken_value>

Kijelentkezés munkamenetből

A felhasználók úgy kezdeményezhetnek kijelentkezést, hogy kérést GET küldenek az alkalmazás végpontjára /.auth/logout . A GET kérés a következőt 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.
  • A Microsoft Entra ID és a Google esetében kiszolgálóoldali kijelentkezés történik az identitásszolgáltatón.

A következő egy egyszerű kijelentkezési hivatkozás egy webhelyen:

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

Javasoljuk, hogy kódolja a függvény értékét post_logout_redirect_uri.

Teljes körű URL-címek használata esetén az URL-címet ugyanabban a tartományban kell üzemeltetni, vagy az alkalmazás engedélyezett külső átirányítási URL-címeként kell konfigurálni. Az alábbi példában a nem ugyanabban a tartományban üzemeltetett tartományra való https://myexternalurl.com átirányításhoz:

GET /.auth/logout?post_logout_redirect_uri=https%3A%2F%2Fmyexternalurl.com

Futtassa a következő parancsot az Azure Cloud Shellben:

az webapp auth update --name <app_name> --resource-group <group_name> --allowed-external-redirect-urls "https://myexternalurl.com"

URL-töredékek megőrzése

Miután a felhasználók bejelentkeztek az alkalmazásba, általában ugyanahhoz a laphoz szeretnének átirányítani őket, például /wiki/Main_Page#SectionZ. Mivel azonban az URL-töredékek (például #SectionZ) soha nem kerülnek a kiszolgálóra, az OAuth-bejelentkezés befejezése és az alkalmazásra való visszairányítás után alapértelmezés szerint nem maradnak meg. A felhasználók ezután nem optimális élményt kapnak, amikor ismét a kívánt horgonyra kell navigálniuk. Ez a korlátozás az összes kiszolgálóoldali hitelesítési megoldásra vonatkozik.

Az App Service-hitelesítésben megőrizheti az URL-töredékeket az OAuth-bejelentkezés során. Ehhez állítsa be a következőre hívott WEBSITE_AUTH_PRESERVE_URL_FRAGMENT alkalmazásbeállítást true: . Ezt megteheti az Azure Portalon, vagy egyszerűen futtathatja a következő parancsot az Azure Cloud Shellben:

az webapp config appsettings set --name <app_name> --resource-group <group_name> --settings WEBSITE_AUTH_PRESERVE_URL_FRAGMENT="true"

Bejelentkezési fiókok tartományának korlátozása

A Microsoft-fiók és a Microsoft Entra-azonosító egyaránt lehetővé teszi, hogy több tartományból jelentkezzen be. A Microsoft-fiók például lehetővé teszi outlook.com, live.com és hotmail.com fiókok használatát. A Microsoft Entra ID tetszőleges számú egyéni tartományt engedélyez a bejelentkezési fiókokhoz. Előfordulhat azonban, hogy közvetlenül a saját márkás Microsoft Entra bejelentkezési oldalára szeretné felgyorsítani a felhasználókat (például contoso.com). A bejelentkezési fiókok tartománynevének javaslatához kövesse az alábbi lépéseket.

  1. A https://resources.azure.comlap tetején válassza az Olvasás/Írás lehetőséget.

  2. A bal oldali böngészőben lépjen az előfizetések<>előfizetés-neve>resourceGroups<>resource-group-name>>providers>Microsoft.Web>sites><app-name>>config>authsettingsV2 elemre.

  3. Kattintson a Szerkesztés gombra.

  4. Adjon hozzá egy loginParameters tömböt egy domain_hint elemhez.

    "identityProviders": {
    "azureActiveDirectory": {
        "login": {
            "loginParameters": ["domain_hint=<domain-name>"],
        }
    }
}

  5. Kattintson a Fel gombra.

Ez a beállítás hozzáfűzi a domain_hint lekérdezési sztring paramétert a bejelentkezési átirányítás URL-címéhez.

Fontos

Az ügyfél eltávolíthatja a paramétert, miután megkapta az domain_hint átirányítási URL-címet, majd bejelentkezhet egy másik tartománnyal. Tehát bár ez a függvény kényelmes, nem biztonsági funkció.

Felhasználók engedélyezése vagy letiltása

Bár az App Service gondoskodik a legegyszerűbb engedélyezési esetről (azaz elutasítja a nem hitelesített kérelmeket), az alkalmazás részletesebb engedélyezési viselkedést igényelhet, például a hozzáférés korlátozását csak egy adott felhasználócsoportra. Bizonyos esetekben egyéni alkalmazáskódot kell írnia a bejelentkezett felhasználó hozzáférésének engedélyezéséhez vagy letiltásához. Más esetekben előfordulhat, hogy az App Service vagy az identitásszolgáltatója kódmódosítások nélkül tud segíteni.

Kiszolgálói szint (csak Windows-alkalmazások esetén)

Bármely Windows-alkalmazás esetében meghatározhatja az IIS-webkiszolgáló engedélyezési viselkedését a Web.config fájl szerkesztésével. A Linux-alkalmazások nem használnak IIS-t, és nem konfigurálhatók a Web.config használatával.

  1. Navigáljon ide: https://<app-name>.scm.azurewebsites.net/DebugConsole

  2. Az App Service-fájlok böngészőböngészőjében keresse meg a webhelyet/wwwroot webhelyet. Ha a Web.config nem létezik, hozza létre az Új fájl lehetőséget választva+>.

  3. Jelölje ki a Web.config ceruzát a szerkesztéshez. Adja hozzá a következő konfigurációs kódot, és kattintson a Mentés gombra. Ha a Web.config már létezik, csak adja hozzá az <authorization> elemet a benne lévő összes elemhez. Adja hozzá az elemhez <allow> engedélyezni kívánt fiókokat.

    <?xml version="1.0" encoding="utf-8"?>
<configuration>
   <system.web>
      <authorization>
        <allow users="user1@contoso.com,user2@contoso.com"/>
        <deny users="*"/>
      </authorization>
   </system.web>
</configuration>

Identitásszolgáltatói szint

Az identitásszolgáltató bizonyos kulcskulcs-engedélyezést biztosíthat. Példa:

Alkalmazásszint

Ha valamelyik másik szint nem adja meg a szükséges hitelesítést, vagy ha a platform vagy identitásszolgáltató nem támogatott, egyéni kódot kell írnia a felhasználók felhasználói jogcímek alapján történő engedélyezéséhez.

További erőforrások