Certificats et clés

Mise à jour : 19 juin 2015

S’applique à : Azure

Microsoft Azure Active Directory Access Control (également appelé service Access Control ou ACS) offre deux façons de signer et de chiffrer des jetons : des certificats X.509 avec une clé privée et des 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 jeton, le chiffrement et les certificats et clés de déchiffrement, utilisez le service de gestion ACS ou le portail de gestion ACS.

Signature de jetons

ACS signe tous les jetons de sécurité qu’il émet avec un certificat X.509 (avec une clé privée) ou une clé symétrique 256 bits. Votre choix d’un 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 jeton » dans les applications de 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.

Clés et certificats dédiés ou spécifiques à un espace de noms

Vous pouvez configurer un certificat de signature ou une clé symétrique afin qu’elle soit utilisée pour l’ensemble de l’espace de noms Access Control ou uniquement pour une application de partie de confiance particulière dans l’espace de noms. La différence est la suivante :

• Access Control espace de noms : lorsqu’un certificat ou une clé de signature est configuré pour l’ensemble de l’espace de noms Access Control, ACS utilise le certificat ou la clé pour signer des jetons pour toutes les applications de partie de confiance de cet espace de noms qui n’ont pas de certificat ou clé spécifique à l’application. Un certificat délimité par un espace de noms est également utilisé pour signer les métadonnées ACS WS-Federation.

• Dédié : si vous configurez un certificat de signature ou une clé à utiliser pour une application de partie de confiance particulière, ACS utilise le certificat de signature ou la clé uniquement pour signer des jetons remis à 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 des 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 des jetons pour l’application.

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 ACS WS-Federation, ce qui permet aux applications de partie de confiance d’automatiser leur configuration. Les clés publiques des certificats qui sont attribuées uniquement à une application de partie de confiance particulière ne sont pas présentes dans les métadonnées ACS WS-Federation et sont utilisées uniquement lorsque le contrôle indépendant sur le certificat de signature d’une application de partie de confiance est requis.

Certificats et clés principaux

Dans ACS, vous pouvez gérer plusieurs certificats et clés, mais utiliser uniquement des certificats et des clés désignés pour signer des 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é. Lorsque vous le faites, ACS rétrograde automatiquement tous les certificats ou clés principaux existants en non-principal.

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 principal, ACS utilise le certificat non principal dont la date de début est la plus ancienne.

Le composant clé publique des certificats principaux et non principaux est publié dans les métadonnées ACS WS-Federation pour activer la substitution de certificat par programmation. Toutefois, ACS utilise uniquement les certificats et clés principaux pour signer des jetons.

Dates d'effet et dates d'expiration des clés de signature

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.

Chiffrement des jetons

Dans ACS, vous pouvez choisir de chiffrer n’importe quel jeton SAML 1.1 ou SAML 2.0 qui émet des problèmes ACS à vos applications de partie de confiance.

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 telle application de partie de confiance, tous les jetons émis 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 chiffre 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 des jetons » dans les applications de partie de confiance.

Déchiffrement des jetons

ACS peut accepter des jetons chiffrés à partir de WS-Federation fournisseurs d’identité, tels que . Le fournisseur d’identité WS-Federation reçoit la clé publique d’un certificat X.509 lorsqu’il importe WS-Federation métadonnées d’ACS et qu’il utilise cette clé publique pour chiffrer le jeton de sécurité transféré vers ACS. ACS déchiffre le jeton à l’aide de la clé privée de ce certificat X.509. Pour plus d’informations, consultez Guide pratique pour configurer AD FS 2.0 en tant que fournisseur d’identité.

Certificats de déchiffrement de jetons primaires

Vous pouvez gérer plusieurs certificats de déchiffrement de jeton pour une application de partie de confiance ou un espace de noms Access Control. Lorsque vous désignez un certificat comme principal, ACS utilise ce certificat pour déchiffrer les jetons des fournisseurs d’identité WS-Federation et utilise des certificats non principaux uniquement si la tentative d’utilisation du certificat principal é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. Lorsque vous le faites, ACS rétrograde automatiquement les certificats de déchiffrement principal existants en non-principal.

Limitations d'ACS relatives aux fichiers de certificats X.509

Dans ACS, les certificats X.509 qui contiennent uniquement une clé publique (fichier.cer) peuvent être utilisés lors de la création d’une identité de service, de la validation d’une signature d’un fournisseur d’identité ou du chiffrement de jetons SAML. Les fichiers de certificat X.509 qui contiennent uniquement une clé publique (fichier.cer) doivent être codés par DER pour être utilisés avec ACS. Les fichiers de certificats encodés Base64 ne sont pas pris en charge actuellement. Le chargement d’un certificat encodé en base64 dans ACS entraîne une erreur de validation lorsque 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 auprès d’une autorité de certification publique. ACS ne fonctionnera pas avec les certificats émis par une autorité de certification privée.

Obtention d'un certificat X.509

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érez un certificat Self-Signed: vous pouvez générer votre propre certificat auto-signé à utiliser avec ACS. Si vous exécutez un système d’exploitation basé sur Windows, vous pouvez utiliser MakeCert.exe, un outil inclus dans le Kit de développement logiciel Microsoft Windows (https://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 le charger dans ACS.

Exportation d'un certificat auto-signé

Ces instructions expliquent comment exporter une certification auto-signée à partir d’un ordinateur exécutant Windows 8, Windows Server 2012, ou .

Pour exporter votre certificat-auto signé

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.

Dates de validité des certificats et des clés

ACS évalue les dates de début et de fin (et date-heures) des certificats et des clés dans l’heure universelle coordonnée (UTC). Par conséquent, ACS peut considérer que les clés et les certificats ne sont pas valides même s’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 peut échouer à émettre un jeton, car la clé ou le certificat n’est pas encore valide.

Voir aussi

Concepts

Composants ACS 2.0
Applications de partie de confiance
Recommandations en matière de gestion de certificats et de clés