Aláírókulcs-váltás a Microsoft Identitásplatform

Cikk
10/30/2024

Ez a cikk ismerteti, mit kell tudnia a biztonsági jogkivonatok aláírásához használt nyilvános kulcsokról, amelyeket a Microsoft Identitásplatform használ. Fontos megjegyezni, hogy ezek a kulcsok rendszeres időközönként átgördülnek, és vészhelyzet esetén azonnal átgördülhetnek. A Microsoft Identitásplatform használó összes alkalmazásnak képesnek kell lennie programozott módon kezelni a kulcsátállítási folyamatot. Megtudhatja, hogyan működnek a kulcsok, hogyan mérheti fel az alkalmazásra való áttérés hatását. Azt is megtudhatja, hogyan frissítheti az alkalmazást, vagy hogyan hozhat létre rendszeres manuális visszaállítási folyamatot a kulcsátállítás kezeléséhez, ha szükséges.

Az aláírási kulcsok áttekintése a Microsoft Identitásplatform

A Microsoft Identitásplatform iparági szabványokra épülő nyilvános kulcsú titkosítást használ, hogy megbízhatóságot teremtsen saját maga és az azt használó alkalmazások között. Gyakorlati szempontból ez a következőképpen működik: A Microsoft Identitásplatform egy nyilvános és privát kulcspárból álló aláírókulcsot használ. Amikor egy felhasználó bejelentkezik egy olyan alkalmazásba, amely a Microsoft Identitásplatform használja hitelesítésre, a Microsoft Identitásplatform létrehoz egy biztonsági jogkivonatot, amely a felhasználóval kapcsolatos információkat tartalmazza. Ezt a jogkivonatot a Microsoft Identitásplatform a titkos kulcsával írja alá, mielőtt visszaküldené őket az alkalmazásnak. Annak ellenőrzéséhez, hogy a jogkivonat érvényes-e, és Microsoft Identitásplatform származik-e, az alkalmazásnak ellenőriznie kell a jogkivonat aláírását a bérlő OpenID Connect felderítési dokumentumában vagy az SAML/WS-Fed összevonási metaadat-dokumentumban található Microsoft Identitásplatform által közzétett nyilvános kulcsokkal.

Biztonsági okokból a Microsoft Identitásplatform aláírókulcsa rendszeres időközönként forog, vészhelyzet esetén pedig azonnal át lehet gördíteni. A kulcstekercsek között nincs beállított vagy garantált idő. A Microsoft Identitásplatform integrálható alkalmazásoknak készen kell állniuk a kulcsátállítási események kezelésére, függetlenül attól, hogy milyen gyakran fordul elő. Ha az alkalmazás nem kezeli a hirtelen frissítéseket, és lejárt kulccsal próbálja ellenőrizni az aláírást egy jogkivonaton, az alkalmazás helytelenül elutasítja a jogkivonatot. Ajánlott szabványos kódtárakat használni a kulcs metaadatainak megfelelő frissítéséhez és naprakészen tartásához. Ha nem használ standard kódtárakat, győződjön meg arról, hogy az implementáció megfelel az ajánlott eljárások szakaszának.

Az OpenID Connect felderítési dokumentumban és az összevonási metaadat-dokumentumban mindig több érvényes kulcs érhető el. Az alkalmazásnak készen kell állnia a dokumentumban megadott összes kulcs használatára, mivel az egyik kulcs hamarosan begördülhet, egy másik lehet a cseréje, és így tovább. A jelen lévő kulcsok száma az Microsoft Identitásplatform belső architektúrája alapján idővel változhat, mivel új platformokat, új felhőket vagy új hitelesítési protokollokat támogatunk. Sem a JSON-válaszban szereplő kulcsok sorrendje, sem a felfedésük sorrendje nem tekinthető értelmezhetőnek az alkalmazás számára. Ha többet szeretne megtudni a JSON webkulcs adatstruktúrájáról, hivatkozhat RFC7517.

Az olyan alkalmazások, amelyek csak egyetlen aláírókulcsot támogatnak, vagy az aláírókulcsok manuális frissítését igénylő alkalmazások, eleve kevésbé biztonságosak és kevésbé megbízhatóak. Ezeket úgy kell frissíteni, hogy szabványos kódtárakat használjanak, hogy a többi ajánlott eljárás mellett mindig naprakész aláírókulcsokat használjanak.

