Přizpůsobení přihlášení a odhlášení v Azure App Service ověřování

V tomto článku se dozvíte, jak přizpůsobit přihlašování a přihlášení uživatelů při používání integrovaného ověřování a autorizace v App Service.

Použití více poskytovatelů přihlašování

Konfigurace portálu nenabízí způsob, jak pro uživatele prezentovat více poskytovatelů přihlášení (například Facebook i Twitter). Do vaší aplikace ale není obtížné přidávat funkce. Postup je popsaný následujícím způsobem:

Nejprve na stránce ověřování/autorizace v Azure Portal nakonfigurujte každého poskytovatele identity, kterého chcete povolit.

V akci, která se má provést, když se žádost neověřuje, vyberte možnost povoluje anonymní žádosti (bez akce).

Na přihlašovací stránce nebo v navigačním panelu nebo jakémkoli jiném umístění aplikace přidejte odkaz pro přihlášení ke každému poskytovateli, který jste povolili ( /.auth/login/<provider> ). Příklad:

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

Když uživatel klikne na jeden z odkazů, otevře se příslušná přihlašovací stránka pro přihlášení uživatele.

Pokud chcete přesměrovat uživatele po přihlášení na vlastní adresu URL, použijte post_login_redirect_uri parametr řetězce dotazu (Nezaměňujte ho pomocí identifikátoru URI přesměrování v konfiguraci zprostředkovatele identity). Chcete-li například procházet uživatele /Home/Index po přihlášení, použijte následující kód HTML:

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

Přihlášení zaměřené na klienta

V přihlašování klienta se aplikace přihlásí uživateli k poskytovateli identity pomocí sady SDK pro konkrétního zprostředkovatele. Kód aplikace poté odešle výsledný ověřovací token k App Service k ověření (viz tok ověřování) pomocí požadavku HTTP POST. Sady SDK pro Azure Mobile Apps používají tento tok přihlášení. Toto ověření sama o sobě neuděluje přístup k požadovaným prostředkům aplikace, ale úspěšné ověření vám poskytne token relace, který můžete použít pro přístup k prostředkům aplikace.

Pokud chcete ověřit token poskytovatele, App Service aplikace musí být nejdřív nakonfigurované s požadovaným poskytovatelem. Po načtení tokenu ověřování od poskytovatele za běhu vystavte token /.auth/login/<provider> pro ověření. Příklad:

POST https://<appname>.azurewebsites.net/.auth/login/aad HTTP/1.1
Content-Type: application/json

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

Formát tokenu se mírně liší v závislosti na poskytovateli. Podrobnosti najdete v následující tabulce:

