Diese Dokumentation wurde archiviert und wird nicht länger gepflegt.

Zertifikate und Schlüssel

Veröffentlicht: April 2011

Letzte Aktualisierung: Juni 2015

Betrifft: Azure

Zugriffssteuerung für Microsoft Azure Active Directory (auch Zugriffssteuerungsdienst oder ACS) bietet zwei verschiedene Möglichkeiten zum Signieren und Verschlüsseln von Token: X.509-Zertifikate mit einem privaten Schlüssel und symmetrische 256-Bit-Schlüssel. Sie können jedes Zertifikat oder jeden Schlüssel so konfigurieren, dass Token für bestimmte Anwendungen oder für alle Anwendungen der vertrauenden Seite im Namespace signiert werden. Zudem können Sie für Zertifikate und Schlüssel festlegen, ob diese primär oder sekundär sind. Sie können die Zertifikate und die Schlüssel für die Tokensignatur und die Tokenver- und -entschlüsselung mithilfe des ACS-Verwaltungsdiensts oder des ACS-Verwaltungsportals hinzufügen und konfigurieren.

ACS signiert alle ausgestellten Sicherheitstoken mithilfe eines X.509-Zertifikats (mit einem privaten Schlüssel) oder eines symmetrischen 256-Bit-Schlüssels. Ihre Wahl eines Typs von Signaturanmeldeinformationen (Zertifikat oder Schlüssel) hängt von dem für von ACS ausgestellte Token ausgewählten Tokenformat ab. Weitere Informationen finden Sie unter "Tokensignatur" in Anwendungen der vertrauenden Seite. Wenn Sie die zu erstellenden Signaturanmeldeinformationen auswählen, ist Folgendes zu berücksichtigen:

  • SAML-Token werden mithilfe von X.509-Zertifikaten signiert. SAML ist das Standardtokenformat, das von Anwendungen verwendet wird, die auf Windows Identity Foundation (WIF) basieren. SAML-Token können über mehrere Protokolle ausgestellt werden, z. B. über WS-Verbund und WS-Trust.

  • SWT-Token werden mithilfe von symmetrischen 256-Bit-Schlüsseln signiert. SWT-Token können über mehrere Protokolle ausgestellt werden, z. B. über OAuth WRAP und WS-Verbund.

  • JWT-Token können mithilfe von X.509-Zertifikaten oder symmetrischen 256-Bit-Schlüsseln signiert werden. JWT-Token können über mehrere Protokolle ausgestellt werden, z. B. über WS-Verbund, WS-Trust und OAuth 2.0.

Sie können ein Signaturzertifikat oder einen symmetrischen Schlüssel konfigurieren, sodass diese für den gesamten Namespace für die Zugriffssteuerung oder nur für eine bestimmte Anwendung der vertrauenden Seite im Namespace verwendet werden. Dabei besteht der folgende Unterschied:

  • Namespace für die Zugriffssteuerung – Wenn ein Signaturzertifikat oder Schlüssel für den gesamten Namespace für die Zugriffssteuerung konfiguriert ist, verwendet ACS dieses Zertifikat oder diesen Schlüssel zum Signieren von Token für alle Anwendungen der vertrauenden Seite in diesem Namespace, für die kein eigenes Zertifikate oder eigener Schlüssel ausdrücklich konfiguriert ist. Ein auf den Namespacebereich begrenztes Zertifikat wird auch zum Signieren der WS-Verbundmetadaten von ACS verwendet.

  • Dediziert – Wenn Sie ein Signaturzertifikat oder einen Schlüssel konfigurieren, das oder der für eine bestimmte Anwendung der vertrauenden Seite verwendet werden soll, verwendet ACS dieses Signaturzertifikat oder den -schlüssel nur zum Signieren von Token, die an diese angegebene Anwendung der vertrauenden Seite übermittelt wurden.

    Wenn Sie einen dedizierten symmetrischen Schlüssel erstellen oder eingeben, verwendet ACS den dedizierten Schlüssel zum Signieren von Token für die Anwendung. Wenn der dedizierte Schlüssel abläuft und nicht ersetzt wird, verwendet ACS den symmetrischen Schlüssel für den Namespace für die Zugriffssteuerung, um Token für die Anwendung zu signieren.

