Zabezpečený vývoj s aplikacemi s jednou stránkou (jednostránkové)

Při vývoji nativních distribuovaných systémů pro Cloud může zabezpečení těchto systémů zavádět novou vrstvu složitosti.

Místní systémy spoléhají na hranice zabezpečení, které poskytuje interní síť, a používají adresářové služby pro zabezpečení uživatelů. Můžou běžet spoustou let v rámci tohoto zabezpečeného prostředí bez problémů. Přechod do cloudu může představovat nová bezpečnostní rizika. Tento článek popisuje nástroje, které můžete použít ke zmírnění těchto rizik.

Jedním z těchto nástrojů je řízení přístupu. Řízení přístupu identifikuje uživatele a řídí, co můžou dělat při interakci s aplikací.

Řízení přístupu má dvě části:

  • Ověřování identifikuje uživatele.
  • Autorizace určuje, co může uživatel dělat v aplikaci.

OAuth, otevřená architektura, pomáhá řešit tyto výzvy a poskytuje protokol, který vývojářům umožňuje používat při sestavování svých systémů. OAuth 2,0 je aktuální standard.

OAuth 2,0 poskytuje zabezpečený delegovaný přístup. Vyvoláním přístupových tokenů můžete autorizovat přístup třetích stran k chráněným prostředkům bez zadání přihlašovacích údajů.

Azure Active Directory (Azure AD) je integrované řešení microsoftu pro správu identit v cloudu. Integruje se s místními systémy, takže uživatelé mají bezproblémové prostředí při přístupu k ochraně služeb v cloudu.

V této příručce se dozvíte, jak pomocí Azure AD a OAuth 2,0 zabezpečit jednostránkovou aplikaci.

Toky OAuth

Toky OAuth pokrývají mnoho případů použití, které jsou všechny zajištěné službami Azure AD. Vývojáři používají tyto toky k vytvoření zabezpečené aplikace, takže:

  • Uživatelé můžou zabezpečeně přistupovat k klientským systémům.
  • Uživatelé typu Host můžou být součástí transakcí Business-to-Business.
  • Uživatelé můžou kontaktovat koncové zákazníky prostřednictvím Azure Business na zákazníky (Azure B2C).

Diagram, který zobrazuje zabezpečený tok OAuth 2 mezi nativní aplikací a webovým rozhraním API.

Existují dva toky OAuth, implicitní udělení a autorizační kód. Implicitní udělení je nejběžnější, ale doporučujeme použít tok autorizačního kódu.

Registrace aplikace v Azure

Zaregistrujte instanční objekt pro uživatelské rozhraní a rozhraní API pomocí adresáře služby Azure AD ve Azure Portal.

  1. Přihlaste se k Azure Portala potom vyhledejte Registrace aplikací.

  2. Vyberte Nová registrace.

    Snímek obrazovky, který zobrazuje registrační stránku aplikace s vybranou novou registrací.

  3. K registraci nové aplikace potřebujete:

    • Zobrazovaný název aplikace
    • Podporovaný typ účtu.
    • Typ aplikace: web, SPA nebo veřejný klient/nativní (mobilní zařízení a Desktop).
    • Identifikátor URI pro přesměrování. Po ověření uživatele Azure AD přesměruje výsledek na klienta.

    Snímek obrazovky, který zobrazuje okno registrace aplikace.

  4. Vyberte Zaregistrovat.

  5. Po dokončení registrace vyberte Přehled a potom vyberte název vaší aplikace vedle spravované aplikace v místním adresáři.

    Snímek obrazovky zobrazující stránku s přehledem s vybraným názvem aplikace

  6. Chcete-li nastavit přístupová oprávnění pro aplikaci, vyberte možnost vlastnosti, přepínač přiřazení uživatele nutný pro hodnotu Ano a poté vyberte možnost Uložit.

    Snímek obrazovky zobrazující stránku vlastností s povoleným přiřazením uživatele

  7. Vyberte Uživatelé a skupiny a pak přidejte existující nebo nové uživatele a skupiny zabezpečení.

    Snímek obrazovky zobrazující stránku Uživatelé a skupiny s vybranou možnost Přidat uživatele nebo skupinu

  8. Uživatelé mají k aplikaci přístup prostřednictvím mých aplikací.