Ajánlott eljárások a kulcsok metaadatainak gyorsítótárazására és érvényesítésére

Kulcsok felderítése az OpenID Connectben (OIDC) és összevonási metaadatokban leírt bérlőspecifikus végpont használatával
Még ha az alkalmazás több bérlőn is üzembe van helyezve, javasoljuk, hogy mindig egymástól függetlenül felderítse és gyorsítótárazza a kulcsokat az alkalmazás által kiszolgált összes bérlőhöz (a bérlőspecifikus végpont használatával). A bérlőkben ma gyakran használt kulcsok a jövőben különböző bérlőkké válhatnak.
Az alábbi gyorsítótárazási algoritmussal biztosíthatja, hogy a gyorsítótárazás rugalmas és biztonságos legyen

Kulcsok metaadat-gyorsítótárazási algoritmusa:

Standard kódtáraink rugalmas és biztonságos kulcs-gyorsítótárazást valósítanak meg. Javasoljuk, hogy használja őket a megvalósítás apró hibáinak elkerülése érdekében. Az egyéni implementációk esetében a durva algoritmus a következő:

Általános szempontok:

A jogkivonatokat érvényesítő szolgáltatásnak olyan gyorsítótárral kell rendelkeznie, amely képes számos különböző kulcs tárolására (10-1000).
A kulcsokat egyenként kell gyorsítótárazni, az OIDC-kulcsok metaadatainak specifikációjában szereplő kulcsazonosítót ("kid") használva gyorsítótárkulcsként.
A gyorsítótárban lévő kulcsok élettartamát 24 órára kell konfigurálni, és a frissítések óránként történnek. Ez biztosítja, hogy a rendszer gyorsan reagáljon az eltávolított kulcsokra, de elegendő gyorsítótár-időtartamot biztosít ahhoz, hogy a kulcsok beolvasásával kapcsolatos problémák ne befolyásolják.
A kulcsokat frissíteni kell:
- Folyamatindításkor vagy üres gyorsítótár esetén
- Rendszeres időközönként (1 óránként ajánlott) háttérfeladatként
- Dinamikusan, ha egy fogadott jogkivonatot ismeretlen kulccsal írtak alá (ismeretlen gyermek vagy azonosító a fejlécben)

KeyRefresh-eljárás (Az IdentityModel elméleti algoritmusa)

Inicializálás

A konfigurációkezelő egy adott címmel van beállítva a konfigurációs adatok lekéréséhez és az adatok lekéréséhez és érvényesítéséhez szükséges felületekhez.
Konfiguráció ellenőrzése

Az új adatok beolvasása előtt a rendszer először ellenőrzi, hogy a meglévő adatok továbbra is érvényesek-e egy előre meghatározott frissítési időköz alapján.
Adatlekérés Ha az adatok elavultak vagy hiányoznak, a rendszer zárolja, hogy csak egy szál kérje le az új adatokat a duplikáció (és a szálkimerülés) elkerülése érdekében. A rendszer ezután megpróbálja lekérni a legújabb konfigurációs adatokat egy adott végpontról.
Érvényesítés

Az új adatok lekérése után a rendszer ellenőrzi, hogy azok megfelelnek-e a szükséges szabványoknak, és nem sérültek-e. A metaadatok csak akkor fogadhatók el, ha egy bejövő kérés sikeresen érvényesítve lett az új kulcsokkal.
Hibakezelés

Ha bármilyen hiba történik az adatlekérés során, a rendszer naplózza őket. A rendszer továbbra is az utolsó jól ismert konfigurációval működik, ha nem lehet új adatokat beolvasni
Automatikus frissítések A rendszer rendszeres időközönként ellenőrzi és frissíti a konfigurációs adatokat a frissítési időköz alapján (ajánlott 12 óra plusz vagy mínusz 1 óra jitterrel). Szükség esetén manuálisan is kérhet frissítést, biztosítva, hogy az adatok mindig naprakészek legyenek.
Jogkivonat érvényesítése új kulccsal Ha egy token olyan aláíró kulccsal érkezik, amely még nem ismert a konfigurációból, a rendszer egy szinkronizálási hívással kísérli meg lekérni a konfigurációt a gyakori elérési úton, hogy a metaadatok új kulcsait a szokásos várt frissítéseken kívül kezelje (de 5 percnél gyakrabban ne)

