¿Le resultó útil esta página?
Sus comentarios sobre este contenido son muy importantes. Háganos saber su opinión.
¿Tiene comentarios adicionales?
Caracteres restantes: 1500
Certificados y claves

Certificados y claves

Publicada: abril de 2011

Actualizado: junio de 2015

Se aplica a: Azure

Active Directory Access Control de Microsoft Azure (también conocido como Access Control Service o ACS) ofrece dos formas de firmar y cifrar tokens: Mediante el uso de certificados X.509 con una clave privada y mediante 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 los certificados y claves de firma, cifrado y descifrado de tokens, utilice el servicio de administración de ACS o del Portal de administración de ACS.

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 posibilidad de firmar un tipo de credencial (certificado o clave) depende del formato de token seleccionado para sus 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.

Es posible configurar un certificado de firma o una clave simétrica para utilizarla en todo el Espacio de nombres Access Control o solo para una aplicación de usuario de confianza determinada del espacio de nombres. La diferencia es la siguiente:

  • Espacio de nombres Access Control : cuando se configura una clave o certificado para todo el Espacio de nombres Access Control, ACS utiliza la clave o el certificado para firmar los tokens de todas las aplicaciones de usuario de confianza de este espacio de nombres que no tengan clave o certificado específico de la aplicación. También se utiliza un certificado de ámbito del espacio de nombres para firmar los metadatos WS-Federation de ACS.

  • Dedicado: se configura una clave o certificado de firma para el uso en una aplicación de usuario de confianza determinada, ACS utilizará la clave o certificado de firma solo para firmar tokens entregados a la aplicación de usuario de confianza determinada.

    Si crea o especifica una clave simétrica dedicada, ACS utilizará la clave dedicada para firmar los tokens de la aplicación. Si la clave dedicada expira y no se reemplaza, ACS usará la clave simétrica para el Espacio de nombres Access Control para firmar los tokens de la aplicación.

noteNota
  • Como práctica de seguridad, cuando use claves simétricas, cree una clave dedicada para cada aplicación de usuario de confianza. Es posible compartir con seguridad un certificado X.509 con varias aplicaciones de un mismo 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 bus de servicio a un espacio de nombres de bus de servicio, 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 obtener más información, vea Espacios de nombres administrados.

  • Al configurar una aplicación de usuario de confianza que utiliza el certificado X.509 para el Espacio de nombres Access Control para que firme tokens JWT, los vínculos al certificado del Espacio de nombres Access Control y a la clave del Espacio de nombres Access Control se muestran en la página de la aplicación de usuario de confianza en el Portal de administración de ACS. Sin embargo, ACS utiliza solo el certificado de espacio de nombres para firmar los tokens de 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 WS-Federation de ACS, lo que permite automatizar la configuración de las aplicaciones de usuario de confianza. Las claves públicas de los certificados que solo se asignan a una aplicación de usuario de confianza determinada no están presentes en los metadatos de WS-Federation de ACS y solo se utilizan cuando se requiere un control independiente del certificado de firma de la aplicación de confianza.

En ACS, podrá mantener varias claves y certificados, aunque solo podrá usar las claves y certificados 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. Al realizar esta acción, ACS degradará automáticamente los certificados o claves principales existentes a no principales.

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 utilizará el certificado no principal con la fecha de inicio válida más antigua.

El componente de clave pública de los certificados principales y no principales se publicará en los metadatos de WS-Federation de ACS para permitir la sustitución del certificado mediante programación. Sin embargo, ACS solo utilizará los certificados y claves principales para firmar los tokens.

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.

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

ImportantImportante
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 utiliza ACS para administrar la autenticación de este tipo de aplicaciones de usuario de confianza, deberá 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 utilizando 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.

ACS puede aceptar tokens cifrados de proveedores de identidades de WS-Federation como, por ejemplo, . El proveedor de identidades de WS-Federation recibe la clave pública de un certificado X.509 al importar los metadatos de WS-Federation de ACS y utiliza dicha clave pública para cifrar el token de seguridad que se reenvía al ACS. ACS descifra el token utilizando la clave privada del certificado X.509. Para obtener más información, vea Procedimiento: Configurar AD FS 2.0 como proveedor de identidad.

Es posible mantener varios certificados de descifrado de tokens para una aplicación de usuario de confianza o Espacio de nombres Access Control. Al designar un certificado como principal, ACS utiliza dicho certificado para descifrar los tokens de los proveedores de identidades de WS-Federation y utiliza certificados no principales solo en caso de error al intentar 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 realizar esta acción, ACS degradará automáticamente los certificados de descifrado principales existentes a no principales.

En ACS, los certificados X.509 que contienen solo una clave pública (archivo .cer) pueden utilizarse al crear una identidad de servicio, al validar la firma de un proveedor de identidades o al cifrar los tokens SAML. Los archivos de certificado X.509 que solo contienen una clave pública (archivo .cer) deben estar codificados mediante DER para que se puedan utilizar con ACS. Los archivos de certificados con codificación Base64 no son compatibles. La carga de un certificado con codificación base64 en ACS generará un error de validación cuando ACS reciba un token entrante que requiera dicho certificado.

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

noteNota
Los certificados X.509 importados en ACS no podrá estar caducados.

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 autofirmado: es posible genera un certificado autofirmado propio para utilizarlo con ACS. Si ejecuta un sistema operativo Windows, puede utilizar la herramienta MakeCert.exe, incluida en el Kit de desarrollo de software de Microsoft Windows (http://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 de su Espacio de nombres Access Control.

A continuación, podrá exportar la clave privada del almacén personal como archivo .pfx y utilizar el Portal de administración de ACS para cargarla en ACS.

Estas instrucciones explican cómo exportar un certificado autofirmado de un equipo que use Windows 8, Windows Server 2012, o .

  1. Inicie MMC.exe y agregue el complemento Certificados a la consola de 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.

ACS evalúa las fechas de inicio y de finalización (y la fecha y hora) de los certificados y claves en hora universal coordinada (UTC). Como resultado, es posible que ACS considere las claves y certificados como no válidos 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, es posible que ACS no emita el token debido a que el certificado o la clave aún no son válidos.

Vea también

Adiciones de comunidad

AGREGAR
Mostrar:
© 2015 Microsoft