Nastavení podrobností konfigurace v klientské aplikaci

Po vytvoření a konfiguraci registrace aplikace v Azure můžete nastavit podrobnosti konfigurace v klientské aplikaci. v případě architektury s jednou stránkou, jako je Angular, vyvinula společnost Microsoft @Azure/msal-angular knihovnu, která vám může při integraci služby Azure AD v klientské aplikaci.

  1. Nainstalujte @Azure/msal-angular knihovnu.

  2. Nakonfigurujte knihovnu.

    • protectedResourceMapObsahuje seznam chráněných prostředků a jejich oborů v poli: [[Protected Resource], [obory pro prostředek]].
    • Do clientID authority objektu Configuration jsou dodány identifikátory a, které jsou ID tenanta.
    • U chráněných požadavků HTTP klient vloží novou vlastnost záhlaví s názvem Authorization. Obsahuje nosný token pro ověřeného uživatele. Nosný token poskytuje zabezpečený bod pro doručení OAuth 2,0. Může zahrnovat metadata pro službu při autorizaci žádosti.
export const protectedResourceMap: [string, string[]][]] = [
    ['https://graph.microsoft.com/v1.0/me', ['user.read']],
    ['https://localhost:5001/api/weatherforecast', ['api://ae05da8f-07d0-4ae6-aef1-18a6af68e5dd/access_as_user']]
];

function MSALConfigFactory(): Configuration {
    return {
        auth: {
            clientId: 'eba23c0b-1e86-4f68-b1d2-9c54d96083de',
            authority: 'https://login.microsoftonline.com/1c302616-bc6a-45a6-9c07-838c89d55003',
            redirectUri: 'http://localhost:4200',
            validateAuthority: true,
            postLogoutRedirectUri: 'http://localhost:4200',
            navigateToLoginRequestUrl: true
        },
        cache: {
            cacheLocation: 'sessionStorage',

            storeAuthStateInCookie: false //set to false, not ie 11
        }
    };
}

další informace o konfiguraci knihovny Angular najdete v tématu kurz: přihlášení uživatelů a volání rozhraní API Microsoft Graph z Angular jednostránkové aplikace (SPA) pomocí toku kódu ověřování.

Testování ověřování aplikace

Otestujte proces ověřování tím, že uživatel má přístup, a uživatel bez přístupu se pokusí přihlásit ke klientovi.

Uživatel se přihlásí k aplikaci a bude přesměrován do svého tenanta služby Azure AD.

  • Pokud je uživatel platný, jsou ověřováni a přihlášeni.
  • Pokud uživatel není platný, aplikace vrátí chybu.

Využívání chráněného prostředku nebo serveru prostředků

Pokud chcete využívat chráněný prostředek, vytvořte další registraci aplikace. Po dokončení registrace aplikace rozhraní API změní token nosiče tak, aby povoloval přístup.

Vystavení rozhraní API

  1. Vytvořte v Azure jinou registraci aplikace.

  2. Vyberte zveřejnit rozhraní API a pak vyberte Přidat obor.

    Snímek obrazovky zobrazující stránku rozhraní API s vybraným oborem přidat.

  3. Zadejte identifikátor URI ID aplikace a pak vyberte Uložit a pokračovat. Toto oprávnění používá rozhraní API k ověření žádosti.

    Snímek obrazovky se zadaným oknem přidat obor s identifikátorem URI ID aplikace a vybraným Uložit a pokračovat

  4. Nakonfigurujte název oboru a informace o jejich souhlasu. Když vyberete jenom oprávnění správce, můžou udělit souhlas s adresářem jenom správci.

    Snímek obrazovky, který zobrazuje okno Přidat konfiguraci oboru s příklady hodnot, které jsou zadány.

Přidání rozhraní API k registraci aplikace