Ez a megközelítés biztosítja, hogy a rendszer mindig a legfrissebb és érvényes konfigurációs adatokat használja, miközben a hibák kezelése és a redundáns műveletek elkerülése mellett mindig a legkorszerűbb adatokat használja.

Az algoritmus .NET-implementációja a BaseConfigurationManagerben érhető el. A rugalmasság és a biztonsági értékelések alapján változhat. Lásd még a magyarázatot itt

KeyRefresh eljárás (pszeudokód):

Ez az eljárás globális (lastSuccessfulRefreshTime időbélyeg) használatával megakadályozza a kulcsokat túl gyakran frissítő feltételeket.

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
}

Szolgáltatásindítási eljárás:

KeyRefresh a kulcsok frissítéséhez
Elindít egy háttérfeladatot, amely óránként meghívja a KeyRefresh-t

TokenValidation eljárás a kulcs (pszeudokód) érvényesítéséhez:

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

Annak felmérése, hogy az alkalmazás érintett-e, és mi a teendő vele kapcsolatban

Az, hogy az alkalmazás hogyan kezeli a kulcsátállítást, olyan változóktól függ, mint az alkalmazás típusa vagy az identitásprotokoll és a kódtár. Az alábbi szakaszok felmérik, hogy a kulcsátállítás hatással van-e a leggyakoribb alkalmazástípusokra, és útmutatást nyújt az alkalmazás frissítéséhez az automatikus átállás támogatásához vagy a kulcs manuális frissítéséhez.

Natív ügyfélalkalmazások, amelyek hozzáférnek az erőforrásokhoz
Webalkalmazások / ERŐFORRÁSOKHOZ hozzáférő API-k
Erőforrásokat védő és Azure-alkalmazás Services használatával létrehozott webalkalmazások/ API-k
Az erőforrásokat ASP.NET OWIN OpenID Connect, WS-Fed vagy WindowsAzureActiveDirectoryBearerAuthentication köztes szoftver használatával védő webalkalmazások/ API-k
Az erőforrásokat ASP.NET Core OpenID Connect vagy JwtBearerAuthentication köztes szoftver használatával védő webalkalmazások/ API-k
Webalkalmazások/ API-k az erőforrások védelme Node.js passport-azure-ad modullal
Erőforrásokat védő webalkalmazások/ API-k, amelyeket a Visual Studio 2015 vagy újabb verziójával hoztak létre
Erőforrásokat védő és a Visual Studio 2013-tal létrehozott webalkalmazások
Az erőforrásokat védő és a Visual Studio 2013-tal létrehozott webes API-k
Erőforrásokat védő és a Visual Studio 2012-vel létrehozott webalkalmazások
Webalkalmazások/ API-k, amelyek más kódtárak használatával védik az erőforrásokat, vagy manuálisan implementálják a támogatott protokollokat

Ez az útmutató nem alkalmazható a következő célokra:

A Microsoft Entra alkalmazáskatalógusából hozzáadott alkalmazások (beleértve az Egyénit is) külön útmutatást nyújtanak az aláírási kulcsokkal kapcsolatban. További információ.
Az alkalmazásproxyval közzétett helyszíni alkalmazásoknak nem kell aggódniuk az aláírási kulcsok miatt.

Natív ügyfélalkalmazások, amelyek hozzáférnek az erőforrásokhoz

Azok az alkalmazások, amelyek csak erőforrásokhoz férnek hozzá (például Microsoft Graph, KeyVault, Outlook API és egyéb Microsoft API-k) csak jogkivonatot szereznek be, és továbbítják azt az erőforrás tulajdonosának. Mivel nem védik az erőforrásokat, nem ellenőrzik a jogkivonatot, ezért nem kell meggyőződniük arról, hogy megfelelően aláírták.

Az asztali vagy mobil natív ügyfélalkalmazások ebbe a kategóriába tartoznak, így az átállás nem érinti őket.

Webalkalmazások / ERŐFORRÁSOKHOZ hozzáférő API-k

