Vrácení podpisového klíče na platformě Microsoft Identity Platform

Tento článek popisuje, co potřebujete vědět o veřejných klíčích používaných platformou Microsoft Identity Platform k podepisování tokenů zabezpečení. Je důležité si uvědomit, že tyto klíče se pravidelně převrácejí a v nouzovém stavu by se mohly okamžitě vrátit. Všechny aplikace, které používají platformu Microsoft Identity Platform, by měly být schopné programově zpracovávat proces přechodu klíčů. Porozumíte tomu, jak fungují klíče, jak vyhodnotit dopad přechodu do aplikace. Dozvíte se také, jak aktualizovat aplikaci nebo vytvořit pravidelný ruční proces přechodu, který bude v případě potřeby zpracovávat vrácení klíče.

Přehled podpisových klíčů na platformě Microsoft Identity Platform

Platforma Microsoft Identity Platform používá kryptografii veřejného klíče postavenou na oborových standardech k navázání důvěryhodnosti mezi sebou a aplikacemi, které ji používají. V praxi to funguje následujícím způsobem: Platforma Microsoft Identity Platform používá podpisový klíč, který se skládá z páru veřejného a privátního klíče. Když se uživatel přihlásí k aplikaci, která k ověřování používá platformu Microsoft Identity Platform, vytvoří platforma Microsoft Identity Platform token zabezpečení, který obsahuje informace o uživateli. Tento token je podepsán platformou Microsoft Identity Platform pomocí svého privátního klíče před odesláním zpět do aplikace. Aby bylo možné ověřit platnost tokenu a pochází z platformy Microsoft Identity Platform, musí aplikace ověřit podpis tokenu pomocí veřejných klíčů vystavených platformou Microsoft Identity Platform, která je obsažena v dokumentu zjišťování OpenID Connect tenanta nebo dokumentu metadat federace SAML/WS-Fed.

Pro účely zabezpečení se podpisový klíč platformy Microsoft Identity Platform pravidelně zapisuje a v případě tísňového volání je možné okamžitě vrátit. Mezi těmito hody klíčů není nastavená ani garantovaná doba. Každá aplikace, která se integruje s platformou Microsoft Identity Platform, by měla být připravená na zpracování události přechodu klíče bez ohledu na to, jak často může dojít. Pokud vaše aplikace nezpracuje náhlé aktualizace a pokusí se ověřit podpis v tokenu pomocí klíče s vypršenou platností, aplikace token nesprávně odmítne. Doporučuje se používat standardní knihovny k zajištění správné aktualizace klíčových metadat a aktuály. V případech, kdy se nepoužívají standardní knihovny, se ujistěte, že implementace dodržuje část s osvědčenými postupy .

V dokumentu zjišťování OpenID Connect a dokumentu federačních metadat je vždy k dispozici více než jeden platný klíč. Vaše aplikace by měla být připravená použít všechny a všechny klíče zadané v dokumentu, protože jeden klíč může být brzy vrácen, další může být jeho nahrazení atd. Počet klíčů, které existují, se může v průběhu času měnit na základě interní architektury platformy Microsoft Identity Platform, protože podporujeme nové platformy, nové cloudy nebo nové ověřovací protokoly. Pořadí klíčů v odpovědi JSON ani pořadí, ve kterém byly vystaveny, by pro vaši aplikaci nemělo být považováno za smysluplné. Další informace o datové struktuře webového klíče JSON najdete v RFC7517.

Aplikace, které podporují pouze jeden podpisový klíč nebo aplikace, které vyžadují ruční aktualizace podpisových klíčů, jsou ze své podstaty méně bezpečné a méně spolehlivé. Měly by se aktualizovat tak, aby používaly standardní knihovny , aby zajistily, že vždy používají aktuální podpisové klíče, mimo jiné osvědčené postupy.

Osvědčené postupy pro ukládání a ověřování metadat klíčů

