Exporter (0) Imprimer
Développer tout

Certificats et clés

Publication: avril 2011

Mis à jour: novembre 2014

S'applique à: Azure

Microsoft Azure Active Directory Access Control (également appelé Access Control Service ou ACS) propose deux manières différentes de signer et de chiffrer les jetons : les certificats X.509 avec une clé privée et les clés symétriques 256 bits. Vous pouvez configurer chaque certificat ou clé pour signer les jetons pour des applications de partie de confiance spécifiques ou pour toutes les applications de partie de confiance dans l'espace de noms, et vous désignez les certificats et les clés comme primaires ou secondaires. Pour ajouter et configurer la signature de jetons et des certificats et des clés de chiffrement et de déchiffrement, utilisez le service de gestion ACS ou le portail de gestion ACS.

ACS signe tous les jetons de sécurité qu'il émet avec un certificat X.509 (avec une clé privée) ou avec une clé symétrique 256 bits. Votre choix du type d'informations d'identification de signature (certificat ou clé) dépend du format de jeton que vous sélectionnez pour vos jetons émis par ACS. Pour plus d'informations, consultez « Signature de jetons » dans Applications par partie de confiance. Lors de la sélection du type d'informations d'identification de signature à créer, vous devez prendre en compte les éléments suivants :

  • Les jetons SAML sont signés avec des certificats X.509. SAML est le format de jeton par défaut utilisé par les applications reposant sur Windows Identity Foundation (WIF). Les jetons SAML peuvent être délivrés sur plusieurs protocoles, tels que WS-Federation et WS-Trust.

  • Les jetons SWT sont signés avec des clés symétriques 256 bits. Les jetons SWT peuvent être délivrés sur plusieurs protocoles, tels que OAuth WRAP et WS-Federation.

  • Les jetons JWT peuvent être signés par des certificats X.509 ou par des clés symétriques 256 bits. Les jetons JWT peuvent être délivrés sur plusieurs protocoles, tels que WS-Federation, WS-Trust et OAuth 2.0.

Vous pouvez configurer une clé symétrique ou un certificat de signature pour qu'il ou elle soit utilisé(e) pour l'ensemble de l'espace de noms Access Control ou uniquement pour une application de partie de confiance spécifique dans l'espace de noms. La différence est la suivante :

  • espace de noms Access Control —Quand une clé ou un certificat de signature est configuré pour l'ensemble de l'espace de noms Access Control, ACS utilise le certificat ou la clé pour signer les jetons pour toutes les applications de partie de confiance dans cet espace de noms qui ne possèdent pas de clé ou de certificat spécifique à l'application. Un certificat ayant un espace de noms comme étendue est également utilisé pour signer les métadonnées WS-Federation ACS.

  • Dédié—Si vous configurez une clé ou un certificat de signature pour qu'il ou elle soit utilisé(e) pour une application de partie de confiance spécifique, ACS utilise la clé ou le certificat de signature uniquement pour signer les jetons délivrés à l'application de partie de confiance spécifiée.

    Si vous créez ou entrez une clé symétrique dédiée, ACS utilise la clé dédiée pour signer les jetons pour l'application. Si la clé dédiée expire et n'est pas remplacée, ACS utilise la clé symétrique de l'espace de noms Access Control pour signer les jetons pour l'application.

noteRemarque
  • Lors de l'utilisation de clés symétriques, une meilleure pratique de sécurité consiste à créer une clé dédiée pour chaque application de partie de confiance. Un certificat X.509 peut être partagé sans danger par plusieurs applications dans un espace de noms Access Control.

  • Quand vous ajoutez une application de partie de confiance gérée par Microsoft à un espace de noms géré, par exemple en cas d'ajout d'une application de partie de confiance Service Bus à un espace de noms Service Bus, n'utilisez pas de clés ou de certificats spécifiques à l'application (dédiés). Au lieu de cela, sélectionnez l'option ACS qui permet d'utiliser les certificats et les clés configurés pour toutes les applications dans l'espace de noms géré. Pour toutes les autres applications de partie de confiance, utilisez des clés et des certificats spécifiques à l'application. Pour plus d'informations, consultez Espaces de noms gérés.

  • Quand vous configurez une application de partie de confiance qui utilise le certificat X.509 pour l'espace de noms Access Control pour signer des jetons JWT, des liens vers le certificat espace de noms Access Control et vers la clé espace de noms Access Control apparaissent dans la page correspondant à l'application de partie de confiance dans le portail de gestion ACS. Toutefois, ACS utilise uniquement le certificat d'espace de noms pour signer les jetons pour l'application de partie de confiance.