Ebbe a kategóriába tartoznak azok a webalkalmazások és webes API-k, amelyek csak az alkalmazásfolyamatot (ügyfél hitelesítő adatait/ ügyféltanúsítványát) használják a jogkivonatok lekérésére, ezért az átállás nem érinti őket.

Erőforrásokat védő és Azure-alkalmazás Services használatával létrehozott webalkalmazások/ API-k

Azure-alkalmazás szolgáltatások hitelesítési/engedélyezési (EasyAuth) funkciója már rendelkezik a kulcsátállítás automatikus kezeléséhez szükséges logikával.

Az erőforrásokat ASP.NET OWIN OpenID Connect, WS-Fed vagy WindowsAzureActiveDirectoryBearerAuthentication köztes szoftver használatával védő webalkalmazások/ API-k

Ha az alkalmazás az ASP.NET OWIN OpenID Connect, WS-Fed vagy WindowsAzureActiveDirectoryBearerAuthentication köztes szoftvert használja, már rendelkezik a szükséges logikával a kulcsok automatikus visszaállításának kezeléséhez.

A következő kódrészletek bármelyikének az alkalmazás Startup.cs vagy Startup.Auth.cs fájljában való megtekintésével ellenőrizheti, hogy az alkalmazás ezeket használja-e.

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

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

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

A .NET Core OpenID Connect vagy a JwtBearerAuthentication köztes szoftver használatával védelmet biztosító webalkalmazások/ API-k

Ha az alkalmazás az OWIN OpenID Connect vagy A JwtBearerAuthentication köztes szoftver ASP.NET használja, már rendelkezik a szükséges logikával a kulcsátállítás automatikus kezeléséhez.

A következő kódrészletek bármelyikének az alkalmazás Startup.cs vagy Startup.Auth.cs

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

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

Webalkalmazások/ API-k az erőforrások védelme Node.js `passport-azure-ad` modullal

Ha az alkalmazás a Node.js passport-ad modult használja, már rendelkezik a kulcsátállítás automatikus kezeléséhez szükséges logikával.

Az alkalmazás útlevél-hirdetésének megerősítéséhez keresse meg az alábbi kódrészletet az alkalmazás app.js

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

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

Erőforrásokat védő webalkalmazások/ API-k, amelyeket a Visual Studio 2015 vagy újabb verziójával hoztak létre

Ha az alkalmazás webalkalmazás-sablonnal készült a Visual Studio 2015-ben vagy újabb verziójában, és a Munkahelyi vagy iskolai fiókok lehetőséget választotta a Hitelesítés módosítása menüben, már rendelkezik a kulcsátállítás automatikus kezeléséhez szükséges logikával. Ez az OWIN OpenID Connect köztes szoftverbe ágyazott logika lekéri és gyorsítótárazza a kulcsokat az OpenID Connect felderítési dokumentumból, és rendszeresen frissíti őket.

Ha manuálisan adta hozzá a hitelesítést a megoldáshoz, előfordulhat, hogy az alkalmazás nem rendelkezik a szükséges kulcsátállítási logikával. Megírhatja saját maga, vagy követheti a webalkalmazások/ API-k lépéseit bármely más kódtár használatával, vagy manuálisan implementálhatja bármelyik támogatott protokollt.

Erőforrásokat védő és a Visual Studio 2013-tal létrehozott webalkalmazások

Ha az alkalmazás webalkalmazás-sablonnal készült a Visual Studio 2013-ban, és a Szervezeti fiókok lehetőséget választotta a Változáshitelesítés menüből, már rendelkezik a kulcsátállítás automatikus kezeléséhez szükséges logikával. Ez a logika a szervezet egyedi azonosítóját és aláírókulcs-adatait a projekthez társított két adatbázistáblában tárolja. Az adatbázis kapcsolati sztring a projekt Web.config fájljában található.

Ha manuálisan adta hozzá a hitelesítést a megoldáshoz, előfordulhat, hogy az alkalmazás nem rendelkezik a szükséges kulcsátállítási logikával. Meg kell írnia saját maga, vagy követnie kell a webalkalmazások / API-k lépéseit bármely más kódtár használatával, vagy manuálisan kell implementálnia a támogatott protokollokat.

