Compartir a través de

Certificados y claves

  • Artículo

Actualizado: 19 de junio de 2015

Se aplica a: Azure

Microsoft Azure Active Directory Access Control (también conocido como Access Control Service o ACS) ofrece dos maneras diferentes de firmar y cifrar tokens: certificados X.509 con una clave privada y claves simétricas de 256 bits. Es posible configurar cada certificado o clave para firmar tokens de aplicaciones de usuario de confianza específicas o para todas las aplicaciones de usuario de confianza del espacio de nombres. Asimismo, es posible designar certificados y claves como principales y secundarios. Para agregar y configurar certificados y claves de firma, cifrado y descifrado de tokens, use el servicio de administración de ACS o el Portal de administración de ACS.

Firma de tokens

ACS firma todos los tokens de seguridad que emite con un certificado X.509 (con una clave privada) o una clave simétrica de 256 bits. La elección de un tipo de credencial de firma (certificado o clave) depende del formato de token que seleccione para los tokens emitidos por ACS. Para obtener más información, vea "Firma de tokens" en Aplicaciones de usuario de confianza. Al seleccionar el tipo de credencial de firma que se va a crear, tenga en cuenta lo siguiente:

  • Los tokens SAML se firman con certificados X.509. El formato SAML es el formato predeterminado de tokens que utilizan las aplicaciones basadas en Windows Identity Foundation (WIF). Los tokens SAML se pueden emitir a través de varios protocolos como, por ejemplo WS-Federation y WS-Trust.

  • Los tokens SWT se firman mediante claves simétricas de 256 bits. Los tokens SWT se pueden emitir a través de varios protocolos como, por ejemplo OAuth WRAP y WS-Federation.

  • Los tokens JWT se pueden firmar con certificados X.509 o claves simétricas de 256 bits. Los tokens JWT se pueden emitir a través de varios protocolos como, por ejemplo WS-Federation, WS-Trust y OAuth 2.0.

Claves y certificados dedicados o de espacios de nombres

Puede configurar un certificado de firma o una clave simétrica para que se use para todo el espacio de nombres Access Control o solo para una aplicación de usuario de confianza determinada en el espacio de nombres. La diferencia es la siguiente:

  • Access Control espacio de nombres : cuando se configura un certificado o clave de firma para todo el espacio de nombres Access Control, ACS usa el certificado o la clave para firmar tokens para todas las aplicaciones de usuario de confianza de este espacio de nombres que no tienen un certificado o clave específicos de la aplicación. Un certificado con ámbito de espacio de nombres también se usa para firmar metadatos de ACS WS-Federation.

  • Dedicado: si configura un certificado o clave de firma que se usará para una aplicación de usuario de confianza determinada, ACS usa el certificado de firma o la clave solo para firmar tokens entregados a la aplicación de usuario de confianza especificada.

    Si crea o escribe una clave simétrica dedicada, ACS usa la clave dedicada para firmar tokens para la aplicación. Si la clave dedicada expira y no se reemplaza, ACS usa la clave simétrica para el espacio de nombres Access Control para firmar tokens para la aplicación.

Nota

  • Como práctica de seguridad, cuando use claves simétricas, cree una clave dedicada para cada aplicación de usuario de confianza. Un certificado X.509 puede compartirse de forma segura por varias aplicaciones en un espacio de nombres Access Control.

  • Al agregar una aplicación de usuario de confianza administrada con Microsoft en un espacio de nombres administrado como, por ejemplo, al agregar una aplicación de usuario de confianza de Service Bus a un espacio de nombres de Service Bus, no utilice certificados o claves específicos de aplicaciones (dedicados). En su lugar, seleccione la opción ACS para utilizar los certificados y claves configurados para todas las aplicaciones del espacio de nombres administrado. Para el resto de las aplicaciones de usuario de confianza, utilice claves y certificados específicos de aplicaciones. Para más información, consulte Espacios de nombres administrados.

  • Al configurar una aplicación de usuario de confianza que usa el certificado X.509 para el espacio de nombres Access Control para firmar tokens JWT, vínculos al certificado de espacio de nombres Access Control y la clave de espacio de nombres Access Control aparecen en la página de la aplicación de usuario de confianza en el Portal de administración de ACS. Sin embargo, ACS usa solo el certificado de espacio de nombres para firmar tokens para la aplicación de usuario de confianza.

Los certificados de firma suelen utilizarse para firmar tokens de todas las aplicaciones de usuario de confianza de un espacio de nombres. El componente de clave pública de un certificado de firma de espacio de nombres se publica en los metadatos de acs WS-Federation, lo que permite a las aplicaciones de usuario de confianza automatizar su configuración. Las claves públicas de los certificados que se asignan solo a una aplicación de usuario de confianza determinada no están presentes en los metadatos del WS-Federation de ACS y solo se usan cuando se requiere un control independiente sobre el certificado de firma de una aplicación de usuario de confianza.

Certificados y claves principales

En ACS, puede mantener varios certificados y claves, pero usar solo certificados y claves designados para firmar tokens. Los certificados y claves designados para la firma se conocen como certificados y claves principales.

Para designar un certificado o clave como principal, seleccione el elemento Convertir en principal de la página del certificado o la clave. Para designar otro certificado como principal, seleccione el elemento Convertir en principal de la página del otro certificado o clave. Cuando lo hace, ACS desvía automáticamente los certificados o claves principales existentes a no principal.

Cuando haya al menos un certificado o clave principal, los certificados y claves que no sean principales dejarán de utilizarse para la firma hasta que el administrador los promocione a principales, incluso cuando el certificado o clave principal haya caducado o no sea válido. Sin embargo, si ninguno de los certificados (o claves) es principal, ACS usa el certificado no principal que tiene la fecha de inicio válida más antigua.

El componente de clave pública de los certificados principales y no principales se publica en los metadatos de acs WS-Federation para habilitar la sustitución de certificados mediante programación. Sin embargo, ACS solo usa certificados y claves principales para firmar tokens.

Fechas de caducidad y de efecto de las claves de firma

Al agregar claves de firma simétricas de 256 bits, también deberá especificar una fecha de efecto y una fecha de caducidad. La fecha de efecto indica la fecha en la que entra en vigor la clave. La fecha de caducidad indica la fecha en que caduca la clave y tras la cual ya no se puede utilizar para firmar tokens.

Cifrado de tokens

En ACS, puede optar por cifrar cualquier token de SAML 1.1 o SAML 2.0 que ACS emite a las aplicaciones de usuario de confianza.

Importante

ACS no admite el cifrado de tokens SWT o JWT.

El cifrado de tokens es necesario para servicios web que utilicen tokens de prueba de posesión a través del protocolo WS-Trust. Si usa ACS para administrar la autenticación para esta aplicación de usuario de confianza, se deben cifrar todos los tokens emitidos por ACS para esta aplicación de usuario de confianza. En el resto de escenarios, el cifrado de tokens es opcional.

ACS cifra los tokens SAML mediante un certificado X.509 que contiene una clave pública (archivo .cer). El token de la aplicación de usuario de confianza descifra el token utilizando una clave privada para dicho certificado X.509. Para obtener más información, vea "Cifrado de tokens" en Aplicaciones de usuario de confianza.

Descifrado de tokens

ACS puede aceptar tokens cifrados de WS-Federation proveedores de identidades, como . El proveedor de identidades WS-Federation recibe la clave pública de un certificado X.509 cuando importa WS-Federation metadatos de ACS y usa esta clave pública para cifrar el token de seguridad que se reenvía a ACS. ACS descifra el token mediante la clave privada de este certificado X.509. Para obtener más información, vea Cómo: Configurar AD FS 2.0 como proveedor de identidades.

Certificados de descifrado de tokens principales

Puede mantener varios certificados de descifrado de tokens para una aplicación de usuario de confianza o Access Control espacio de nombres. Al designar un certificado como principal, ACS usa ese certificado para descifrar los tokens de WS-Federation proveedores de identidades y usa certificados no principales solo si se produce un error en el intento de usar el certificado principal.