• Zjišťování klíčů pomocí koncového bodu specifického pro tenanta, jak je popsáno v openID Connect (OIDC) a metadatech federace
• I když je vaše aplikace nasazená napříč více tenanty, doporučuje se vždy zjišťovat a ukládat klíče do mezipaměti nezávisle pro každého tenanta, který aplikace obsluhuje (pomocí koncového bodu specifického pro tenanta). Klíč, který je v současné době společný pro tenanty, se může v budoucnu v různých tenantech lišit.
• Pomocí následujícího algoritmu ukládání do mezipaměti se ujistěte, že je ukládání do mezipaměti odolné a zabezpečené.

Algoritmus ukládání metadat do mezipaměti klíčů:

Naše standardní knihovny implementují odolné a zabezpečené ukládání klíčů do mezipaměti. Doporučuje se je použít, abyste se vyhnuli drobným vadám v implementaci. Pro vlastní implementace je tady hrubý algoritmus:

Obecné aspekty:

• Ověřování tokenů služby by mělo mít mezipaměť umožňující ukládání mnoha různých klíčů (10–1000).
• Klíče by se měly ukládat do mezipaměti jednotlivě pomocí ID klíče ("kid" ve specifikaci metadat klíčů OIDC) jako klíče mezipaměti.
• Klíče v mezipaměti by měly být nakonfigurované na 24 hodin, přičemž aktualizace probíhají každou hodinu. Tím se zajistí, že systém dokáže rychle reagovat na odebrané klíče, ale má dostatek doby trvání mezipaměti, aby nebyl ovlivněn problémy při načítání klíčů.
• Klíče by se měly aktualizovat:
  • Po spuštění procesu nebo když je mezipaměť prázdná
  • Pravidelně (doporučeno každých 1 hodinu) jako úloha na pozadí
  • Dynamicky, pokud byl přijatý token podepsán neznámým klíčem (neznámým dítětem nebo svázaným v hlavičce)

Procedura KeyRefresh (koncepční algoritmus z modelu IdentityModel)

1. Inicializace

   Správce konfigurace je nastavený s konkrétní adresou pro načtení konfiguračních dat a potřebných rozhraní pro načtení a ověření těchto dat.

2. Kontrola konfigurace

   Před načtením nových dat systém nejprve zkontroluje, jestli jsou stávající data stále platná na základě předdefinovaného intervalu aktualizace.

3. Načítání dat Pokud jsou data zastaralá nebo chybí, systém uzamkne, aby se zajistilo, že nová data načte pouze jedno vlákno, aby nedocházelo k duplicitě (a vyčerpání vláken). Systém se pak pokusí načíst nejnovější konfigurační data ze zadaného koncového bodu.

4. Ověření

   Po načtení nových dat se ověří, že splňují požadované standardy a nejsou poškozená. Metadata se přijímají pouze v případech, kdy se příchozí požadavek úspěšně ověřil pomocí nových klíčů.

5. Zpracování chyb

   Pokud během načítání dat dojde k nějakým chybám, zaprotokolují se. Systém nadále funguje s poslední známou dobrou konfigurací, pokud se nová data nedají načíst.

6. Automatické aktualizace Systém pravidelně kontroluje a aktualizuje konfigurační data automaticky na základě intervalu aktualizace (doporučujeme 12 h s chvění plus nebo minus 1 h). V případě potřeby může také ručně požádat o aktualizaci a zajistit, aby data byla vždy aktuální.

7. Ověření tokenu s novým klíčem Pokud token dorazí s podpisovým klíčem, který ještě není známý z konfigurace, systém se pokusí načíst konfiguraci pomocí volání synchronizace na horké cestě pro zpracování nových klíčů v metadatech mimo běžné očekávané aktualizace (ale častěji než 5 minut).

Tento přístup zajišťuje, že systém vždy používá nejaktuálnější a platná konfigurační data, zatímco řádně zpracovává chyby a zabraňuje redundantním operacím.

Implementace rozhraní .NET tohoto algoritmu je k dispozici v BaseConfigurationManageru. Na základě odolnosti a vyhodnocení zabezpečení se může změnit. Vysvětlení najdete také tady.

Procedura KeyRefresh (pseudokód):

Tento postup používá globální časové razítko (lastSuccessfulRefreshTime), aby se zabránilo podmínkám, které aktualizují klíče příliš často.

