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

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 értékelheti az alkalmazásra való átállás hatását, és hogyan frissítheti az alkalmazást, vagy szükség esetén rendszeres manuális visszaállítási folyamatot hozhat létre a kulcsátállítás kezeléséhez.

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é 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 Csatlakozás felderítési dokumentumában vagy az SAML/WS-Fed Microsoft Identitásplatform által közzétett nyilvános kulcsokkal.összevonási metaadat-dokumentum.

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 meghatározott 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 fordulnak 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 24 óránként ellenőrizni a frissítéseket, a kulcsdokumentum szabályozott (legfeljebb öt percenként) azonnali frissítésével, ha olyan jogkivonatot tapasztal, amely nem érvényesíti az alkalmazás gyorsítótárában lévő kulcsokat.

Az OpenID Csatlakozás 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.

Azok az alkalmazások, amelyek csak egyetlen aláírókulcsot támogatnak, vagy amelyek manuális frissítést igényelnek az aláírókulcsokhoz, 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.

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 Csatlakozás, WS-Fed vagy WindowsAzureActiveDirectoryBearerAuthentication köztes szoftver használatával védő webalkalmazások/ API-k
• Az erőforrásokat ASP.NET Core OpenID Csatlakozás 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

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.

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 Csatlakozás, WS-Fed vagy WindowsAzureActiveDirectoryBearerAuthentication köztes szoftver használatával védő webalkalmazások/ API-k

Ha az alkalmazás az OWIN OpenID ASP.NET Csatlakozás, a WS-Fed vagy a WindowsAzureActiveDirectoryBearerAuthentication köztes szoftvereket 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 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 Csatlakozás vagy JwtBearerAuthentication köztes szoftver használatával védelmet biztosító webalkalmazások/ API-k

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

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 Csatlakozás köztes szoftverbe ágyazott logika lekéri és gyorsítótárazza a kulcsokat az OpenID Csatlakozás 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. Ezt saját maga kell megírnia, 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.

1. A Visual Studio 2013-ban nyissa meg a megoldást, majd válassza a jobb oldali ablak Kiszolgálókezelő lapján.
2. Bontsa ki az Adat Csatlakozás, az Alapértelmezett Csatlakozás ion, majd a Táblák elemet. Keresse meg az IssuingAuthorityKeys táblát, kattintson rá a jobb gombbal, majd válassza a Táblaadatok megjelenítése parancsot.
3. 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.
4. Kattintson a jobb gombbal a Bérlők táblára, majd válassza a Táblaadatok megjelenítése parancsot.
5. 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.
6. Hozza létre és futtassa az alkalmazást. Miután bejelentkezett a fiókjába, leállíthatja az alkalmazást.
7. 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. Megfigyelheti, 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.

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

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

3. 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);
   }
   

4. Hívja meg a RefreshValidation Gépház() metódust a Application_Start() metódusban 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.

1. 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="3A38FA984E8560F19AADC9F86FE9594BB6AD049B" />
          </keys>
   

2. <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.
3. 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, ellenőrizze, hogy az alkalmazás módosításai helyesek-e. 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 Csatlakozás felderítési dokumentumbó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.

1. Telepítse az MSIdentityTools PowerShell-modult:

   Install-Module -Name MSIdentityTools
   

2. Jelentkezzen be a Csatlakozás-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"
   

3. Kérje le az elérhető aláírókulcs-ujjlenyomatok listáját:

   Get-MsIdSigningKeyThumbprint
   

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

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

6. Minden visszaadott aláírókulcs-ujjlenyomathoz futtassa a Update-MsIdApplicationSigningKeyThumbprint parancsmagot, és tesztelje a webalkalmazás bejelentkezési folyamatát.

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

8. 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ó kulcsok PowerShell-lel való ellenőrzéséhez és frissítéséhez szüksége lesz a MSIdentityTools PowerShell-modulra.

1. Telepítse a MSIdentityTools PowerShell-modult:

   Install-Module -Name MSIdentityTools
   

2. 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 <tenandId> -Latest
   

3. Hasonlítsa össze ezt a kulcsot az alkalmazás által jelenleg rögzített vagy használatra konfigurált kulccsal.

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

5. Frissítse az alkalmazás kódját vagy konfigurációját az új kulcs használatára.

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

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

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

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