noteHinweis
  • Als bewährte Sicherheitsmethode erstellen Sie bei der Verwendung symmetrischer Schlüssel für jede Anwendung der vertrauenden Seite einen dedizierten Schlüssel. Ein X.509-Zertifikat kann von mehreren Anwendungen in einem Namespace für die Zugriffssteuerung auf sichere Weise gemeinsam verwendet werden.

  • Wenn Sie eine von Microsoft verwaltete Anwendung der vertrauenden Seite einem verwalteten Namespace hinzufügen (z. B. beim Hinzufügen einer Service Bus-Anwendung der vertrauenden Seite zu einem Service Bus-Namespace), verwenden Sie keine anwendungsspezifischen (dedizierten) Zertifikate oder Schlüssel. Wählen Sie stattdessen die ACS-Option zum Verwenden der Zertifikate und Schlüssel aus, die für alle Anwendungen im verwalteten Namespace konfiguriert sind. Für alle anderen Anwendungen der vertrauenden Seite verwenden Sie anwendungsspezifische Zertifikate und Schlüssel. Weitere Informationen finden Sie unter Verwaltete Namespaces.

  • Wenn Sie die Anwendung einer vertrauenden Seite konfigurieren, die das X.509-Zertifikat für den Namespace für die Zugriffssteuerung verwendet, um JWT-Token zu signieren, werden auf der Seite für die Anwendung der vertrauenden Seite Links zum Namespace für die Zugriffssteuerungzertifikat sowie der Namespace für die Zugriffssteuerungschlüssel im ACS-Verwaltungsportal angezeigt. ACS verwendet jedoch nur das Namespacezertifikat zum Signieren von Token für die Anwendung der vertrauenden Seite.

Signaturzertifikate werden in der Regel zum Signieren von Token für die Anwendungen vertrauender Seiten in einem Namespace verwendet. Die öffentliche Schlüsselkomponente von Namespace-Signaturzertifikaten wird in den WS-Verbundmetadaten von ACS veröffentlicht. Auf diese Weise können Anwendungen der vertrauenden Seite ihre Konfiguration automatisieren. Die öffentlichen Schlüssel oder Zertifikate, die ausschließlich einer bestimmten Anwendung der vertrauenden Seite zugewiesen wurden, sind in den WS-Verbundmetadaten von ACS nicht vorhanden und werden nur verwendet, wenn eine unabhängige Kontrolle über das Signaturzertifikat einer Anwendung der vertrauenden Seite erforderlich ist.

In ACS können Sie verschiedene Zertifikate und Schlüssel verwalten, aber nur designierte Zertifikate und Schlüssel zum Signieren von Token verwenden. Die zum Signieren bestimmten Zertifikate und Schlüssel werden als primäre Zertifikate und Schlüssel bezeichnet.

Wählen Sie auf der Seite für ein Zertifikat oder Schlüssel die Option Primär machen, um ein Zertifikat oder Schlüssel als primär festzulegen. Wählen Sie die Option Primär machen auf der Seite für ein anderes Zertifikat oder einen anderen Schlüssel fest, um diese als als primär festzulegen. In diesem Fall stuft ACS alle vorhanden primären Zertifikate oder Schlüssel als "nicht primär" zurück.

Wenn mindestens ein Zertifikat oder Schlüssel primär ist, werden nicht primäre Zertifikate und Schlüssel nicht zum Signieren verwendet, bis sie von einem Administrator den primären Status zugewiesen bekommen, auch wenn das bisherige primäre Zertifikat oder der primäre Schlüssel ungültig oder abgelaufen ist. Wenn kein Zertifikat (oder Schlüssel) primär ist, verwendet ACS das nicht primäre Zertifikat mit dem frühesten gültigen Startdatum.