• OpenID Connect (OIDC)

KeyRefresh(issuer)
{
  // Store cache entries and last successful refresh timestamp per distinct 'issuer'
 
  if (LastSuccessfulRefreshTime is set and more recent than 5 minutes ago) 
    return // without refreshing
 
  // Load keys URI using the tenant-specific OIDC configuration endpoint ('issuer' is the input parameter)
  oidcConfiguration = download JSON from "{issuer}/.well-known/openid-configuration"
 
  // Load list of keys from keys URI
  keyList = download JSON from jwks_uri property of oidcConfiguration
 
  foreach (key in keyList) 
  {
    cache entry = lookup in cache by kid property of key
    if (cache entry found) 
      set expiration of cache entry to now + 24h 
    else 
      add key to cache with expiration set to now + 24h
  }
 
  set LastSuccessfulRefreshTime to now // current timestamp
}

Postup spuštění služby:

• KeyRefresh pro aktualizaci klíčů
• Spuštění úlohy na pozadí, která volá KeyRefresh každou hodinu

Procedura TokenValidation pro ověření klíče (pseudokód):

ValidateToken(token)
{
  kid = token.header.kid // get key id from token header
  issuer = token.body.iss // get issuer from 'iss' claim in token body
 
  key = lookup in cache by issuer and kid
  if (key found)
  {
     validate token with key and return
  }
  else // key is not found in the cache
  {
    call KeyRefresh(issuer) // to opportunistically refresh the keys for the issuer
    key = lookup in cache by issuer and kid
    if (key found)
    {
      validate token with key and return
    }
    else // key is not found in the cache even after refresh
    {
      return token validation error
    }
  }
}

Jak posoudit, jestli bude vaše aplikace ovlivněná a co s ní dělat

Způsob, jakým vaše aplikace zpracovává převod klíčů, závisí na proměnných, jako je typ aplikace nebo jaký protokol identity a knihovna se použily. V následujících částech se dozvíte, jestli jsou nejběžnější typy aplikací ovlivněné převodem klíče, a poskytují pokyny k aktualizaci aplikace tak, aby podporovala automatické převrácení nebo ruční aktualizaci klíče.

• Nativní klientské aplikace přistupující k prostředkům
• Webové aplikace / rozhraní API přistupující k prostředkům
• Webové aplikace / rozhraní API chrání prostředky a vytvářejí se pomocí Aplikace Azure Services
• Webové aplikace / rozhraní API chránící prostředky pomocí ASP.NET OWIN OpenID Connect, WS-Fed nebo WindowsAzureActiveDirectoryBearerAuthentication middleware
• Webové aplikace / rozhraní API chránící prostředky pomocí middlewaru ASP.NET Core OpenID Connect nebo JwtBearerAuthentication
• Webové aplikace / rozhraní API chránící prostředky pomocí modulu Node.js passport-azure-ad
• Webové aplikace / rozhraní API chránící prostředky a vytvořené pomocí sady Visual Studio 2015 nebo novější
• Webové aplikace chrání prostředky a vytvářejí se pomocí sady Visual Studio 2013
• Webová rozhraní API chrání prostředky a vytvářejí se pomocí sady Visual Studio 2013
• Webové aplikace chrání prostředky a vytvořené pomocí sady Visual Studio 2012
• Webové aplikace / rozhraní API chrání prostředky pomocí jakékoli jiné knihovny nebo ručně implementují některý z podporovaných protokolů.

Tyto pokyny neplatí pro:

• Aplikace přidané z Galerie aplikací Microsoft Entra (včetně vlastních) obsahují samostatné pokyny týkající se podpisových klíčů. Další informace.
• Místní aplikace publikované prostřednictvím proxy aplikací se nemusí starat o podpisové klíče.

Nativní klientské aplikace přistupující k prostředkům

Aplikace, které přistupují jenom k prostředkům (například Microsoft Graph, KeyVault, Rozhraní API Outlooku a další rozhraní API Microsoftu), získají token a předají ho vlastníkovi prostředku. Vzhledem k tomu, že nechrání žádné prostředky, neprověřují token, a proto se nemusí ujistit, že je správně podepsaný.