Az alábbi lépések segítenek ellenőrizni, hogy a logika megfelelően működik-e az alkalmazásban.

A Visual Studio 2013-ban nyissa meg a megoldást, majd válassza a jobb oldali ablak Kiszolgálókezelő lapján.
Bontsa ki az adatkapcsolatokat, a DefaultConnectiont, majd a táblákat. Keresse meg az IssuingAuthorityKeys táblát, kattintson rá a jobb gombbal, majd válassza a Táblaadatok megjelenítése parancsot.
Az IssuingAuthorityKeys táblában legalább egy sor lesz, amely megfelel a kulcs ujjlenyomat-értékének. Törölje a táblázat összes sorát.
Kattintson a jobb gombbal a Bérlők táblára, majd válassza a Táblaadatok megjelenítése parancsot.
A Bérlők táblában legalább egy sor lesz, amely egy egyedi címtár-bérlőazonosítónak felel meg. Törölje a táblázat összes sorát. Ha nem törli a Bérlők és az IssuingAuthorityKeys tábla sorait, futásidőben hibaüzenet jelenik meg.
Hozza létre és futtassa az alkalmazást. Miután bejelentkezett a fiókjába, leállíthatja az alkalmazást.
Térjen vissza a Kiszolgálókezelőbe , és tekintse meg az IssuingAuthorityKeys és a Tenants tábla értékeit. Megfigyelheti, hogy a rendszer automatikusan újra feltölti őket az összevonási metaadat-dokumentum megfelelő információival.

Az erőforrásokat védő és a Visual Studio 2013-tal létrehozott webes API-k

Ha webes API-alkalmazást hozott létre a Visual Studio 2013-ban a Webes API-sablon használatával, majd a Szervezeti fiókok lehetőséget választotta a Hitelesítés módosítása menüből, már rendelkezik a szükséges logikával az alkalmazásban.

Ha manuálisan konfigurálta a hitelesítést, az alábbi utasításokat követve megtudhatja, hogyan konfigurálhatja a webes API-t a kulcsinformációk automatikus frissítéséhez.

Az alábbi kódrészlet bemutatja, hogyan szerezheti be a legújabb kulcsokat az összevonási metaadat-dokumentumból, majd a JWT Token Handler használatával érvényesítheti a jogkivonatot. A kódrészlet feltételezi, hogy a kulcs megőrzéséhez saját gyorsítótárazási mechanizmust fog használni a jövőbeli jogkivonatok ellenőrzéséhez Microsoft Identitásplatform, legyen az adatbázisban, konfigurációs fájlban vagy máshol.

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

Erőforrásokat védő és a Visual Studio 2012-vel létrehozott webalkalmazások

Ha az alkalmazás a Visual Studio 2012-ben készült, valószínűleg az Identitás és az Access eszközzel konfigurálta az alkalmazást. Az is valószínű, hogy a kiállítók névjegyzékét (VINR) használja. A VINR felelős a megbízható identitásszolgáltatókkal (Microsoft Identitásplatform) és az általuk kibocsátott jogkivonatok érvényesítéséhez használt kulcsokkal kapcsolatos információk megőrzéséért. A VINR emellett megkönnyíti a Web.config fájlban tárolt kulcsadatok automatikus frissítését a címtárhoz társított legújabb összevonási metaadat-dokumentum letöltésével, annak ellenőrzésével, hogy a konfiguráció elavult-e a legújabb dokumentummal, és szükség szerint frissíti az alkalmazást az új kulcs használatára.

Ha az alkalmazást a Microsoft által biztosított kódminták vagy útmutató dokumentáció segítségével hozta létre, a kulcsátállítási logika már szerepel a projektben. Láthatja, hogy az alábbi kód már létezik a projektben. Ha az alkalmazás még nem rendelkezik ezzel a logikával, az alábbi lépéseket követve adja hozzá, és ellenőrizze, hogy megfelelően működik-e.

A Megoldáskezelő adjon hozzá egy hivatkozást a System.IdentityModel szerelvényhez a megfelelő projekthez.
Nyissa meg a Global.asax.cs fájlt, és adja hozzá az alábbi irányelveket:
```
using System.Configuration;
using System.IdentityModel.Tokens;
```

Adja hozzá a következő metódust a Global.asax.cs fájlhoz:

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

Hívja meg a RefreshValidationSettings() metódust a Application_Start() metódusban a Global.asax.cs az alábbi módon:
```
protected void Application_Start()
{
 AreaRegistration.RegisterAllAreas();
 ...
 RefreshValidationSettings();
}
```

Miután követte ezeket a lépéseket, az alkalmazás Web.config-konfigurációja frissül az összevonási metaadat-dokumentum legújabb információival, beleértve a legújabb kulcsokat is. Ez a frissítés minden alkalommal megtörténik, amikor az alkalmazáskészlet újrafeldolgozódik az IIS-ben; Alapértelmezés szerint az IIS 29 óránként állítja be az alkalmazások újrahasznosítását.

Kövesse az alábbi lépéseket annak ellenőrzéséhez, hogy a kulcsátállítási logika működik-e.

Miután ellenőrizte, hogy az alkalmazás a fenti kódot használja-e, nyissa meg a Web.config fájlt, és keresse meg a< issuerNameRegistry> blokkot, különösen a következő sorokat keresve:

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

<Az add thumbprint="" (ujjlenyomat hozzáadása)> beállításban módosítsa az ujjlenyomat értékét úgy, hogy bármelyik karaktert lecseréli egy másikra. Mentse a Web.config fájlt.
Hozza létre az alkalmazást, majd futtassa. Ha befejezheti a bejelentkezési folyamatot, az alkalmazás sikeresen frissíti a kulcsot, ha letölti a szükséges információkat a címtár összevonási metaadat-dokumentumából. Ha problémákat tapasztal a bejelentkezés során, győződjön meg arról, hogy az alkalmazás módosításai helyesek. Ehhez olvassa el a Bejelentkezés hozzáadása a webalkalmazáshoz Microsoft Identitásplatform cikk használatával című cikket, vagy töltse le és vizsgálja meg a következő kódmintát: Több-bérlős felhőalkalmazás a Microsoft Entra-azonosítóhoz.

Webalkalmazások/ API-k, amelyek más kódtárak használatával védik az erőforrásokat, vagy manuálisan implementálják a támogatott protokollokat

Ha más kódtárat használ, vagy manuálisan implementálta a támogatott protokollok bármelyikét, át kell tekintenie a tárat vagy az implementációt, hogy a kulcs lekérhető legyen az OpenID Connect felderítési dokumentumából vagy az összevonási metaadat-dokumentumból. Ennek egyik módja, ha keresést hajt végre a kódban vagy a kódtár kódjában az OpenID felderítési dokumentumra vagy az összevonási metaadat-dokumentumra irányuló hívásokra.

Ha a kulcsot valahol vagy az alkalmazásban merevlemezen tárolják, manuálisan lekérheti a kulcsot, és ennek megfelelően frissítheti az útmutató dokumentum végén található utasításoknak megfelelően. Határozottan javasoljuk, hogy bővítse az alkalmazást, hogy támogassa az automatikus átállást a jelen cikkben ismertetett megközelítések bármelyikével, hogy elkerülje a jövőbeli fennakadásokat és többletterhelést, ha a Microsoft Identitásplatform növeli az átállási ütemet, vagy ha sávon kívüli vészhelyzet áll elő.

Az alkalmazás tesztelése annak megállapításához, hogy az érintett-e

Az alábbi PowerShell-szkriptekkel ellenőrizheti, hogy az alkalmazás támogatja-e az automatikus kulcsátállítást.

Az aláírási kulcsok PowerShell-lel való ellenőrzéséhez és frissítéséhez szüksége lesz az MSIdentityTools PowerShell-modulra.