Die öffentliche Schlüsselkomponente primärer und nicht primärer Zertifikate wird in den WS-Verbundmetadaten von ACS veröffentlicht, um einen programmgesteuerten Zertifikatrollover zu ermöglichen. ACS verwendet jedoch ausschließlich primäre Zertifikate und Schlüssel zum Signieren von Token.

Wenn symmetrische 256-Bit-Signaturschlüssel hinzugefügt werden, müssen Sie ein Gültigkeitsdatum sowie ein Ablaufdatum angeben. Das Gültigkeitsdatum gibt das Datum an, zu dem Schlüssel in Kraft tritt. Das Ablaufdatum gibt das Datum an, an dem dieser Schlüssel abläuft und nicht mehr zum Signieren von Token verwendet werden kann.

In ACS können Sie alle SAML 1.1- oder SAML 2.0-Token verschlüsseln, die ACS ausstellt und an die Anwendungen der vertrauenden Seite sendet.

ImportantWichtig
Die Verschlüsselung von SWT- oder JWT-Token wird von ACS nicht unterstützt.

Die Tokenverschlüsselung ist für Webdienste erforderlich, die Eigentumsnachweistoken über das WS-Verbundprotokoll verwenden. Wenn Sie ACS zur Verwaltung der Authentifizierung einer solchen Anwendung der vertrauenden Seite verwenden, müssen alle von ACS ausgestellten Token für diese Anwendung der vertrauenden Seite verschlüsselt sein. In allen anderen Fällen ist die Tokenverschlüsselung optional.

ACS verschlüsselt SAML-Token mithilfe eines X.509-Zertifikats, das einen öffentlichen Schlüssel (CER-Datei) enthält. Der Anwendungstoken der vertrauenden Seite entschlüsselt den Token mithilfe eines privaten Schlüssels für das X.509-Zertifikat. Weitere Informationen finden Sie unter "Tokenverschlüsselung" in Anwendungen der vertrauenden Seite.

ACS kann verschlüsselte Token von WS-Verbundidentitätsanbietern wie annehmen. Der WS-Verbundidentitätsanbieter empfängt den öffentlichen Schlüssel dieses X.509-Zertifikats, wenn er die WS-Verbundmetadaten von ACS importiert. Er verwendet diesen öffentlichen Schlüssel dann zum Verschlüsseln des Sicherheitstokens, das an ACS weitergeleitet wird. ACS entschlüsselt dieses Token anschließend mithilfe des privaten Schlüssels dieses X.509-Zertifikats. Weitere Informationen finden Sie unter Vorgehensweise: Konfigurieren von AD FS 2.0 als Identitätsanbieter.

Sie können mehrere Tokenentschlüsselungszertifikate für die Anwendung einer vertrauenden Seite oder für einen Namespace für die Zugriffssteuerung verwalten. Wenn Sie ein Zertifikat als primär festlegen, verwendet ACS dieses Zertifikat zum Entschlüsseln der Token von WS-Verbundidentitätsanbietern. Nicht primäre Zertifikate werden nur verwendet, wenn bei der Anwendung des primären Zertifikats ein Fehler auftritt.

Wählen Sie die Option Primär machen auf der Seite für das Zertifikat, um ein Verschlüsselungszertifikat als primär festzulegen. Wählen Sie die Option Primär machen auf der Seite für das andere Zertifikat, um ein anderes Zertifikat als primär festzulegen. In diesem Fall stuft ACS alle vorhanden primären Verschlüsselungszertifikate als "nicht primär" zurück.

In ACS können X.509-Zertifikate, die nur einen öffentlichen Schlüssel (CER-Datei) enthalten, zum Erstellen einer Dienstidentität, zum Überprüfen einer Signatur eines Identitätsanbieters oder zum Verschlüsseln von SAML-Token verwendet werden. X.509-Zertifikatsdateien, die nur einen öffentlichen Schlüssel (CER-Datei) enthalten, müssen mit DER codiert werden, damit sie mit ACS verwendet werden können. Base64-codierte Zertifikatdateien werden derzeit nicht unterstützt. Das Hochladen eines base64-codierten Zertifikats zu ACS führt zu einem Überprüfungsfehler, wenn ACS ein eingehendes Token empfängt, das dieses Zertifikat erfordert.