Teď, když jste definovali vaše oprávnění a vystavili si rozhraní API, je nutné přidat rozhraní API k registraci aplikace pro klienta.

  1. V registraci aplikace vyberte oprávnění rozhraní API a pak přidejte oprávnění.

    Snímek obrazovky zobrazující stránku oprávnění rozhraní API s vybraným oprávněním přidat oprávnění

  2. Vyberte Moje rozhraní API a potom vyberte registraci rozhraní API, kterou jste vytvořili.

    Snímek obrazovky zobrazující kartu Moje rozhraní API s vybraným rozhraním API

  3. Vyberte obor, který jste vytvořili pro vystavení oprávnění rozhraní API, a pak vyberte Přidat oprávnění.

    Snímek obrazovky, který zobrazuje vybraný obor s vybraným tlačítkem Přidat oprávnění

Rozhraní API je teď přidané do aplikace. Vzhledem k tomu, že možná budete muset udělit souhlas pro přístup k rozhraní API, zvažte udělení souhlasu správce, aby uživatelé nemuseli znovu souhlasit.

Snímek obrazovky zobrazující rozhraní API přidané do aplikace

Přidat rozhraní API k mapě chráněných prostředků

Teď, když je konfigurace v Azure Portal dokončená, může klient uživatelského rozhraní spotřebovat prostředek. Přidejte rozhraní API k mapě chráněných prostředků, abyste se ujistili, že uživatelské rozhraní připojí pro požadavek rozhraní API správný nosný token.

export const protectedResourceMap: [string, string[]][] = [
    ['https://graph.microsoft.com/v1.0/me', ['user.read']],
    ['https://localhost:5001/api/weatherforecast', ['api://eba23c0b-1e86-4f68-b1d2-9c54d96083de/access_as_user']]
];

Když se klientská aplikace pokusí o přístup k prostředku, Klientská knihovna MSAL se pomocí skrytého prvku IFRAME ověří do Azure AD a potom vrátí nosný token pro daný prostředek. Nosný token se přidávají jenom pro požadavky, které odpovídají koncovému bodu, v tomto případě https://localhost:5001/api/weatherforecast .

Pokud rozhraní API, které jste nakonfigurovali s příslušnými registracemi aplikací, obdrží token nosiče s neplatným identifikátorem URI ID aplikace, požadavek odmítne a vrátí 401 neoprávněnou zprávu.

V následujícím příkladu je back-end služba napsaná v .NET Core. V příkladu se zobrazí vlastnosti konfigurace rozhraní API. ClientIdIdentifikátor URI ID aplikace je ve formátu api://{clientId} .

"AzureAD": {
  "Instance": "https://login.microsoftonline.com/",
  "Domain": "yourName.onmicrosoft.com",
  "TenantId": "1c302616-bc6a-45a6-9c07-838c89d55003",
  "ClientId": "api://ae05da8f-07d0-4ae6-aef1-18a6af68e5dd"
},

V rámci třídy Startup rozhraní API .NET Core se schéma ověřování a možnosti přidají do metody konfigurace služeb.

services.Addauthentication(AzureADDefaults.BearerAuthenticationScheme).AddAzureADBearer(options => Configuration.Bind("AzureAD",
  options));

Když klient volá rozhraní API, token nosiče se přidá do žádosti.

Snímek obrazovky zobrazující token nosiče přidaný do žádosti

Můžete přejít na jwt.ms a vložit token nosiče do formátu čitelného pro člověka.

Snímek obrazovky zobrazující token nosiče ve formátu čitelném pro člověka

Můžete vidět, že identifikátor URI rozhraní API je uvnitř aud Vlastnosti. Tato vlastnost identifikuje zamýšleného příjemce tokenu, což je vaše rozhraní API. Pokud vaše rozhraní API není zamýšleným příjemcem, tento požadavek automaticky odmítne pomocí odpovědi HTTP 401.

scpVlastnost obsahuje sadu oborů vystavených vaší aplikací. Pokud se prostřednictvím klienta přidají neplatné obory, Azure AD vrátí chybu požadující další autorizaci oboru.

Snímek obrazovky, který zobrazuje vlastnosti tokenu v souboru jwt.ms.

Použití manifestu aplikace k dalšímu definování autorizace

Další postupy autorizace jsou implementované pomocí manifestu aplikace pro registraci aplikace API. Vzhledem k tomu, že jste explicitně definovali uživatele, můžete přidat další úrovně autorizace a zpřístupnit přístup k citlivým prostředkům pouze členům konkrétní skupiny zabezpečení.

  1. V registraci aplikace vyberte možnost manifest.

    Snímek obrazovky zobrazující stránku manifestu

  2. Podle potřeby upravte páry klíč-hodnota objektu JSON.

Obecně je nejlepší jenom problém SecurityGroup . Pokud používáte All , generují se skupiny zabezpečení, role Azure AD a distribuční skupiny. Token má nastaven limit 200 a v případě dosažení tohoto limitu je přidána deklarace identity překročení. deklarace identity odkazuje na koncový bod Graph a načítá seznam skupin pro uživatele.

Po konfiguraci má token JWT novou vlastnost, groups která obsahuje jedinečná ID objektů, která lze použít k vymáhání autorizace.

Rozhraní API se dá nakonfigurovat pomocí zásady, která vyhledává požadovanou deklaraci identity a hodnotu pro autorizaci založenou na rolích prostřednictvím obslužné rutiny zásad.

public void ConfigureServices(IServiceCollection services)
{

    services.AddAuthentication(AzureADDefaults.BearerAuthenticationScheme).AddAzureADBearer(options => Configuration.Bind("AzureAD",
      options));

    services.AddAuthorization(options =>
    {

        options.AddPolicy("DensuAegisReportsAdmin", policyBuilder =>
        {
            policyBuilder.RequireClaim("groups", "ebde25e7-d254-474e-ae33-cd491aa98ebf"); //This would be an environment variable
        });
});

    JWTSecurityTokenHandler.DefaultMapInboundClaims = false;
    services.AddCors();

    services.AddControllers();
}

Kontroler pro rozhraní API může mít přidané příslušné přizpůsobené položky. Tyto atributy nabízejí lepší zabezpečení a umožňují potvrdit, že ověřené osoby mají oprávnění pro přístup k chráněnému prostředku.

[Route("admin")]
[Authorize("DensuAegisReportsAdmin")]
public IActionResult GetForcastsForAdmin()
{
    var user = User.Claims;

    var groups = User.Claims.Where(c => c.Type == "groups").Select(c => c.Value).ToList();
    var userName = UserClaims.Where(c => c.Type == "unique_name").Select(c => c.Value).FirstOrDefault();
    // SecurityGroup = groups
    var rng = new Random();
    var forecasts = Enumerable.Range(1, 5).Select(index => new WeatherForecast
    {
        Date = DateTime.Now.AddDays(index),
        TemperatureC = rng.Next(-20, 55),
        Summary = Summaries[rng.Next(Summaries.Length)],

    })
    .ToArray();

    return Ok(new
    {
        User = userName
        ,
        SecurityGroup = groups
        ,
        Forcasts = forecasts
    });
}

S manifestem aplikace, který je jedinečný pro registraci aplikace, lze vytvořit další role. V kontextu aplikace je pak možné vytvořit více skupin.

Snímek obrazovky, který ukazuje příklad appRole přidané do manifestu.

Můžete například vytvořit vlastní roli s názvem AppAdmin, která je pro registraci aplikace jedinečná. Pomocí sestavení podnikové aplikace můžete této roli přiřadit uživatele nebo skupiny zabezpečení.

Při volání chráněného prostředku po změně konfigurace má nosný token roles vlastnost uvnitř nosného tokenu.

Snímek obrazovky zobrazující vlastnost role v nosných tokenech

Rozhraní API se konfiguruje pomocí Tvůrce zásad v části Konfigurovat služby.

            // Adding authorization policies that enforce authorization using Azure AD roles.
            services.AddAuthorization(options =>
            {
                options.AddPolicy(AuthorizationPolicies.AssignmentToAppAdminRoleRequired, policy =>
                  policy.RequireRole(AppRole.AppAdmin));
            });

Chráněná trasa používá zásadu autorizace k ujištění, že ověřený uživatel je v příslušné roli před autorizací žádosti.

Další kroky