Nativní klientské aplikace, ať už desktopové nebo mobilní, spadají do této kategorie, a proto nejsou ovlivněny převrácením.

Webové aplikace / rozhraní API přistupující k prostředkům

Aplikace, které přistupují jenom k prostředkům (jako je Microsoft Graph, KeyVault, Outlook API a další rozhraní API Microsoftu), získají token a předají ho vlastníkovi prostředku. Vzhledem k tomu, že nechrání žádné prostředky, neprověřují token, a proto se nemusí ujistit, že je správně podepsaný.

Webové aplikace a webová rozhraní API, které k vyžádání tokenů spadají do této kategorie a které používají tok jen pro aplikaci (přihlašovací údaje klienta nebo klientský certifikát), a proto to nemá vliv na vrácení.

Webové aplikace / rozhraní API chrání prostředky a vytvářejí se pomocí Aplikace Azure Services

Funkce ověřování / autorizace služby Aplikace Azure (EasyAuth) už má potřebnou logiku pro automatické zpracování přechodu klíčů.

Webové aplikace / rozhraní API chránící prostředky pomocí ASP.NET OWIN OpenID Connect, WS-Fed nebo WindowsAzureActiveDirectoryBearerAuthentication middleware

Pokud vaše aplikace používá middleware ASP.NET OWIN OpenID Connect, WS-Fed nebo WindowsAzureActiveDirectoryBearerAuthentication, už má potřebnou logiku pro automatické zpracování přechodu klíče.

Aplikaci můžete ověřit tak, že hledáte některý z následujících fragmentů kódu v souboru Startup.cs nebo Startup.Auth.cs vaší aplikace.

app.UseOpenIdConnectAuthentication(
    new OpenIdConnectAuthenticationOptions
    {
        // ...
    });

app.UseWsFederationAuthentication(
    new WsFederationAuthenticationOptions
    {
        // ...
    });

app.UseWindowsAzureActiveDirectoryBearerAuthentication(
    new WindowsAzureActiveDirectoryBearerAuthenticationOptions
    {
        // ...
    });

Webové aplikace / rozhraní API chránící prostředky pomocí middlewaru .NET Core OpenID Connect nebo JwtBearerAuthentication

Pokud vaše aplikace používá middleware ASP.NET OWIN OpenID Connect nebo JwtBearerAuthentication, už má potřebnou logiku pro automatické zpracování přechodu klíče.

Pokud chcete ověřit, že vaše aplikace některou z těchto metod používá, vyhledejte v Startup.cs nebo Startup.Auth.cs vaší aplikace některý z následujících fragmentů kódu.

app.UseOpenIdConnectAuthentication(
     new OpenIdConnectAuthenticationOptions
     {
         // ...
     });

app.UseJwtBearerAuthentication(
    new JwtBearerAuthenticationOptions
    {
     // ...
     });

Webové aplikace / rozhraní API chránící prostředky pomocí modulu Node.js passport-azure-ad

Pokud vaše aplikace používá modul Node.js passport-ad, už má potřebnou logiku pro automatické zpracování přechodu klíče.

Potvrzení, že vaše aplikace passport-ad vyhledá následující fragment kódu v app.js vaší aplikace

var OIDCStrategy = require('passport-azure-ad').OIDCStrategy;