In ACS müssen X.509-Zertifikate entweder selbstsigniert sein oder direkt von einer öffentlichen Zertifizierungsstelle signiert und verkettet werden. ACS funktioniert nicht mit Zertifikaten, die von einer privaten Zertifizierungsstelle ausgestellt wurden.

noteHinweis
In ACS importierte X.509-Zertifikate dürfen nicht ablaufen.

Ein X.509-Zertifikat für die Tokensignatur, Tokenverschlüsselung oder Tokenentschlüsselung kann mit verschiedenen Methoden abgerufen werden. Die von Ihnen verwendete Methode hängt von Ihren Anforderungen und den in Ihrer Organisation verfügbaren Tools ab.

Kommerzielle Zertifizierungsstelle - Sie können ein X.509-Zertifikat von einer kommerziellen Zertifizierungsstelle erwerben.

Generieren eines selbstsignierten Zertifikats - Sie können eigene selbstsignierte Zertifikate generieren, die mit ACS verwendet werden. Wenn Sie ein auf Windows basierendes Betriebssystem ausführen, können Sie MakeCert.exe, ein im Microsoft Windows Software Development Kit (http://go.microsoft.com/fwlink/?LinkID=214104) enthaltenes Tool, verwenden, um ein selbstsigniertes Zertifikat zu generieren.

Der folgende Befehl generiert z. B. ein selbstsigniertes Zertifikat in Ihrem persönlichen Zertifikatspeicher.

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

Dabei ist <service_namespace_name> der Name Ihres Namespace für die Zugriffssteuerung.

Anschließend können Sie den privaten Schlüssel aus Ihrem persönlichen Zertifikatspeicher als PFX-Datei exportieren und mithilfe des ACS-Verwaltungsportals in ACS hochladen.

Diese Anweisungen erläutern, wie ein selbstsigniertes Zertifikat von einem Computer exportiert wird, auf dem Windows 8, Windows Server 2012, oder ausgeführt wird.

  1. Starten Sie MMC.exe, und fügen Sie das Snap-In Zertifikate zur MMC-Konsole hinzu.

  2. Doppelklicken Sie auf Zertifikate – Aktueller Benutzer, Privat und dann auf Zertifikate.

  3. Klicken Sie mit der rechten Maustaste auf ein Zertifikat, klicken Sie dann auf Alle Aufgaben und anschließend auf Exportieren.

  4. Klicken Sie auf derWillkommenseite auf Weiter.

  5. Wählen Sie auf der Seite Privaten Schlüssel exportieren die Option Ja, privaten Schlüssel exportieren aus, und klicken Sie dann auf Weiter.

  6. Klicken Sie auf der Seite Format der zu exportierenden Datei auf die Option Privater Informationsaustausch – PKCS #12 (.PFX).

  7. Geben Sie in die Felder Kennwort ein Kennwort und ein Bestätigungskennwort ein, und klicken Sie dann auf Weiter.

  8. Geben Sie unter Dateiname einen Pfad und Dateinamen mit der Dateinamenerweiterung PFX ein, und klicken Sie dann auf Weiter.

  9. Klicken Sie auf Fertig stellen.

ACS wertet die Start- und Enddaten (und Zeiten) von Zertifikaten und Schlüsseln im UTC-Format (Coordinated Universal Time) aus. Daher betrachtet ACS Schlüssel und Zertifikate möglicherweise als ungültig, auch wenn diese gemäß der lokalen Uhrzeit auf dem lokalen Computer oder in einer anderen Zeitzone gültig sind.

Passen Sie die Datumsangaben auf das UTC-Format an, um sicherzustellen, dass das Zertifikat oder der Schlüssel sofort gültig ist. Andernfalls kann ACS ein Token möglicherweise nicht ausstellen, da der Schlüssel oder das Zertifikat noch nicht gültig ist.

Siehe auch

Anzeigen: