Rollover för signeringsnyckel i Microsofts identitetsplattform
I den här artikeln beskrivs vad du behöver veta om de offentliga nycklar som används av Microsofts identitetsplattform för att signera säkerhetstoken. Det är viktigt att observera att dessa nycklar rullas över regelbundet och, i en nödsituation, kan rullas över omedelbart. Alla program som använder Microsofts identitetsplattform ska kunna hantera nyckelåterställningen programmatiskt. Du kommer att förstå hur nycklarna fungerar, hur du utvärderar effekten av övergången till ditt program. Du får också lära dig hur du uppdaterar ditt program eller upprättar en periodisk manuell rollover-process för att hantera nyckelåterställning om det behövs.
Översikt över signeringsnycklar i Microsofts identitetsplattform
Microsofts identitetsplattform använder kryptering med offentlig nyckel som bygger på branschstandarder för att upprätta förtroende mellan sig själv och de program som använder den. I praktiken fungerar detta på följande sätt: Microsofts identitetsplattform använder en signeringsnyckel som består av ett offentligt och privat nyckelpar. När en användare loggar in på ett program som använder Microsofts identitetsplattform för autentisering skapar Microsofts identitetsplattform en säkerhetstoken som innehåller information om användaren. Den här token signeras av Microsofts identitetsplattform med dess privata nyckel innan den skickas tillbaka till programmet. För att verifiera att token är giltig och kommer från Microsofts identitetsplattform måste programmet verifiera tokens signatur med hjälp av de offentliga nycklar som exponeras av Microsofts identitetsplattform som finns i klientorganisationens OpenID Connect-identifieringsdokument eller SAML/WS-Fed federationsmetadatadokument.
I säkerhetssyfte rullar Microsofts identitetsplattform signeringsnyckeln regelbundet och, i händelse av en nödsituation, kan rullas över omedelbart. Det finns ingen angiven eller garanterad tid mellan dessa nyckelvalsar. Alla program som integreras med Microsofts identitetsplattform bör vara beredda att hantera en nyckelåterställningshändelse oavsett hur ofta den kan inträffa. Om programmet inte hanterar plötsliga uppdateringar och försöker använda en nyckel som har upphört att gälla för att verifiera signaturen på en token avvisar programmet token felaktigt. Vi rekommenderar att du använder standardbibliotek för att säkerställa att viktiga metadata uppdateras korrekt och hålls uppdaterade. I de fall där standardbibliotek inte används kontrollerar du att implementeringen följer avsnittet metodtips .
Det finns alltid fler än en giltig nyckel i OpenID Connect-identifieringsdokumentet och federationsmetadatadokumentet. Ditt program bör vara redo att använda alla nycklar som anges i dokumentet, eftersom en nyckel kan rullas snart, en annan kan vara dess ersättning och så vidare. Antalet nycklar som finns kan ändras över tid baserat på den interna arkitekturen för Microsofts identitetsplattform eftersom vi stöder nya plattformar, nya moln eller nya autentiseringsprotokoll. Varken ordningen på nycklarna i JSON-svaret eller i vilken ordning de exponerades bör betraktas som meningsfulla för ditt program. Om du vill veta mer om JSON Web Key-datastrukturen kan du referera till RFC7517.
Program som endast stöder en enda signeringsnyckel, eller program som kräver manuella uppdateringar av signeringsnycklarna, är i sig mindre säkra och mindre tillförlitliga. De bör uppdateras för att använda standardbibliotek för att säkerställa att de alltid använder uppdaterade signeringsnycklar, bland andra metodtips.
Metodtips för cachelagring och validering av nycklar för metadata
- Identifiera nycklar med den klientspecifika slutpunkten enligt beskrivningen i OpenID Connect (OIDC) och federationsmetadata
- Även om ditt program distribueras mellan flera klienter rekommenderar vi att du alltid identifierar och cachelagrar nycklar oberoende av varandra för varje klientorganisation som programmet hanterar (med hjälp av den klientspecifika slutpunkten). En nyckel som är gemensam för klienter i dag kan bli distinkt mellan klienter i framtiden.
- Använd cachelagringsalgoritmen nedan för att säkerställa att cachelagringen är elastisk och säker
Cachelagringsalgoritm för nycklar:
Våra standardbibliotek implementerar elastisk och säker cachelagring av nycklar. Vi rekommenderar att du använder dem för att undvika subtila defekter i implementeringen. Här är den grova algoritmen för anpassade implementeringar:
Allmänna överväganden:
- Tjänsten som validerar token bör ha en cache som kan lagra många distinkta nycklar (10–1 000).
- Nycklarna ska cachelagras individuellt med hjälp av nyckel-ID :t ("kid" i metadataspecifikationen för OIDC-nycklar) som en cachenyckel.
- Time-to-live-nycklar i cacheminnet ska konfigureras till 24 timmar, med uppdateringar som sker varje timme. Detta säkerställer att systemet kan svara snabbt på nycklar som tas bort, men har tillräckligt med cachevaraktighet för att inte påverkas av problem med att hämta nycklar.
- Nycklarna ska uppdateras:
- När processen startas eller när cacheminnet är tomt
- Regelbundet (rekommenderas var 1 timme) som ett bakgrundsjobb
- Dynamiskt om en mottagen token signerades med en okänd nyckel (okänd unge eller tid i huvudet)
KeyRefresh-procedur (konceptalgoritm från IdentityModel)
Initiering
Konfigurationshanteraren har konfigurerats med en specifik adress för att hämta konfigurationsdata och nödvändiga gränssnitt för att hämta och verifiera dessa data.
Konfigurationskontroll
Innan du hämtar nya data kontrollerar systemet först om befintliga data fortfarande är giltiga baserat på ett fördefinierat uppdateringsintervall.
Datahämtning Om data är inaktuella eller saknas låses systemet för att säkerställa att endast en tråd hämtar nya data för att undvika duplicering (och trådöverbelastning). Systemet försöker sedan hämta de senaste konfigurationsdata från en angiven slutpunkt.
Validering
När de nya data hämtas verifieras de för att säkerställa att de uppfyller de standarder som krävs och inte är skadade. Metadata accepteras endast när en inkommande begäran har verifierats med de nya nycklarna.
Felhantering
Om det uppstår fel under datahämtningen loggas de. Systemet fortsätter att fungera med den senast kända bra konfigurationen om nya data inte kan hämtas
Automatiska uppdateringar Systemet kontrollerar och uppdaterar konfigurationsdata automatiskt baserat på uppdateringsintervallet (rekommenderar 12 h med ett jitter på plus eller minus 1 h). Den kan också begära en uppdatering manuellt om det behövs, vilket säkerställer att data alltid är aktuella.
Validering av en token med en ny nyckel Om en token kommer med en signeringsnyckel som ännu inte är känd från konfigurationen försöker systemet hämta konfigurationen med ett synkroniseringsanrop på den frekventa sökvägen för att hantera nya nycklar i metadata utanför de vanliga förväntade uppdateringarna (men inte oftare än 5 minuter)
Den här metoden säkerställer att systemet alltid använder de senaste och mest giltiga konfigurationsdata, samtidigt som fel hanteras korrekt och redundanta åtgärder undviks.
.NET-implementeringen av den här algoritmen är tillgänglig från BaseConfigurationManager. Det kan komma att ändras baserat på motståndskraft och säkerhetsutvärderingar. Se även en förklaring här
KeyRefresh-procedur (pseudokod):
Den här proceduren använder en global (lastSuccessfulRefreshTime-tidsstämpel) för att förhindra villkor som uppdaterar nycklar för ofta.
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
}
Startprocedur för tjänsten:
- KeyRefresh för att uppdatera nycklarna
- Starta ett bakgrundsjobb som anropar KeyRefresh varje timme
TokenValidation-procedur för validering av nyckeln (pseudokod):
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
}
}
}
Så här utvärderar du om ditt program kommer att påverkas och vad du ska göra åt det
Hur ditt program hanterar nyckelåterställning beror på variabler som typ av program eller vilket identitetsprotokoll och bibliotek som användes. I avsnitten nedan utvärderas om de vanligaste typerna av program påverkas av nyckelåterställning och ger vägledning om hur du uppdaterar programmet för att stödja automatisk återställning eller manuellt uppdatera nyckeln.
- Interna klientprogram som har åtkomst till resurser
- Webbprogram/API:er som har åtkomst till resurser
- Webbprogram/API:er som skyddar resurser och skapas med Hjälp av Azure App Services
- Webbprogram/API:er som skyddar resurser med hjälp av ASP.NET OWIN OpenID Connect, WS-Fed eller WindowsAzureActiveDirectoryBearerAuthentication mellanprogram
- Webbprogram/API:er som skyddar resurser med ASP.NET Core OpenID Connect eller JwtBearerAuthentication mellanprogram
- Webbprogram/API:er som skyddar resurser med hjälp av Node.js
passport-azure-admodul - Webbprogram/API:er som skyddar resurser och skapas med Visual Studio 2015 eller senare
- Webbprogram som skyddar resurser och skapas med Visual Studio 2013
- Webb-API:er som skyddar resurser och skapas med Visual Studio 2013
- Webbprogram som skyddar resurser och skapas med Visual Studio 2012
- Webbprogram/API:er som skyddar resurser med andra bibliotek eller implementerar något av protokollen som stöds manuellt
Den här vägledningen gäller inte för:
- Program som lagts till från Microsoft Entra-programgalleriet (inklusive Anpassad) har separat vägledning om signeringsnycklar. Mer information.
- Lokala program som publiceras via programproxy behöver inte bekymra sig om signeringsnycklar.
Interna klientprogram som har åtkomst till resurser
Program som bara har åtkomst till resurser (till exempel Microsoft Graph, KeyVault, Outlook API och andra Microsoft-API:er) hämtar bara en token och skickar den vidare till resursägaren. Eftersom de inte skyddar några resurser inspekterar de inte token och behöver därför inte se till att den är korrekt signerad.
Interna klientprogram, oavsett om de är stationära eller mobila, tillhör den här kategorin och påverkas därför inte av övergången.
Webbprogram/API:er som har åtkomst till resurser
Program som endast har åtkomst till resurser (till exempel Microsoft Graph, KeyVault, Outlook API och andra Microsoft-API:er) hämtar bara en token och skickar den vidare till resursägaren. Eftersom de inte skyddar några resurser inspekterar de inte token och behöver därför inte se till att den är korrekt signerad.
Webbprogram och webb-API:er som använder flödet endast för appar (klientautentiseringsuppgifter/klientcertifikat) för att begära token ingår i den här kategorin och påverkas därför inte av övergången.
Webbprogram/API:er som skyddar resurser och skapas med Hjälp av Azure App Services
Funktionerna för autentisering/auktorisering i Azure App Services (EasyAuth) har redan den logik som krävs för att hantera nyckelåterställning automatiskt.
Webbprogram/API:er som skyddar resurser med hjälp av ASP.NET OWIN OpenID Connect, WS-Fed eller WindowsAzureActiveDirectoryBearerAuthentication mellanprogram
Om ditt program använder mellanprogrammet ASP.NET OWIN OpenID Connect, WS-Fed eller WindowsAzureActiveDirectoryBearerAuthentication har det redan den logik som krävs för att hantera nyckelåterställning automatiskt.
Du kan bekräfta att ditt program använder något av dessa genom att leta efter något av följande kodfragment i programmets Startup.cs- eller Startup.Auth.cs-filer.
app.UseOpenIdConnectAuthentication(
new OpenIdConnectAuthenticationOptions
{
// ...
});
app.UseWsFederationAuthentication(
new WsFederationAuthenticationOptions
{
// ...
});
app.UseWindowsAzureActiveDirectoryBearerAuthentication(
new WindowsAzureActiveDirectoryBearerAuthenticationOptions
{
// ...
});
Webbprogram/API:er som skyddar resurser med hjälp av .NET Core OpenID Connect eller JwtBearerAuthentication mellanprogram
Om programmet använder mellanprogrammet ASP.NET OWIN OpenID Connect eller JwtBearerAuthentication har det redan den logik som krävs för att hantera nyckelåterställning automatiskt.
Du kan bekräfta att programmet använder något av dessa genom att leta efter något av följande kodavsnitt i programmets Startup.cs eller Startup.Auth.cs
app.UseOpenIdConnectAuthentication(
new OpenIdConnectAuthenticationOptions
{
// ...
});
app.UseJwtBearerAuthentication(
new JwtBearerAuthenticationOptions
{
// ...
});
Webbprogram/API:er som skyddar resurser med hjälp av modulen Node.js passport-azure-ad
Om ditt program använder modulen Node.js passport-ad har det redan den logik som krävs för att hantera nyckelåterställning automatiskt.
Du kan bekräfta att ditt program passport-ad genom att söka efter följande kodfragment i programmets app.js
var OIDCStrategy = require('passport-azure-ad').OIDCStrategy;
passport.use(new OIDCStrategy({
//...
));
Webbprogram/API:er som skyddar resurser och skapas med Visual Studio 2015 eller senare
Om ditt program skapades med hjälp av en webbprogrammall i Visual Studio 2015 eller senare och du valde Arbets- eller skolkonton från menyn Ändra autentisering har det redan den logik som krävs för att hantera nyckelåterställning automatiskt. Den här logiken, inbäddad i OWIN OpenID Connect-mellanprogrammet, hämtar och cachelagrar nycklarna från OpenID Connect-identifieringsdokumentet och uppdaterar dem regelbundet.
Om du har lagt till autentisering i lösningen manuellt kanske programmet inte har den nödvändiga logiken för nyckelåterställning. Du kan skriva det själv eller följa stegen i webbprogram/API:er med hjälp av andra bibliotek eller manuellt implementera något av de protokoll som stöds.
Webbprogram som skyddar resurser och skapas med Visual Studio 2013
Om ditt program skapades med hjälp av en webbprogrammall i Visual Studio 2013 och du valde Organisationskonton på menyn Ändra autentisering har det redan den logik som krävs för att hantera nyckelåterställning automatiskt. Den här logiken lagrar organisationens unika identifierare och signeringsnyckelinformationen i två databastabeller som är associerade med projektet. Du hittar anslutningssträng för databasen i projektets Web.config-fil.
Om du har lagt till autentisering i lösningen manuellt kanske programmet inte har den nödvändiga logiken för nyckelåterställning. Du måste skriva det själv eller följa stegen i webbprogram/API:er med hjälp av andra bibliotek eller manuellt implementera något av de protokoll som stöds..
Följande steg hjälper dig att kontrollera att logiken fungerar korrekt i ditt program.
- Öppna lösningen i Visual Studio 2013 och välj sedan på fliken Serverutforskaren i det högra fönstret.
- Expandera Dataanslutningar, DefaultConnection och sedan Tabeller. Leta upp tabellen IssuingAuthorityKeys, högerklicka på den och välj sedan Visa tabelldata.
- I tabellen IssuingAuthorityKeys finns det minst en rad, vilket motsvarar tumavtrycksvärdet för nyckeln. Ta bort alla rader i tabellen.
- Högerklicka på tabellen Klientorganisationer och välj sedan Visa tabelldata.
- I tabellen Klientorganisationer finns det minst en rad, vilket motsvarar en unik katalogklientidentifierare. Ta bort alla rader i tabellen. Om du inte tar bort raderna i både tabellen Klientorganisationer och tabellen IssuingAuthorityKeys får du ett fel vid körning.
- Skapa och kör programmet. När du har loggat in på ditt konto kan du stoppa programmet.
- Gå tillbaka till Server Explorer och titta på värdena i tabellen UtfärdandeAuthorityKeys och Klientorganisationer . Du kommer att märka att de fylls i automatiskt med lämplig information från dokumentet med federationsmetadata.
Webb-API:er som skyddar resurser och skapas med Visual Studio 2013
Om du skapade ett webb-API-program i Visual Studio 2013 med hjälp av webb-API-mallen och sedan valde Organisationskonton på menyn Ändra autentisering har du redan den logik som krävs i ditt program.
Om du har konfigurerat autentisering manuellt följer du anvisningarna nedan för att lära dig hur du konfigurerar webb-API:et för att automatiskt uppdatera dess nyckelinformation.
Följande kodfragment visar hur du hämtar de senaste nycklarna från dokumentet med federationsmetadata och sedan använder JWT-tokenhanteraren för att verifiera token. Kodfragmentet förutsätter att du använder din egen cachelagringsmekanism för att bevara nyckeln för att verifiera framtida token från Microsofts identitetsplattform, oavsett om det finns i en databas, konfigurationsfil eller någon annanstans.
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;
}
}
}
Webbprogram som skyddar resurser och skapas med Visual Studio 2012
Om ditt program skapades i Visual Studio 2012 använde du förmodligen identitets- och åtkomstverktyget för att konfigurera programmet. Det är också troligt att du använder VINR (Validating Issuer Name Registry). VINR ansvarar för att underhålla information om betrodda identitetsprovidrar (Microsofts identitetsplattform) och de nycklar som används för att verifiera token som utfärdats av dem. VINR gör det också enkelt att automatiskt uppdatera nyckelinformationen som lagras i en Web.config-fil genom att ladda ned det senaste federationsmetadatadokumentet som är associerat med din katalog, kontrollera om konfigurationen är inaktuell med det senaste dokumentet och uppdatera programmet för att använda den nya nyckeln efter behov.
Om du har skapat ditt program med hjälp av något av de kodexempel eller genomgångsdokumentation som tillhandahålls av Microsoft ingår redan logiken för nyckelåterställning i projektet. Du kommer att märka att koden nedan redan finns i projektet. Om ditt program inte redan har den här logiken följer du stegen nedan för att lägga till den och kontrollera att den fungerar korrekt.
- I Solution Explorer lägger du till en referens till sammansättningen System.IdentityModel för lämpligt projekt.
- Öppna filen Global.asax.cs och lägg till följande med hjälp av direktiv:
using System.Configuration; using System.IdentityModel.Tokens; - Lägg till följande metod i filen Global.asax.cs :
protected void RefreshValidationSettings() { string configPath = AppDomain.CurrentDomain.BaseDirectory + "\\" + "Web.config"; string metadataAddress = ConfigurationManager.AppSettings["ida:FederationMetadataLocation"]; ValidatingIssuerNameRegistry.WriteToConfig(metadataAddress, configPath); } - Anropa metoden RefreshValidationSettings() i metoden Application_Start() i Global.asax.cs enligt följande:
protected void Application_Start() { AreaRegistration.RegisterAllAreas(); ... RefreshValidationSettings(); }
När du har följt de här stegen uppdateras programmets Web.config med den senaste informationen från dokumentet med federationsmetadata, inklusive de senaste nycklarna. Den här uppdateringen sker varje gång programpoolen återanvänds i IIS. som standard är IIS inställt på att återanvända program var 29:e timme.
Följ stegen nedan för att kontrollera att nyckelåterställningslogik fungerar.
- När du har kontrollerat att programmet använder koden ovan öppnar du filen Web.config och navigerar till <blocket issuerNameRegistry> och letar specifikt efter följande rader:
<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> - I inställningen <lägg till tumavtryck=""> ändrar du tumavtrycksvärdet genom att ersätta alla tecken med ett annat. Spara filen Web.config.
- Skapa programmet och kör det sedan. Om du kan slutföra inloggningsprocessen uppdaterar programmet nyckeln genom att ladda ned nödvändig information från katalogens federationsmetadatadokument. Om du har problem med att logga in kontrollerar du att ändringarna i ditt program är korrekta genom att läsa artikeln Lägga till inloggning i ditt webbprogram med hjälp av Microsofts identitetsplattform eller ladda ned och inspektera följande kodexempel: Multitenant Cloud Application for Microsoft Entra ID.
Webbprogram/API:er som skyddar resurser med andra bibliotek eller implementerar något av protokollen som stöds manuellt
Om du använder något annat bibliotek eller manuellt implementerar något av de protokoll som stöds måste du granska biblioteket eller implementeringen för att säkerställa att nyckeln hämtas från antingen OpenID Connect-identifieringsdokumentet eller federationsmetadatadokumentet. Ett sätt att söka efter detta är att söka i koden eller bibliotekets kod efter eventuella anrop till antingen OpenID-identifieringsdokumentet eller federationsmetadatadokumentet.
Om nyckeln lagras någonstans eller hårdkodas i ditt program kan du manuellt hämta nyckeln och uppdatera den genom att utföra en manuell rollover enligt anvisningarna i slutet av det här vägledningsdokumentet. Det är starkt uppmuntrat att du förbättrar ditt program för att stödja automatisk rollover med någon av de metoder som beskrivs i den här artikeln för att undvika framtida störningar och omkostnader om Microsofts identitetsplattform ökar dess rollover-takt eller har en nödutrullning.
Så här testar du programmet för att avgöra om det kommer att påverkas
Du kan kontrollera om ditt program stöder automatisk nyckelåterställning med hjälp av följande PowerShell-skript.
Om du vill kontrollera och uppdatera signeringsnycklar med PowerShell behöver du POWERShell-modulen MSIdentityTools .
Installera MSIdentityTools PowerShell-modulen:
Install-Module -Name MSIdentityToolsLogga in med hjälp av kommandot Connect-MgGraph med ett administratörskonto för att godkänna de nödvändiga omfången:
Connect-MgGraph -Scope "Application.ReadWrite.All"Hämta listan över tillgängliga tumavtryck för signeringsnyckeln:
Get-MsIdSigningKeyThumbprintVälj något av tumavtrycken och konfigurera Microsoft Entra-ID för att använda den nyckeln med ditt program (hämta app-ID:t från administrationscentret för Microsoft Entra):
Update-MsIdApplicationSigningKeyThumbprint -ApplicationId <ApplicationId> -KeyThumbprint <Thumbprint>Testa webbprogrammet genom att logga in för att hämta en ny token. Nyckeluppdateringsändringen är omedelbar, men se till att du använder en ny webbläsarsession (till exempel Internet Explorers "InPrivate", Chromes "Incognito" eller Firefox"Private"-läge) för att säkerställa att du får en ny token.
För var och en av tumavtrycken för den returnerade signeringsnyckeln kör du cmdleten
Update-MsIdApplicationSigningKeyThumbprintoch testar inloggningsprocessen för webbprogrammet.Om webbprogrammet signerar dig korrekt stöder det automatisk återställning. Om den inte gör det ändrar du programmet så att det stöder manuell återställning. Mer information finns i Upprätta en manuell rollover-process.
Kör följande skript för att återgå till normalt beteende:
Update-MsIdApplicationSigningKeyThumbprint -ApplicationId <ApplicationId> -Default
Så här utför du en manuell rollover om programmet inte har stöd för automatisk rollover
Om ditt program inte stöder automatisk rollover måste du upprätta en process som regelbundet övervakar Microsofts identitetsplattform signeringsnycklar och utför en manuell rollover i enlighet med detta.
Om du vill kontrollera och uppdatera signeringsnycklar med PowerShell behöver MSIdentityTools du PowerShell-modulen.
MSIdentityToolsInstallera PowerShell-modulen:Install-Module -Name MSIdentityToolsHämta den senaste signeringsnyckeln (hämta klient-ID:t från administrationscentret för Microsoft Entra):
Get-MsIdSigningKeyThumbprint -Tenant <tenandId> -LatestJämför den här nyckeln med nyckeln som programmet för närvarande är hårdkodat eller konfigurerat att använda.
Om den senaste nyckeln skiljer sig från den nyckel som programmet använder laddar du ned den senaste signeringsnyckeln:
Get-MsIdSigningKeyThumbprint -Latest -DownloadPath <DownloadFolderPath>Uppdatera programmets kod eller konfiguration för att använda den nya nyckeln.
Konfigurera Microsoft Entra-ID för att använda den senaste nyckeln med ditt program (hämta app-ID:t från administrationscentret för Microsoft Entra):
Get-MsIdSigningKeyThumbprint -Latest | Update-MsIdApplicationSigningKeyThumbprint -ApplicationId <ApplicationId>Testa webbprogrammet genom att logga in för att hämta en ny token. Ändringen av nyckeluppdateringen är omedelbar, men se till att du använder en ny webbläsarsession för att säkerställa att du har utfärdat en ny token. Du kan till exempel använda Microsoft Edge-läget "InPrivate", Chromes "Incognito" eller Firefox".
Om du får problem återgår du till den tidigare nyckeln som du använde och kontaktar Azure Support:
Update-MsIdApplicationSigningKeyThumbprint -ApplicationId <ApplicationId> -KeyThumbprint <PreviousKeyThumbprint>När du har uppdaterat programmet för att stödja manuell återställning återgår du till normalt beteende:
Update-MsIdApplicationSigningKeyThumbprint -ApplicationId <ApplicationId> -Default