Telepítse az MSIdentityTools PowerShell-modult:
```
Install-Module -Name MSIdentityTools
```
Jelentkezzen be a Connect-MgGraph paranccsal egy rendszergazdai fiókkal, hogy hozzájáruljon a szükséges hatókörökhöz:
```
 Connect-MgGraph -Scope "Application.ReadWrite.All"
```
Kérje le az elérhető aláírókulcs-ujjlenyomatok listáját:
```
Get-MsIdSigningKeyThumbprint
```
Válassza ki a kulcs ujjlenyomatait, és konfigurálja a Microsoft Entra-azonosítót a kulcs alkalmazáshoz való használatára (kérje le az alkalmazásazonosítót a Microsoft Entra felügyeleti központból):
```
Update-MsIdApplicationSigningKeyThumbprint -ApplicationId <ApplicationId> -KeyThumbprint <Thumbprint>
```
Tesztelje a webalkalmazást úgy, hogy bejelentkezik egy új jogkivonat beszerzéséhez. A legfontosabb frissítési módosítás azonnali, de győződjön meg arról, hogy új böngésző-munkamenetet használ (például az Internet Explorer "InPrivate"-jával, a Chrome Inkognitójával vagy a Firefox "Privát" módjával), hogy biztosan új jogkivonatot adjon ki.
Minden visszaadott aláírókulcs-ujjlenyomathoz futtassa a Update-MsIdApplicationSigningKeyThumbprint parancsmagot, és tesztelje a webalkalmazás bejelentkezési folyamatát.
Ha a webalkalmazás megfelelően jelentkezik be, támogatja az automatikus átállást. Ha nem, módosítsa az alkalmazást úgy, hogy támogassa a manuális átállást. További információkért tekintse meg a manuális bevezetési folyamat létrehozását ismertető szakaszt.

Futtassa a következő szkriptet a normál működésre való visszatéréshez:

Update-MsIdApplicationSigningKeyThumbprint -ApplicationId <ApplicationId> -Default

Manuális átállás végrehajtása, ha az alkalmazás nem támogatja az automatikus átállást

Ha az alkalmazás nem támogatja az automatikus átállást, létre kell hoznia egy folyamatot, amely rendszeresen figyeli Microsoft Identitásplatform aláírókulcsait, és ennek megfelelően elvégzi a manuális visszaállítást.

Az aláírási kulcsok PowerShell-lel való ellenőrzéséhez és frissítéséhez a MSIdentityTools PowerShell-modulra van szükség.

Telepítse a MSIdentityTools PowerShell-modult:
```
Install-Module -Name MSIdentityTools
```
Szerezze be a legújabb aláírási kulcsot (kérje le a bérlőazonosítót a Microsoft Entra felügyeleti központból):
```
Get-MsIdSigningKeyThumbprint -Tenant <tenantId> -Latest
```
Hasonlítsa össze ezt a kulcsot az alkalmazás által jelenleg rögzített vagy használatra konfigurált kulccsal.
Ha a legújabb kulcs eltér az alkalmazás által használt kulcstól, töltse le a legújabb aláírási kulcsot:
```
Get-MsIdSigningKeyThumbprint -Latest -DownloadPath <DownloadFolderPath>
```
Frissítse az alkalmazás kódját vagy konfigurációját az új kulcs használatára.
Konfigurálja a Microsoft Entra-azonosítót úgy, hogy a legújabb kulcsot használja az alkalmazással (kérje le az alkalmazásazonosítót a Microsoft Entra felügyeleti központból):
```
Get-MsIdSigningKeyThumbprint -Latest | Update-MsIdApplicationSigningKeyThumbprint -ApplicationId <ApplicationId>
```
Tesztelje a webalkalmazást úgy, hogy bejelentkezik egy új jogkivonat beszerzéséhez. A kulcsfrissítés módosítása azonnali, de győződjön meg arról, hogy új böngésző-munkamenetet használ annak ellenőrzéséhez, hogy új jogkivonatot ad-e ki. Használja például a Microsoft Edge "InPrivate"-ját, a Chrome Inkognitóját vagy a Firefox "Privát" módját.

Ha bármilyen problémát tapasztal, térjen vissza az előző kulcsra, és lépjen kapcsolatba Azure-támogatás:

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

Miután frissítette az alkalmazást a manuális átállás támogatásához, térjen vissza a normál működésre:
```
Update-MsIdApplicationSigningKeyThumbprint -ApplicationId <ApplicationId> -Default
```

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

Aláírókulcs-váltás a Microsoft Identitásplatform

Az aláírási kulcsok áttekintése a Microsoft Identitásplatform

Ajánlott eljárások a kulcsok metaadatainak gyorsítótárazására és érvényesítésére

Kulcsok metaadat-gyorsítótárazási algoritmusa:

Általános szempontok:

KeyRefresh-eljárás (Az IdentityModel elméleti algoritmusa)

KeyRefresh eljárás (pszeudokód):

Szolgáltatásindítási eljárás:

TokenValidation eljárás a kulcs (pszeudokód) érvényesítéséhez:

Annak felmérése, hogy az alkalmazás érintett-e, és mi a teendő vele kapcsolatban

Natív ügyfélalkalmazások, amelyek hozzáférnek az erőforrásokhoz

Webalkalmazások / ERŐFORRÁSOKHOZ hozzáférő API-k

Erőforrásokat védő és Azure-alkalmazás Services használatával létrehozott webalkalmazások/ API-k

Az erőforrásokat ASP.NET OWIN OpenID Connect, WS-Fed vagy WindowsAzureActiveDirectoryBearerAuthentication köztes szoftver használatával védő webalkalmazások/ API-k

A .NET Core OpenID Connect vagy a JwtBearerAuthentication köztes szoftver használatával védelmet biztosító webalkalmazások/ API-k

Webalkalmazások/ API-k az erőforrások védelme Node.js `passport-azure-ad` modullal

Erőforrásokat védő webalkalmazások/ API-k, amelyeket a Visual Studio 2015 vagy újabb verziójával hoztak létre

Erőforrásokat védő és a Visual Studio 2013-tal létrehozott webalkalmazások

Az erőforrásokat védő és a Visual Studio 2013-tal létrehozott webes API-k

Erőforrásokat védő és a Visual Studio 2012-vel létrehozott webalkalmazások

Webalkalmazások/ API-k, amelyek más kódtárak használatával védik az erőforrásokat, vagy manuálisan implementálják a támogatott protokollokat

Az alkalmazás tesztelése annak megállapításához, hogy az érintett-e

Manuális átállás végrehajtása, ha az alkalmazás nem támogatja az automatikus átállást

Visszajelzés

További források

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

Aláírókulcs-váltás a Microsoft Identitásplatform

Az aláírási kulcsok áttekintése a Microsoft Identitásplatform

Ajánlott eljárások a kulcsok metaadatainak gyorsítótárazására és érvényesítésére

Kulcsok metaadat-gyorsítótárazási algoritmusa:

Általános szempontok:

KeyRefresh-eljárás (Az IdentityModel elméleti algoritmusa)

KeyRefresh eljárás (pszeudokód):

Szolgáltatásindítási eljárás:

TokenValidation eljárás a kulcs (pszeudokód) érvényesítéséhez:

Annak felmérése, hogy az alkalmazás érintett-e, és mi a teendő vele kapcsolatban

Natív ügyfélalkalmazások, amelyek hozzáférnek az erőforrásokhoz

Webalkalmazások / ERŐFORRÁSOKHOZ hozzáférő API-k

Erőforrásokat védő és Azure-alkalmazás Services használatával létrehozott webalkalmazások/ API-k

Az erőforrásokat ASP.NET OWIN OpenID Connect, WS-Fed vagy WindowsAzureActiveDirectoryBearerAuthentication köztes szoftver használatával védő webalkalmazások/ API-k

A .NET Core OpenID Connect vagy a JwtBearerAuthentication köztes szoftver használatával védelmet biztosító webalkalmazások/ API-k

Webalkalmazások/ API-k az erőforrások védelme Node.js passport-azure-ad modullal

Erőforrásokat védő webalkalmazások/ API-k, amelyeket a Visual Studio 2015 vagy újabb verziójával hoztak létre

Erőforrásokat védő és a Visual Studio 2013-tal létrehozott webalkalmazások

Az erőforrásokat védő és a Visual Studio 2013-tal létrehozott webes API-k

Erőforrásokat védő és a Visual Studio 2012-vel létrehozott webalkalmazások

Webalkalmazások/ API-k, amelyek más kódtárak használatával védik az erőforrásokat, vagy manuálisan implementálják a támogatott protokollokat

Az alkalmazás tesztelése annak megállapításához, hogy az érintett-e

Manuális átállás végrehajtása, ha az alkalmazás nem támogatja az automatikus átállást

Visszajelzés

További források

Webalkalmazások/ API-k az erőforrások védelme Node.js `passport-azure-ad` modullal