Sustitución de claves de firma en la Plataforma de identidad de Microsoft
En este artículo se habla de lo que se necesita saber sobre las claves públicas que se usan en la Plataforma de identidad de Microsoft para firmar los tokens de seguridad. Es importante tener en cuenta que estas claves se sustituyen de forma periódica y, en caso de emergencia, podrían ser sustituidas inmediatamente. Todas las aplicaciones que usan la Plataforma de identidad de Microsoft deben poder controlar el proceso de sustitución de claves mediante programación. Comprenderá cómo funcionan las claves, cómo evaluar el impacto de la sustitución en la aplicación. También aprenderá a actualizar la aplicación o a establecer un proceso de sustitución manual periódico para controlar la sustitución de claves si es necesario.
Introducción a las claves de firma en la Plataforma de identidad de Microsoft
La Plataforma de identidad de Microsoft emplea una criptografía de clave pública basada en estándares del sector con el fin de establecer una relación de confianza entre ella y las aplicaciones que la usan. En la práctica, esto funciona de la manera siguiente: La Plataforma de identidad de Microsoft usa una clave de firma que consta de un par de claves pública y privada. Cuando un usuario inicia sesión en una aplicación que usa la Plataforma de identidad de Microsoft para la autenticación, esta plataforma crea un token de seguridad que contiene información sobre el usuario. El Plataforma de identidad de Microsoft firma este token mediante su clave privada antes de devolverlo a la aplicación. Para comprobar que el token es válido y que se ha originado en la Plataforma de identidad de Microsoft, la aplicación debe validar la firma del token mediante las claves públicas expuestas por la Plataforma de identidad de Microsoft incluida en el documento de detección de OpenID Connect del inquilino o el documento de metadatos de federación de SAML/WS-Fed.
Por motivos de seguridad, la Plataforma de identidad de Microsoft sustituye la clave de firma de forma periódica y, en caso de emergencia, podría hacerlo de inmediato. No hay tiempo establecido ni garantizado entre estas tiradas de claves. Cualquier aplicación que se integre con el Plataforma de identidad de Microsoft debe estar preparada para controlar un evento de sustitución de claves independientemente de la frecuencia con la que pueda producirse. Si la aplicación no controla las actualizaciones repentinas e intenta usar una clave expirada para comprobar la firma en un token, la aplicación rechaza incorrectamente el token. Se recomienda usar bibliotecas estándar para asegurarse de que los metadatos de clave se actualizan correctamente y se mantienen actualizados. En los casos en los que no se usan las bibliotecas estándar, asegúrese de que la implementación sigue la sección de procedimientos recomendados .
Siempre hay más de una clave válida disponible en el documento de detección de OpenID Connect y en el de metadatos de federación. La aplicación debe estar preparada para usar todas y cada una de las claves especificadas en el documento, ya que una clave se puede sustituir pronto, otra puede ser su reemplazo, etc. El número de claves presentes puede cambiar con el tiempo en función de la arquitectura interna de Plataforma de identidad de Microsoft a media que se admitan nuevas plataformas, nuevas nubes o nuevos protocolos de autenticación. Ni el orden de las claves en la respuesta JSON ni el orden en el que se han expuesto deben considerarse significativos para la aplicación.
Las aplicaciones que solo admiten una sola clave de firma o aplicaciones que requieren actualizaciones manuales de las claves de firma son intrínsecamente menos seguras y menos confiables. Deben actualizarse para usar bibliotecas estándar a fin de garantizar que siempre usen claves de firma actualizadas, entre otros procedimientos recomendados.
Procedimientos recomendados para el almacenamiento en caché y validación de metadatos de claves
- Detección de claves mediante el punto de conexión específico del inquilino, tal y como se describe en OpenID Connect (OIDC) y metadatos de federación
- Incluso si la aplicación se implementa en varios inquilinos, se recomienda detectar y almacenar en caché las claves de forma independiente para cada inquilino al que sirve la aplicación (mediante el punto de conexión específico del inquilino). Una clave que es común en todos los inquilinos actualmente puede ser distinta en todos los inquilinos en el futuro.
- Use el algoritmo de almacenamiento en caché siguiente para asegurarse de que el almacenamiento en caché es resistente y seguro.
Algoritmo de almacenamiento en caché de metadatos de claves:
Nuestras bibliotecas estándar implementan el almacenamiento en caché resistente y seguro de las claves. Se recomienda usarlos para evitar defectos sutiles en la implementación. Para implementaciones personalizadas, este es el algoritmo aproximado:
Consideraciones generales:
- El servicio que valida tokens debe tener una memoria caché capaz de almacenar muchas claves distintas (10-1000).
- Las claves se deben almacenar en caché individualmente, con el identificador de clave ("kid" en la especificación de metadatos de claves OIDC) como clave de caché.
- El período de vida de las claves en la memoria caché debe configurarse en 24 horas, con actualizaciones que se producen cada hora. Esto garantiza que el sistema pueda responder rápidamente a las claves que se quitan, pero tiene suficiente duración de caché para no verse afectada por problemas en la captura de claves.
- Las claves deben actualizarse:
- Una vez en el inicio del proceso o cuando la memoria caché está vacía
- Periódicamente (recomendado cada 1 hora) como trabajo en segundo plano
- Dinámicamente si un token recibido se firmó con una clave desconocida (niño desconocido o ordenado en el encabezado)
Procedimiento KeyRefresh (algoritmo conceptual de IdentityModel)
Inicialización
El administrador de configuración se configura con una dirección específica para capturar los datos de configuración y las interfaces necesarias para recuperar y validar estos datos.
Comprobación de configuración
Antes de capturar nuevos datos, el sistema comprueba primero si los datos existentes siguen siendo válidos en función de un intervalo de actualización predefinido.
Recuperación de datos Si los datos están obsoletos o faltan, el sistema se bloquea para asegurarse de que solo un subproceso captura los nuevos datos para evitar la duplicación (y el agotamiento de subprocesos). A continuación, el sistema intenta recuperar los datos de configuración más recientes de un punto de conexión especificado.
Validación
Una vez recuperados los nuevos datos, se valida para asegurarse de que cumple los estándares necesarios y no está dañado. Los metadatos solo se aceptan cuando una solicitud entrante se validó correctamente con las nuevas claves.
Tratamiento de errores
Si se producen errores durante la recuperación de datos, se registran. El sistema sigue funcionando con la última configuración correcta conocida si no se pueden capturar nuevos datos.
Actualizaciones automáticas El sistema comprueba y actualiza periódicamente los datos de configuración automáticamente en función del intervalo de actualización (se recomienda 12 h con una vibración de más o menos 1 h). También puede solicitar manualmente una actualización si es necesario, lo que garantiza que los datos siempre están actualizados.
Validación de un token con una nueva clave Si un token llega con una clave de firma que aún no se conoce de la configuración, el sistema intenta capturar la configuración con una llamada de sincronización en la ruta de acceso activa para controlar nuevas claves en metadatos fuera de las actualizaciones esperadas normales (pero no con más de 5 minutos).
Este enfoque garantiza que el sistema siempre use los datos de configuración más actualizados y válidos, a la vez que controla correctamente los errores y evita las operaciones redundantes.
La implementación de .NET de este algoritmo está disponible en BaseConfigurationManager. Está sujeto a cambios en función de las evaluaciones de resistencia y seguridad. Consulte también una explicación aquí.
Procedimiento KeyRefresh (pseudocódigo):
Este procedimiento usa una marca de tiempo global (lastSuccessfulRefreshTime) para evitar condiciones que actualizan las claves con demasiada frecuencia.
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
}
Procedimiento de inicio del servicio:
- KeyRefresh para actualizar las claves
- Inicio de un trabajo en segundo plano que llama a KeyRefresh cada hora
Procedimiento TokenValidation para validar la clave (pseudocódigo):
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
}
}
}
Cómo evaluar si su aplicación se verá afectada y qué hacer al respecto
La forma que tiene la aplicación de controlar la sustitución de claves depende de ciertas variables, como el tipo de aplicación o qué protocolo de identidad y biblioteca se han usado. Las secciones siguientes evalúan si los tipos más comunes de aplicaciones se ven afectados por la sustitución de claves y ofrecen orientación sobre cómo actualizar la aplicación para admitir la sustitución automática o actualizar manualmente la clave.
- Aplicaciones de cliente nativas que acceden a recursos
- Aplicaciones y API web que acceden a recursos
- Aplicaciones y API web que protegen recursos y creadas mediante Azure App Service
- Aplicaciones Web o API que protegen los recursos mediante ASP.NET OWIN OpenID Connect, WS-Fed o WindowsAzureActiveDirectoryBearerAuthentication
- Aplicaciones y API web que protegen recursos mediante el middleware ASP.NET Core OpenID Connect o JwtBearerAuthentication
- Aplicaciones y API web que protegen recursos mediante el módulo Node.js
passport-azure-ad - Aplicaciones y API web de protección de recursos y creadas con Visual Studio 2015 o versión posterior
- Aplicaciones Web de protección de recursos y creadas con Visual Studio 2013
- API web de protección de recursos y creadas con Visual Studio 2013
- Aplicaciones web de protección de recursos y creadas con Visual Studio 2012
- Aplicaciones y API web de protección de recursos que usan cualquier otra biblioteca o que implementan manualmente cualquiera de los protocolos admitidos
Esta guía no es aplicable para:
- Las aplicaciones agregadas desde la Galería de aplicaciones de Microsoft Entra (incluido Personalizado) tienen instrucciones independientes sobre las claves de firma. Más información.
- Las aplicaciones locales publicadas a través del proxy de la aplicación no tienen que preocuparse acerca de las claves de firma.
Aplicaciones de cliente nativas que acceden a recursos
Las aplicaciones que solo acceden a los recursos (por ejemplo, Microsoft Graph, KeyVault, API de Outlook y otras API de Microsoft) únicamente obtienen un token y lo pasan al propietario del recurso. Como no protegen ningún recurso, no inspeccionan el token y, por tanto, no tienen que asegurar de que se firmó correctamente.
Las aplicaciones de cliente nativo, ya sean de escritorio o móviles, entran en esta categoría y, por tanto, no se verán afectadas por la sustitución.
Aplicaciones y API web que acceden a recursos
Las aplicaciones que solo acceden a los recursos (como Microsoft Graph, KeyVault, API de Outlook y otras API de Microsoft) únicamente obtienen un token y lo pasan al propietario del recurso. Como no protegen ningún recurso, no inspeccionan el token y, por tanto, no tienen que asegurar de que se firmó correctamente.
Las aplicaciones web y las API web que usan el flujo solo de aplicación (credenciales de cliente o certificado de cliente) para solicitar tokens entran en esta categoría y, por tanto, no se ven afectadas por la sustitución.
Aplicaciones y API web que protegen recursos y creadas mediante Azure App Service
La funcionalidad de autenticación o autorización (EasyAuth) de Azure App Service ya cuenta con la lógica necesaria para controlar automáticamente la sustitución de claves.
Aplicaciones Web o API que protegen recursos mediante ASP.NET middleware OWIN OpenID Connect, WS-Fed o WindowsAzureActiveDirectoryBearerAuthentication
Si la aplicación está utilizando el middleware ASP.NET OWIN OpenID Connect, WS-Fed o WindowsAzureActiveDirectoryBearerAuthentication, ya tiene la lógica necesaria para controlar automáticamente la sustitución de clave.
Puede confirmar que la aplicación utiliza cualquiera de estos, busque cualquiera de los siguientes fragmentos de código en los archivos Startup.cs o Startup.Auth.cs de la aplicación.
app.UseOpenIdConnectAuthentication(
new OpenIdConnectAuthenticationOptions
{
// ...
});
app.UseWsFederationAuthentication(
new WsFederationAuthenticationOptions
{
// ...
});
app.UseWindowsAzureActiveDirectoryBearerAuthentication(
new WindowsAzureActiveDirectoryBearerAuthenticationOptions
{
// ...
});
Aplicaciones y API web que protegen recursos mediante el middleware .NET Core OpenID Connect o JwtBearerAuthentication
Si la aplicación está utilizando el middleware ASP.NET OWIN OpenID Connect o JwtBearerAuthentication, ya tiene la lógica necesaria para controlar automáticamente la sustitución de clave.
Puede confirmar que la aplicación utiliza cualquiera de estos, busque cualquiera de los siguientes fragmentos de código en la aplicación Startup.cs o Startup.Auth.cs
app.UseOpenIdConnectAuthentication(
new OpenIdConnectAuthenticationOptions
{
// ...
});
app.UseJwtBearerAuthentication(
new JwtBearerAuthenticationOptions
{
// ...
});
Aplicaciones y API web que protegen recursos mediante el módulo passport-azure-ad de Node.js
Si la aplicación está utilizando el módulo Node.js passport-ad, ya tiene la lógica necesaria para controlar automáticamente la sustitución de clave.
Puede confirmar su aplicación passport-ad si busca el siguiente fragmento en el archivo app.js de la aplicación
var OIDCStrategy = require('passport-azure-ad').OIDCStrategy;
passport.use(new OIDCStrategy({
//...
));
Aplicaciones y API web de protección de recursos y creadas con Visual Studio 2015 o versión posterior
Si la aplicación se compiló mediante una plantilla de aplicación web en Visual Studio 2015 o versión posterior y seleccionó Cuentas profesionales o educativas en el menú Cambiar autenticación, ya tiene la lógica necesaria para controlar automáticamente la sustitución de claves. Esta lógica, insertada en el middleware de OpenID Connect de OWIN, recupera y almacena en caché las claves del documento de detección de OpenID Connect y las actualiza periódicamente.
Si ha agregado manualmente la autenticación a la solución, la aplicación no tendrá la lógica necesaria para la sustitución de claves. Puede escribirlo usted mismo, o seguir los pasos enAplicaciones Web / API mediante el uso de cualquier otra biblioteca o implementar manualmente cualquiera de los protocolos soportados.
Aplicaciones Web de protección de recursos y creadas con Visual Studio 2013
Si la aplicación se compiló mediante una plantilla de aplicación web en Visual Studio 2013 y seleccionó Cuentas profesionales en el menú Cambiar autenticación, ya tiene la lógica necesaria para controlar automáticamente la sustitución de claves. Esta lógica almacena la información de la clave de firma y el identificador único de la organización en dos tablas de base de datos asociadas al proyecto. Puede encontrar la cadena de conexión de la base de datos en el archivo Web.config del proyecto.
Si ha agregado manualmente la autenticación a la solución, la aplicación no tendrá la lógica necesaria para la sustitución de claves. Debe escribirlo usted mismo o seguir los pasos descritos en Aplicaciones web o API mediante cualquier otra biblioteca o implementar manualmente cualquiera de los protocolos admitidos.
Los siguientes pasos ayudan a comprobar que la lógica funcione correctamente en la aplicación.
- En Visual Studio 2013, abra la solución y seleccione la pestaña Explorador de servidores de la ventana derecha.
- Expanda Conexiones de datos, DefaultConnection y Tablas. Busque la tabla IssuingAuthorityKeys, haga clic con el botón derecho en ella y, después, con el botón izquierdo, seleccione Mostrar datos de tabla.
- En la tabla IssuingAuthorityKeys habrá al menos una fila, que corresponde al valor de la huella digital de la clave. Elimine las filas de la tabla.
- Haga clic con el botón derecho en la tabla Inquilinos y seleccione Mostrar datos de tabla.
- En la tabla Inquilinos habrá al menos una fila, que corresponde a un identificador único del inquilino de directorio. Elimine las filas de la tabla. Si no elimina las filas de la tabla Tenants y de la tabla IssuingAuthorityKeys , obtendrá un error en tiempo de ejecución.
- Compile y ejecute la aplicación. Una vez que haya iniciado sesión en la cuenta, podrá detener la aplicación.
- Vuelva a la pestaña Explorador de servidores y examine los valores de las tablas IssuingAuthorityKeys e Inquilinos. Observará que se rellenaron automáticamente con la información adecuada del documento de metadatos de federación.
API web de protección de recursos y creadas con Visual Studio 2013
Si creó una aplicación API web en Visual Studio 2013 con la plantilla de API web y, después, seleccionó Cuentas profesionales en el menú Cambiar autenticación, la aplicación ya tiene la lógica necesaria.
Si configura manualmente la autenticación, siga estas instrucciones para aprender a configurar la API web con el fin de actualizar automáticamente la información de claves.
En el siguiente fragmento de código se muestra cómo obtener las claves más recientes del documento de metadatos de federación y, a continuación, se usa el controlador de tokens JWT para validar el token. El fragmento de código supone que usará su propio mecanismo de almacenamiento en caché para conservar la clave para validar los tokens futuros de la plataforma de identidad de Microsoft, ya sea en una base de datos, un archivo de configuración o en otro lugar.
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;
}
}
}
Aplicaciones web de protección de recursos y creadas con Visual Studio 2012
Si la aplicación se compiló en Visual Studio 2012, probablemente ha utilizado la herramienta de identidad y acceso para configurar la aplicación. También es probable que use el Registro de nombres de emisor de validación (VINR). El VINR se encarga de mantener la información sobre los proveedores de identidad de confianza (Plataforma de identidad de Microsoft) y las claves utilizadas para validar los tokens que emiten. El VINR también facilita la tarea de actualizar automáticamente la información de claves almacenada en un archivo Web.config descargando el documento de metadatos de federación más reciente asociado a su directorio, comprobando si la configuración está actualizada con respecto al último documento y actualizando la aplicación para usar la nueva clave según sea necesario.
Si ha creado la aplicación utilizando cualquiera de los ejemplos de código o la documentación de tutorial que proporciona Microsoft, la lógica de sustitución de claves ya estará incluida en el proyecto. Observará que el código siguiente ya existe en el proyecto. Si la aplicación aún no tiene esta lógica, siga los pasos siguientes para agregarla y comprobar que funciona correctamente.
- En Explorador de soluciones, agregue una referencia al ensamblado System.IdentityModel del proyecto correspondiente.
- Abra el archivo Global.asax.cs y agregue lo siguiente utilizando directivas:
using System.Configuration; using System.IdentityModel.Tokens; - Agregue el método siguiente al archivo Global.asax.cs :
protected void RefreshValidationSettings() { string configPath = AppDomain.CurrentDomain.BaseDirectory + "\\" + "Web.config"; string metadataAddress = ConfigurationManager.AppSettings["ida:FederationMetadataLocation"]; ValidatingIssuerNameRegistry.WriteToConfig(metadataAddress, configPath); } - Invoque el método RefreshValidationSettings() en el método Application_Start() de Global.asax.cs, tal y como se muestra:
protected void Application_Start() { AreaRegistration.RegisterAllAreas(); ... RefreshValidationSettings(); }
Una vez que haya seguido estos pasos, el archivo Web.config de la aplicación se actualizará con la información más reciente del documento de metadatos de federación, incluidas las últimas claves. Esta actualización se producirá cada vez que recicle el grupo de aplicaciones de IIS; de forma predeterminada, esta acción se realizará cada 29 horas.
Siga los pasos que figuran a continuación para comprobar que la lógica de sustitución de claves funciona correctamente.
- Una vez que haya comprobado que la aplicación está utilizando el código anterior, abra el archivo Web.config y desplácese al bloque <issuerNameRegistry> y busque expresamente las siguientes líneas:
<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> - En la configuración <add thumbprint="">, cambie el valor de la huella digital reemplazando cualquier carácter por otro diferente. Guarde el archivo Web.config .
- Compile la aplicación y, después, ejecútela. Si puede completar el proceso de inicio de sesión, la aplicación actualizará correctamente la clave descargando la información necesaria del documento de metadatos de federación de su directorio. Si tiene problemas para iniciar sesión, asegúrese de que los cambios de la aplicación son correctos; para ello, lea el artículo Agregar inicio de sesión a la aplicación web con Plataforma de identidad de Microsoft o descargue e inspeccione el siguiente ejemplo de código: Aplicación en la nube multiinquilino para el identificador de Microsoft Entra.
Aplicaciones y API web de protección de recursos que usan cualquier otra biblioteca o que implementan manualmente cualquiera de los protocolos admitidos
Si usa alguna otra biblioteca o implementa manualmente cualquiera de los protocolos admitidos, deberá revisar la biblioteca o la implementación para asegurarse de que la clave se está recuperando del documento de detección de OpenID Connect o del documento de metadatos de federación. Una forma de comprobarlo es realizar una búsqueda en el código o en el de la biblioteca de las llamadas al documento de detección OpenID o al documento de metadatos de federación.
Si la clave se está almacenando en algún lugar o está incrustada directamente en la aplicación, puede recuperarla de forma manual y actualizarla según corresponda; para ello, realice una sustitución manual de acuerdo con las instrucciones al final de este documento de orientación. Se recomienda encarecidamente mejorar la aplicación para que admita la sustitución automática mediante cualquiera de los enfoques descritos en este artículo a fin de evitar futuras interrupciones y la sobrecarga si la Plataforma de identidad de Microsoft aumenta su cadencia de sustitución o se produce una sustitución de emergencia no programada.
Cómo probar la aplicación para determinar si se verá afectada
Puede validar si su aplicación admite la sustitución automática de claves usando los siguientes scripts de PowerShell.
Para comprobar y actualizar las claves de firma con PowerShell, necesitará el módulo MSIdentityTools de PowerShell.
Instale el módulo MSIdentityTools de PowerShell:
Install-Module -Name MSIdentityToolsInicie sesión con el comando Connect-MgGraph con una cuenta de administrador para dar su consentimiento a los ámbitos necesarios:
Connect-MgGraph -Scope "Application.ReadWrite.All"Obtenga la lista de huellas digitales de clave de firma disponibles:
Get-MsIdSigningKeyThumbprintElija cualquiera de las huellas digitales de clave y configure Microsoft Entra ID para usar esa clave con la aplicación (obtenga el identificador de la aplicación del Centro de administración de Microsoft Entra):
Update-MsIdApplicationSigningKeyThumbprint -ApplicationId <ApplicationId> -KeyThumbprint <Thumbprint>Pruebe la aplicación web iniciando sesión para obtener un nuevo token. El cambio de actualización de claves es instantáneo, pero asegúrese de usar una nueva sesión del explorador (por ejemplo, "InPrivate" de Internet Explorer, "Incógnito" de Chrome o el modo "Privado" de Firefox) para asegurarse de que se emite un nuevo token.
Para cada una de las huellas digitales de clave de firma devueltas, ejecute el
Update-MsIdApplicationSigningKeyThumbprintcmdlet y pruebe el proceso de inicio de sesión de la aplicación web.Si la aplicación web inicia sesión correctamente, admite la sustitución automática. Si no es así, modifique la aplicación para admitir la sustitución manual. Consulte Establecimiento de un proceso de sustitución manual para obtener más información.
Ejecute el siguiente script para revertir al comportamiento normal:
Update-MsIdApplicationSigningKeyThumbprint -ApplicationId <ApplicationId> -Default
Cómo realizar una sustitución manual si la aplicación no admite la sustitución automática
Si la aplicación no admite la sustitución automática, debe establecer un proceso que supervise periódicamente las claves de firma de la Plataforma de identidad de Microsoft y realizar una sustitución manual cuando corresponda.
Para comprobar y actualizar las claves de firma con PowerShell, necesita el MSIdentityTools módulo de PowerShell.
Instale el módulo de PowerShell
MSIdentityTools:Install-Module -Name MSIdentityToolsObtenga la clave de firma más reciente (obtenga el identificador de inquilino del Centro de administración de Microsoft Entra):
Get-MsIdSigningKeyThumbprint -Tenant <tenandId> -LatestCompare esta clave con la clave que la aplicación está codificada o configurada actualmente para su uso.
Si la clave más reciente es diferente de la clave que usa la aplicación, descargue la clave de firma más reciente:
Get-MsIdSigningKeyThumbprint -Latest -DownloadPath <DownloadFolderPath>Actualice el código o la configuración de la aplicación para usar la nueva clave.
Configure Microsoft Entra ID para usar la clave más reciente con la aplicación (obtenga el identificador de la aplicación en el Centro de administración de Microsoft Entra):
Get-MsIdSigningKeyThumbprint -Latest | Update-MsIdApplicationSigningKeyThumbprint -ApplicationId <ApplicationId>Pruebe la aplicación web iniciando sesión para obtener un nuevo token. El cambio de actualización de claves es instantáneo, pero asegúrese de usar una nueva sesión del explorador para asegurarse de que se ha emitido un nuevo token. Por ejemplo, use "InPrivate" de Microsoft Edge, el modo "Incógnito" de Chrome o el modo "Privado" de Firefox.
Si tiene algún problema, revierta a la clave anterior que estaba usando y póngase en contacto con el soporte técnico de Azure:
Update-MsIdApplicationSigningKeyThumbprint -ApplicationId <ApplicationId> -KeyThumbprint <PreviousKeyThumbprint>Después de actualizar la aplicación para admitir la suversión manual, vuelva al comportamiento normal:
Update-MsIdApplicationSigningKeyThumbprint -ApplicationId <ApplicationId> -Default