Les certificats de signature servent généralement à signer des jetons pour toutes les application de partie de confiance dans un espace de noms. Le composant clé publique d'un certificat de signature d'espace de noms est publié dans les métadonnées WS-Federation ACS, ce qui permet aux applications de partie de confiance d'automatiser leur configuration. Les clés publiques des certificats qui sont assignés uniquement à une application de partie de confiance spécifique ne sont pas présentes dans les métadonnées WS-Federation ACS. Elles sont utilisées uniquement quand vous devez pouvoir contrôler indépendamment le certificat de signature d'une application de partie de confiance.

Dans ACS, vous pouvez tenir à jour plusieurs certificats et clés, mais utiliser uniquement les clés et les certificats désignés pour signer les jetons. Les certificats et les clés désignés pour la signature portent le nom de certificats et clés primaires.

Pour désigner un certificat ou une clé comme primaire, sélectionnez l'élément Rendre primaire dans la page du certificat ou de la clé. Pour désigner un autre certificat comme primaire, sélectionnez l'élément Rendre primaire dans la page de l'autre certificat ou clé. Dans ce cas, ACS rétrograde automatiquement les clés ou les certificats primaires existants.

Quand au moins un certificat ou une clé est primaire, les autres certificats et clés ne sont pas utilisés pour la signature, à moins d'être promus à un état primaire par l'administrateur, même si le certificat ou la clé primaire est non valide ou a expiré. Toutefois si aucun des certificats ou clés n'est primaire, ACS utilise le certificat non primaire ayant la date de début de validité la plus ancienne.

Le composant clé publique des certificats primaires et non primaires est publié dans les métadonnées WS-Federation ACS afin de permettre le déploiement de certificat par programmation. Toutefois, ACS utilise uniquement des clés et des certificats primaires pour signer les jetons.

Quand vous ajoutez des clés de signature symétriques 256 bits, vous devez aussi spécifier une date d'effet et une date d'expiration. La date d'effet indique la date d'entrée en vigueur de cette clé. La date d'expiration indique la date à partir de laquelle cette clé ne peut plus être utilisée pour signer des jetons.

Dans ACS, vous pouvez choisir de chiffrer des jetons SAML 1.1 ou SAML 2.0 délivrés par ACS à vos applications de partie de confiance.

ImportantImportant
ACS ne prend pas en charge le chiffrement des jetons SWT ou JWT.

Le chiffrement des jetons est nécessaire pour les services web qui utilisent des jetons avec preuve de possession sur le protocole WS-Trust. Si vous utilisez ACS pour gérer l'authentification pour une application de partie de confiance de ce type, tous les jetons délivrés par ACS pour cette application de partie de confiance doivent être chiffrés. Dans tous les autres scénarios, le chiffrement des jetons est facultatif.

ACS chiffres les jetons SAML à l'aide d'un certificat X.509 contenant une clé publique (fichier .cer). L'application de partie de confiance déchiffre le jeton à l'aide d'une clé privée pour ce certificat X.509. Pour plus d'informations, consultez « Chiffrement de jetons » dans Applications par partie de confiance.

ACS peut accepter des jetons chiffrés provenant de fournisseurs d'identité WS-Federation, tels que les services . Le fournisseur d'identité WS-Federation reçoit la clé publique d'un certificat X.509 quand il importe des métadonnées WS-Federation à partir d'ACS et il utilise cette clé publique pour chiffrer le jeton de sécurité qui est transféré à ACS. ACS déchiffre le jeton à l'aide de la clé privée de ce certificat X.509. Pour plus d'informations, consultez Configuration d'ADFS 2.0 en tant que fournisseur d'identité.

Vous pouvez tenir à jour plusieurs certificats de déchiffrement de jetons pour une application de partie de confiance ou un espace de noms Access Control. Quand vous désignez un certificat comme primaire, ACS l'utilise pour déchiffrer les jetons provenant des fournisseurs d'identité WS-Federation. Il utilise des certificats non primaires uniquement si la tentative d'utilisation du certificat primaire échoue.