Para designar un certificado de firma como principal, seleccione el elemento Convertir en principal en la página del certificado. Para designar otro certificado como principal, seleccione el elemento Convertir en principal de la página del otro certificado. Al hacerlo, ACS desvía automáticamente los certificados de descifrado principal existentes en los que no son principales.

Limitaciones de ACS para los archivos de certificado X.509

En ACS, los certificados X.509 que contienen solo una clave pública (archivo .cer) se pueden usar al crear una identidad de servicio, validar una firma de un proveedor de identidades o cifrar tokens SAML. Los archivos de certificado X.509 que contienen solo una clave pública (archivo .cer) deben estar codificados en DER para usarse con ACS. Los archivos de certificados con codificación Base64 no son compatibles. Al cargar un certificado codificado en base64 en ACS, se producirá un error de validación cuando ACS reciba un token entrante que requiera ese certificado.

En ACS, los certificados X.509 deben estar autofirmados o estar firmados y encadenados directamente a una entidad de certificación pública. ACS no funcionará con certificados emitidos por una entidad de certificación privada.

Nota

Los certificados X.509 importados en ACS no deben expirar.

Obtención de un certificado X.509

Existen varias maneras de obtener un certificado X.509 para la firma de tokens, el cifrado o descifrado de tokens. El método utilizado dependerá de los requisitos y de las herramientas disponibles en su organización.

Autoridad de certificación comercial: puede adquirir un certificado X.509 de una autoridad de certificación comercial.

Generar un certificado Self-Signed: puede generar su propio certificado autofirmado para usarlo con ACS. Si ejecuta un sistema operativo basado en Windows, puede usar MakeCert.exe, una herramienta incluida en el Kit de desarrollo de software de Microsoft Windows (https://go.microsoft.com/fwlink/?LinkID=214104) para generar un certificado autofirmado.

Por ejemplo, el comando siguiente generará un certificado autofirmado en su almacén personal de certificados.

MakeCert.exe -r -pe -n "CN=<service_namespace_name>.accesscontrol.windows.net" -sky exchange -ss my -len 2048 –e <1 year from today>

donde <service_namespace_name> es el nombre del espacio de nombres Access Control.

Después, puede exportar la clave privada desde su almacén personal como un archivo .pfx y usar el Portal de administración de ACS para cargarla en ACS.

Exportación de certificados autofirmados

En estas instrucciones se explica cómo exportar una certificación autofirmado desde un equipo que ejecuta Windows 8, Windows Server 2012, o .

Para exportar su certificado autofirmado

  1. Inicie MMC.exe y agregue el complemento Certificados a la consola MMC.

  2. Haga doble clic en Certificados - Usuario actual, Personal y luego en Certificados.

  3. Haga clic con el botón secundario en un certificado, haga clic en Todas las tareas y luego haga clic en Exportar.

  4. En la página Asistente para exportación de certificados, haga clic en Siguiente.

  5. En la página Exportar clave privada, seleccione Sí, exportar la clave privada y luego haga clic en Siguiente.

  6. En la página Formato de archivo de exportación, haga clic en Intercambio de información personal - PKCS #12 (.PFX).

  7. En los campos Contraseña, especifique una contraseña y una contraseña de confirmación y haga clic en Siguiente.

  8. En el campo Nombre de archivo, especifique un nombre de archivo con una extensión de nombre de archivo .pfx y luego haga clic en Siguiente.

  9. Haga clic en Finalizar

Fechas válidas de claves y certificados

ACS evalúa las fechas de inicio y finalización (y fecha y hora) de certificados y claves en la hora universal coordinada (UTC). Como resultado, ACS podría considerar que las claves y los certificados no son válidos incluso cuando son válidos en la hora local del equipo local o en otra zona horaria.

Para asegurarse de que el certificado o la clave sean válidos de inmediato, ajuste las fechas según la hora UTC. De lo contrario, ACS podría no emitir un token porque la clave o el certificado aún no son válidos.

Consulte también

Conceptos

Componentes de ACS 2.0
Aplicaciones de usuario de confianza
Directrices de administración de claves y certificados