Hodnota poskytovatele Vyžadováno v textu žádosti Komentáře
aad {"access_token":"<access_token>"} id_tokenVlastnosti, refresh_token a expires_in jsou volitelné.
microsoftaccount {"access_token":"<access_token>"} nebo {"authentication_token": "<token>" authentication_token je upřednostňovaný access_token . expires_inVlastnost je nepovinná.
Při žádosti o token ze služby Live Services vždy vyžádat wl.basic rozsah.
google {"id_token":"<id_token>"} authorization_codeVlastnost je nepovinná. Zadáním authorization_code hodnoty se přidá přístupový token a obnovovací token do úložiště tokenů. Je-li tento parametr zadán, authorization_code může být také případně doplněn redirect_uri vlastností.
facebook {"access_token":"<user_access_token>"} Použijte platný přístupový token uživatele z Facebooku.
twitter {"access_token":"<access_token>", "access_token_secret":"<acces_token_secret>"}

V případě úspěšného ověření tokenu poskytovatele vrátí rozhraní API authenticationToken text v odpovědi, který je vaším tokenem relace.

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

Po vytvoření tohoto tokenu relace můžete získat přístup k prostředkům chráněných aplikací přidáním X-ZUMO-AUTH hlavičky do požadavků HTTP. Příklad:

GET https://<appname>.azurewebsites.net/api/products/1
X-ZUMO-AUTH: <authenticationToken_value>

Odhlásit se z relace

Uživatelé můžou zahájit odhlášení odesláním GET žádosti do /.auth/logout koncového bodu aplikace. GETPožadavek provede následující akce:

  • Vymaže soubory cookie ověřování z aktuální relace.
  • Odstraní tokeny aktuálního uživatele z úložiště tokenů.
  • pro Azure Active Directory a Google provede na poskytovateli identity přihlášení na straně serveru.

Tady je jednoduchý odkaz na odhlášení z webové stránky:

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

Ve výchozím nastavení se při úspěšném odhlášení přesměruje klient na adresu URL /.auth/logout/done . Stránku přesměrování po odhlášení můžete změnit přidáním post_logout_redirect_uri parametru dotazu. Příklad:

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

Doporučuje se kódovat hodnotu post_logout_redirect_uri .

Při použití plně kvalifikovaných adres URL musí být adresa URL buď hostovaná ve stejné doméně, nebo nakonfigurovaná jako povolená externí adresa URL pro přesměrování vaší aplikace. V následujícím příkladu pro přesměrování na https://myexternalurl.com , který není hostovaný ve stejné doméně:

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

Spusťte následující příkaz v Azure Cloud Shell:

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

Zachovat fragmenty adresy URL

Až se uživatelé přihlásí do aplikace, obvykle chtějí být přesměrováni na stejnou část stejné stránky, jako je například /wiki/Main_Page#SectionZ . Protože se ale Fragmenty adresy URL (například #SectionZ ) nikdy neodesílají na server, po dokončení přihlášení OAuth a přesměrování zpátky do vaší aplikace se ve výchozím nastavení nezachovají. Uživatelé pak dostanou optimální prostředí, když potřebují znovu přejít k požadovanému kotvu. Toto omezení se vztahuje na všechna řešení ověřování na straně serveru.

V App Service ověřování můžete zachovat fragmenty adresy URL v rámci přihlášení OAuth. To provedete tak, že nastavíte nastavení aplikace WEBSITE_AUTH_PRESERVE_URL_FRAGMENT s názvem na true . Můžete to provést v Azure Portalnebo stačí spustit následující příkaz v Azure Cloud Shell:

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

Omezení domény přihlašovacích účtů

účet Microsoft i Azure Active Directory vám umožňují přihlašovat se z více domén. Například účet Microsoft umožňuje účty Outlook.com, Live.com a hotmail.com . Azure AD povoluje pro přihlašovací účty libovolný počet vlastních domén. Můžete ale chtít zrychlit uživatele přímo na přihlašovací stránku služby Azure AD, která je označená značkou (například contoso.com ). Chcete-li navrhnout název domény přihlašovacích účtů, postupujte podle těchto kroků.

V https://resources.azure.com přejděte na odběry > * <subscription_name* > resourceGroups > * _ <resource_group_name> * > poskytovatelé > společnosti Microsoft. > weby > * * <app_name> _ * * > config > authsettings.

Klikněte na tlačítko Upravit, upravte následující vlastnost a pak klikněte na tlačítko Vložit. Nezapomeňte nahradit <domain_name> doménou, kterou chcete.

"additionalLoginParams": ["domain_hint=<domain_name>"]

Toto nastavení připojí domain_hint parametr řetězce dotazu k adrese URL pro přesměrování přihlášení.

Důležité

Klient může domain_hint po přijetí adresy URL pro přesměrování odebrat parametr a pak se přihlásit k jiné doméně. Takže když je tato funkce užitečná, není to funkce zabezpečení.

Autorizovat nebo Odepřít uživatele

I když App Service postará o nejjednodušší případ autorizace (tj. odmítnout neověřené žádosti), vaše aplikace může vyžadovat přesnější chování autorizace, jako je omezení přístupu jenom na konkrétní skupinu uživatelů. V některých případech je nutné napsat vlastní kód aplikace, aby bylo možné povolit nebo odepřít přístup přihlášenému uživateli. V jiných případech App Service nebo váš poskytovatel identity může pomáhat bez nutnosti změny kódu.

úroveň serveru (jenom Windows aplikace)

u jakékoli Windows aplikace můžete definovat chování ověřování webového serveru IIS úpravou souboru Web.config . Aplikace pro Linux nepoužívají službu IIS a nelze je konfigurovat prostřednictvím Web.config.

  1. Přejděte na adresu https://<app-name>.scm.azurewebsites.net/DebugConsole.

  2. V Průzkumníkovi prohlížeče souborů App Service přejděte na lokalitu/wwwroot. Pokud Web.config neexistuje, vytvořte ho výběrem možnosti + > nový soubor.

  3. Vyberte tužku pro Web.config a upravte ji. Přidejte následující konfigurační kód a klikněte na Uložit. Pokud Web.config již existuje, stačí přidat <authorization> prvek se všemi. Přidejte účty, které chcete v <allow> elementu použít.

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

Úroveň poskytovatele identity

Poskytovatel identity může poskytovat určitou autorizaci autorizace klíče. Příklad:

Úroveň aplikace

Pokud žádná z ostatních úrovní neposkytne autorizaci, kterou potřebujete, nebo pokud vaše platforma nebo zprostředkovatel identity není podporována, musíte napsat vlastní kód, který autorizuje uživatele na základě deklarací identity uživatele.

Další zdroje informací