Pour désigner un certificat de déchiffrement comme primaire, sélectionnez l'élément Rendre primaire dans la page du certificat. Pour désigner un autre certificat comme primaire, sélectionnez l'élément Rendre primaire dans la page de l'autre certificat. Dans ce cas, ACS rétrograde automatiquement les certificats de déchiffrement primaires existants.

Dans ACS, les certificats X.509 qui contiennent seulement une clé publique (fichier .cer) peuvent être utilisés lors de la création d'une identité de service, lors de la validation de la signature d'un fournisseur d'identité ou lors du chiffrement de jetons SAML. Les fichiers de certificats X.509 qui contiennent seulement une clé publique (fichier .cer) doivent être encodés DER pour pouvoir être utilisés avec ACS. Les fichiers de certificats encodés Base64 ne sont pas pris en charge actuellement. Le téléchargement d'un certificat encodé Base64 vers ACS provoque une erreur de validation quand ACS reçoit un jeton entrant qui nécessite ce certificat.

Dans ACS, les certificats X.509 doivent être auto-signés ou signés et chaînés directement à une autorité de certification publique. ACS ne fonctionne pas avec les certificats délivrés par une autorité de certification privée.

noteRemarque
Les certificats X.509 importés dans ACS ne doivent pas avoir expiré.

Il existe plusieurs manières d'obtenir un certificat X.509 pour la signature de jetons ou le chiffrement ou déchiffrement de jetons. Celle que vous adopterez dépendra de vos exigences et des outils disponibles au sein de votre organisation.

Autorité de certification commerciale : vous pouvez acheter un certificat X.509 auprès d'une autorité de certification commerciale.

Générer un certificat auto-signé : vous pouvez générer votre propre certificat auto-signé pour l'utiliser avec ACS. Si vous exécutez un système d'exploitation Windows, vous pouvez utiliser MakeCert.exe, un outil fourni avec le Kit de développement logiciel Microsoft Windows (Kit SDK Windows) (http://go.microsoft.com/fwlink/?LinkID=214104) pour générer un certificat auto-signé.

Par exemple, la commande suivante génère un certificat auto-signé dans votre magasin de certificats personnels.

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

où <service_namespace_name> est le nom de votre espace de noms Access Control.

Vous pouvez ensuite exporter la clé privée à partir de votre magasin personnel en tant que fichier .pfx et utiliser le portail de gestion ACS pour la télécharger vers ACS.

Ces instructions expliquent comment exporter un certificat auto-signé à partir d'un ordinateur exécutant Windows 8, Windows Server 2012, ou .

  1. Démarrez MMC.exe et ajoutez le composant logiciel enfichable Certificats à votre console MMC.

  2. Double-cliquez sur Certificats - Utilisateur actuel, Personnel, puis Certificats.

  3. Cliquez avec le bouton droit sur un certificat, cliquez sur Toutes les tâches, puis sur Exporter.

  4. Dans la page Assistant Exportation de certificat, cliquez sur Suivant.

  5. Dans la page Exporter la clé privée, sélectionnez Oui, exporter la clé privée, puis cliquez sur Suivant.

  6. Dans la page Format de fichier d'exportation, cliquez sur Échange d'informations personnelles - PKCS #12 (.PFX).

  7. Dans les champs Mot de passe, entrez un mot de passe et confirmez ce mot de passe, puis cliquez sur Suivant.

  8. Dans le champ Nom du fichier, entrez un nom de fichier et un chemin d'accès avec une extension de nom de fichier .pfx, puis cliquez sur Suivant.

  9. Cliquez sur Terminer.

ACS évalue les dates de début et de fin des certificats et des clés au format UTC (Temps universel coordonné). Par conséquent, ACS peut considérer des clés et des certificats comme non valides même quand ils sont valides dans l'heure locale de l'ordinateur local ou dans un autre fuseau horaire.

Pour être sûr que le certificat ou la clé est valide immédiatement, ajustez les dates au format UTC. Sinon, ACS risque de ne pas pouvoir délivrer de jeton car la clé ou le certificat n'est pas encore valide.

Voir aussi

Ajouts de la communauté

AJOUTER
Afficher:
© 2014 Microsoft