passport.use(new OIDCStrategy({
    //...
));

Webové aplikace / rozhraní API chránící prostředky a vytvořené pomocí sady Visual Studio 2015 nebo novější

Pokud byla vaše aplikace vytvořena pomocí šablony webové aplikace v sadě Visual Studio 2015 nebo novější a v nabídce Změnit ověřování jste vybrali pracovní nebo školní účty, už má potřebnou logiku pro automatické zpracování přechodu klíče. Tato logika vložená do middlewaru OWIN OpenID Connect, načte a ukládá klíče do mezipaměti z dokumentu zjišťování OpenID Connect a pravidelně je aktualizuje.

Pokud jste do řešení přidali ověřování ručně, vaše aplikace nemusí mít potřebnou logiku přechodu klíče. Můžete ho napsat sami, nebo postupovat podle kroků ve webových aplikacích nebo rozhraních API pomocí jakékoli jiné knihovny nebo ručně implementovat některý z podporovaných protokolů.

Webové aplikace chrání prostředky a vytvářejí se pomocí sady Visual Studio 2013

Pokud byla vaše aplikace vytvořena pomocí šablony webové aplikace v sadě Visual Studio 2013 a v nabídce Změnit ověřování jste vybrali organizační účty, už má potřebnou logiku pro automatické zpracování přechodu klíče. Tato logika ukládá jedinečný identifikátor vaší organizace a informace o podpisovém klíči do dvou databázových tabulek přidružených k projektu. Připojovací řetězec pro databázi najdete v souboru Web.config projektu.

Pokud jste do řešení přidali ověřování ručně, vaše aplikace nemusí mít potřebnou logiku přechodu klíče. Musíte ho napsat sami, nebo postupovat podle kroků ve webových aplikacích nebo rozhraních API pomocí jakékoli jiné knihovny nebo ručně implementovat některý z podporovaných protokolů.

Následující kroky vám pomůžou ověřit, že logika ve vaší aplikaci funguje správně.

1. V sadě Visual Studio 2013 otevřete řešení a v pravém okně vyberte na kartě Průzkumník serveru.
2. Rozbalte datová připojení, DefaultConnection a potom tabulky. Vyhledejte tabulku IssuingAuthorityKeys, klikněte na ni pravým tlačítkem myši a pak vyberte Zobrazit data tabulky.
3. V tabulce IssuingAuthorityKeys bude alespoň jeden řádek, který odpovídá hodnotě kryptografického otisku klíče. Odstraňte všechny řádky v tabulce.
4. Klikněte pravým tlačítkem myši na tabulku Tenants a pak vyberte Zobrazit data tabulky.
5. V tabulce Tenants (Tenants) bude alespoň jeden řádek, který odpovídá jedinečnému identifikátoru tenanta adresáře. Odstraňte všechny řádky v tabulce. Pokud neodstraníte řádky v tabulce Tenants i v tabulce IssuingAuthorityKeys , zobrazí se za běhu chyba.
6. Sestavte a spusťte aplikaci. Po přihlášení ke svému účtu můžete aplikaci zastavit.
7. Vraťte se do Průzkumníka serveru a podívejte se na hodnoty v tabulce IssuingAuthorityKeys a Tenants. Všimněte si, že se automaticky znovu vyplní příslušnými informacemi z dokumentu federačních metadat.

Webová rozhraní API chrání prostředky a vytvářejí se pomocí sady Visual Studio 2013

Pokud jste vytvořili aplikaci webového rozhraní API v sadě Visual Studio 2013 pomocí šablony webového rozhraní API a poté jste v nabídce Změnit ověřování vybrali účty organizace, už máte ve své aplikaci potřebnou logiku.

Pokud jste ručně nakonfigurovali ověřování, postupujte podle následujících pokynů a zjistěte, jak nakonfigurovat webové rozhraní API tak, aby automaticky aktualizovalo informace o jeho klíči.

Následující fragment kódu ukazuje, jak získat nejnovější klíče z dokumentu federačních metadat a pak pomocí obslužné rutiny tokenu JWT ověřit token. Fragment kódu předpokládá, že použijete vlastní mechanismus ukládání do mezipaměti pro zachování klíče k ověření budoucích tokenů z platformy Microsoft Identity Platform, ať už v databázi, konfiguračním souboru nebo jinde.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.IdentityModel.Tokens;
using System.Configuration;
using System.Security.Cryptography.X509Certificates;
using System.Xml;
using System.IdentityModel.Metadata;
using System.ServiceModel.Security;
using System.Threading;

namespace JWTValidation
{
    public class JWTValidator
    {
        private string MetadataAddress = "[Your Federation Metadata document address goes here]";

        // Validates the JWT Token that's part of the Authorization header in an HTTP request.
        public void ValidateJwtToken(string token)
        {
            JwtSecurityTokenHandler tokenHandler = new JwtSecurityTokenHandler()
            {
                // Do not disable for production code
                CertificateValidator = X509CertificateValidator.None
            };

            TokenValidationParameters validationParams = new TokenValidationParameters()
            {
                AllowedAudience = "[Your App ID URI goes here]",
                ValidIssuer = "[The issuer for the token goes here, such as https://sts.windows.net/aaaabbbb-0000-cccc-1111-dddd2222eeee/]",
                SigningTokens = GetSigningCertificates(MetadataAddress)

                // Cache the signing tokens by your desired mechanism
            };

            Thread.CurrentPrincipal = tokenHandler.ValidateToken(token, validationParams);
        }

        // Returns a list of certificates from the specified metadata document.
        public List<X509SecurityToken> GetSigningCertificates(string metadataAddress)
        {
            List<X509SecurityToken> tokens = new List<X509SecurityToken>();

            if (metadataAddress == null)
            {
                throw new ArgumentNullException(metadataAddress);
            }

            using (XmlReader metadataReader = XmlReader.Create(metadataAddress))
            {
                MetadataSerializer serializer = new MetadataSerializer()
                {
                    // Do not disable for production code
                    CertificateValidationMode = X509CertificateValidationMode.None
                };

                EntityDescriptor metadata = serializer.ReadMetadata(metadataReader) as EntityDescriptor;

                if (metadata != null)
                {
                    SecurityTokenServiceDescriptor stsd = metadata.RoleDescriptors.OfType<SecurityTokenServiceDescriptor>().First();

                    if (stsd != null)
                    {
                        IEnumerable<X509RawDataKeyIdentifierClause> x509DataClauses = stsd.Keys.Where(key => key.KeyInfo != null && (key.Use == KeyType.Signing || key.Use == KeyType.Unspecified)).
                                                             Select(key => key.KeyInfo.OfType<X509RawDataKeyIdentifierClause>().First());

                        tokens.AddRange(x509DataClauses.Select(token => new X509SecurityToken(new X509Certificate2(token.GetX509RawData()))));
                    }
                    else
                    {
                        throw new InvalidOperationException("There is no RoleDescriptor of type SecurityTokenServiceType in the metadata");
                    }
                }
                else
                {
                    throw new Exception("Invalid Federation Metadata document");
                }
            }
            return tokens;
        }
    }
}

Webové aplikace chrání prostředky a vytvořené pomocí sady Visual Studio 2012

Pokud byla vaše aplikace vytvořená v sadě Visual Studio 2012, pravděpodobně jste ke konfiguraci aplikace použili nástroj Identity and Access Tool. Je také pravděpodobné, že používáte registr vinR (Validating Issuer Name Registry). VinR zodpovídá za údržbu informací o důvěryhodných zprostředkovatelích identit (Microsoft Identity Platform) a klíčích používaných k ověření tokenů vydaných nimi. VinR také usnadňuje automatickou aktualizaci klíčových informací uložených v souboru Web.config stažením nejnovějšího dokumentu federačních metadat přidružených k vašemu adresáři, kontrolou, jestli konfigurace není aktuální s nejnovějším dokumentem, a podle potřeby aktualizuje aplikaci tak, aby používala nový klíč.

Pokud jste aplikaci vytvořili pomocí některé z ukázek kódu nebo dokumentace návodu od Microsoftu, logika přechodu klíčů je už součástí vašeho projektu. Všimněte si, že následující kód už v projektu existuje. Pokud vaše aplikace tuto logiku ještě nemá, přidejte ji podle následujících kroků a ověřte, že funguje správně.

1. V Průzkumník řešení přidejte odkaz na sestavení System.IdentityModel pro příslušný projekt.
2. Otevřete soubor Global.asax.cs a přidejte následující direktivy using:

   using System.Configuration;
   using System.IdentityModel.Tokens;
   

3. Do souboru Global.asax.cs přidejte následující metodu:

   protected void RefreshValidationSettings()
   {
    string configPath = AppDomain.CurrentDomain.BaseDirectory + "\\" + "Web.config";
    string metadataAddress =
                  ConfigurationManager.AppSettings["ida:FederationMetadataLocation"];
    ValidatingIssuerNameRegistry.WriteToConfig(metadataAddress, configPath);
   }
   

4. Vyvoláním metody RefreshValidationSettings() v metodě Application_Start() v Global.asax.cs, jak je znázorněno:

   protected void Application_Start()
   {
    AreaRegistration.RegisterAllAreas();
    ...
    RefreshValidationSettings();
   }
   

Po provedení těchto kroků se soubor Web.config vaší aplikace aktualizuje nejnovějšími informacemi z dokumentu federačních metadat, včetně nejnovějších klíčů. K této aktualizaci dojde pokaždé, když váš fond aplikací recykluje ve službě IIS; Ve výchozím nastavení je služba IIS nastavená na recyklaci aplikací každých 29 hodin.

Pomocí následujícího postupu ověřte, že funguje logika přechodu klíče.

1. Po ověření, že vaše aplikace používá výše uvedený kód, otevřete soubor Web.config a přejděte do< bloku issuerNameRegistry>, konkrétně hledáte následující řádky:

   <issuerNameRegistry type="System.IdentityModel.Tokens.ValidatingIssuerNameRegistry, System.IdentityModel.Tokens.ValidatingIssuerNameRegistry">
        <authority name="https://sts.windows.net/aaaabbbb-0000-cccc-1111-dddd2222eeee/">
          <keys>
            <add thumbprint="AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00" />
          </keys>
   

2. <V nastavení add thumbprint=""> změňte hodnotu kryptografického otisku nahrazením libovolného znaku jiným znakem. Uložte soubor Web.config.
3. Sestavte aplikaci a spusťte ji. Pokud můžete dokončit proces přihlášení, vaše aplikace úspěšně aktualizuje klíč stažením požadovaných informací z dokumentu federačních metadat vašeho adresáře. Pokud máte problémy s přihlášením, ujistěte se, že jsou změny ve vaší aplikaci správné, a to tak, že si přečtete článek Přidání přihlášení k webové aplikaci pomocí platformy Microsoft Identity Platform nebo stáhnete a zkontrolujete následující ukázku kódu: Víceklientová cloudová aplikace pro Microsoft Entra ID.

Webové aplikace / rozhraní API chrání prostředky pomocí jakékoli jiné knihovny nebo ručně implementují některý z podporovaných protokolů.

Pokud používáte jinou knihovnu nebo ručně implementujete některý z podporovaných protokolů, budete muset zkontrolovat knihovnu nebo implementaci, abyste měli jistotu, že se klíč načítá z dokumentu zjišťování OpenID Connect nebo z dokumentu federačních metadat. Jedním ze způsobů, jak to zjistit, je provést vyhledávání v kódu nebo v kódu knihovny pro všechna volání dokumentu zjišťování OpenID nebo dokumentu federačních metadat.

Pokud je klíč uložený někde nebo pevně zakódovaný v aplikaci, můžete ho ručně načíst a odpovídajícím způsobem aktualizovat provedením ručního přechodu podle pokynů na konci tohoto dokumentu s pokyny. Důrazně doporučujeme, abyste svou aplikaci vylepšili tak, aby podporovala automatické převrácení pomocí některého z přístupů uvedených v tomto článku, abyste se vyhnuli budoucím přerušením a režijním nákladům, pokud platforma Microsoft Identity Platform zvýší četnost přechodu na jinou verzi nebo má nouzové zrušení mimo pásmo.

Jak otestovat aplikaci, abyste zjistili, jestli bude ovlivněná

Pomocí následujících skriptů PowerShellu můžete ověřit, jestli vaše aplikace podporuje automatické převrácení klíčů.

Pokud chcete zkontrolovat a aktualizovat podpisové klíče pomocí PowerShellu, budete potřebovat modul MSIdentityTools PowerShell.

1. Nainstalujte modul POWERShellu MSIdentityTools:

   Install-Module -Name MSIdentityTools
   

2. Přihlaste se pomocí příkazu Connect-MgGraph s účtem správce, abyste udělili souhlas s požadovanými obory:

    Connect-MgGraph -Scope "Application.ReadWrite.All"
   

3. Získejte seznam dostupných kryptografických otisků podpisového klíče:

   Get-MsIdSigningKeyThumbprint
   

4. Vyberte některý z kryptografických otisků klíčů a nakonfigurujte ID Microsoft Entra tak, aby tento klíč používal s vaší aplikací (získejte ID aplikace z Centra pro správu Microsoft Entra):

   Update-MsIdApplicationSigningKeyThumbprint -ApplicationId <ApplicationId> -KeyThumbprint <Thumbprint>
   

5. Otestujte webovou aplikaci přihlášením, abyste získali nový token. Změna aktualizace klíče je okamžitá, ale ujistěte se, že používáte novou relaci prohlížeče (například Internet Explorer InPrivate, Chrome v anonymním režimu nebo privátní režim Firefoxu), abyste měli jistotu, že jste vystavil nový token.

6. Pro každý z vrácených kryptografických otisků podpisového klíče spusťte rutinu Update-MsIdApplicationSigningKeyThumbprint a otestujte proces přihlášení k webové aplikaci.

7. Pokud se webová aplikace správně přihlásí, podporuje automatické převrácení. Pokud tomu tak není, upravte aplikaci tak, aby podporovala ruční vrácení. Další informace najdete v části Vytvoření ručního procesu přechodu.

8. Spuštěním následujícího skriptu se vraťte k normálnímu chování:

   Update-MsIdApplicationSigningKeyThumbprint -ApplicationId <ApplicationId> -Default
   

Postup ručního přechodu, pokud vaše aplikace nepodporuje automatické převrácení

Pokud vaše aplikace nepodporuje automatické převrácení, musíte vytvořit proces, který pravidelně monitoruje podpisové klíče platformy Microsoft Identity Platform a odpovídajícím způsobem provádí ruční převrácení.

Pokud chcete zkontrolovat a aktualizovat podpisové klíče pomocí PowerShellu MSIdentityTools , potřebujete modul PowerShellu.

1. Nainstalujte modul PowerShellu MSIdentityTools :

   Install-Module -Name MSIdentityTools
   

2. Získejte nejnovější podpisový klíč (získejte ID tenanta z Centra pro správu Microsoft Entra):

   Get-MsIdSigningKeyThumbprint -Tenant <tenandId> -Latest
   

3. Porovnejte tento klíč s klíčem, který je aktuálně pevně zakódovaný nebo nakonfigurovaný pro použití vaší aplikace.

4. Pokud se nejnovější klíč liší od klíče, který vaše aplikace používá, stáhněte si nejnovější podpisový klíč:

   Get-MsIdSigningKeyThumbprint -Latest -DownloadPath <DownloadFolderPath>
   

5. Aktualizujte kód nebo konfiguraci aplikace tak, aby používaly nový klíč.

6. Nakonfigurujte ID Microsoft Entra tak, aby používalo tento nejnovější klíč s vaší aplikací (získejte ID aplikace z Centra pro správu Microsoft Entra):

   Get-MsIdSigningKeyThumbprint -Latest | Update-MsIdApplicationSigningKeyThumbprint -ApplicationId <ApplicationId>
   

7. Otestujte webovou aplikaci přihlášením, abyste získali nový token. Změna aktualizace klíče je okamžitá, ale ujistěte se, že používáte novou relaci prohlížeče, abyste měli jistotu, že jste vydali nový token. Použijte například "InPrivate" v Prohlížeči Microsoft Edge, Chrome režim Incognito nebo Privátní režim Firefoxu.

8. Pokud dojde k nějakým problémům, vraťte se k předchozímu klíči, který jste používali, a kontaktujte podpora Azure:

   Update-MsIdApplicationSigningKeyThumbprint -ApplicationId <ApplicationId> -KeyThumbprint <PreviousKeyThumbprint>
   

9. Po aktualizaci aplikace na podporu ručního přechodu se vraťte k normálnímu chování:

   Update-MsIdApplicationSigningKeyThumbprint -ApplicationId <ApplicationId> -Default