Zertifikate und Schlüssel

Aktualisiert: 19. Juni 2015

Gilt für: Azure

Microsoft Azure Active Directory Access Control (auch als Access Control Service oder ACS bezeichnet) bietet zwei verschiedene Möglichkeiten zum Signieren und Verschlüsseln von Token: X.509-Zertifikate mit einem privaten Schlüssel und 256-Bit-symmetrischen Schlüsseln. 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. Um Tokensignierung, Verschlüsselung und Entschlüsselungszertifikate und Schlüssel hinzuzufügen und zu konfigurieren, verwenden Sie den ACS-Verwaltungsdienst oder das ACS-Verwaltungsportal.

Signieren von Token

ACS signiert alle Sicherheitstoken, die es mit einem X.509-Zertifikat (mit einem privaten Schlüssel) oder einem 256-Bit-symmetrischen Schlüssel hat. Die Wahl eines Anmeldeinformationentyps (Zertifikat oder Schlüssel) hängt von dem Tokenformat ab, das Sie für Ihre ACS-ausgestellten Token auswählen. Weitere Informationen finden Sie unter "Token signieren" in vertrauenden Parteianwendungen. 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.

Namespace oder dedizierte Zertifikate und Schlüssel

Sie können ein Signaturzertifikat oder einen symmetrischen Schlüssel so konfigurieren, dass sie für den gesamten Access Control Namespace oder nur für eine bestimmte vertrauende Parteianwendung im Namespace verwendet wird. Dabei besteht der folgende Unterschied:

  • Access Control Namespace – Wenn ein Signaturzertifikat oder ein Schlüssel für den gesamten Access Control Namespace konfiguriert ist, verwendet ACS das Zertifikat oder den Schlüssel zum Signieren von Token für alle vertrauenden Parteienanwendungen in diesem Namespace, die kein anwendungsspezifisches Zertifikat oder einen Schlüssel haben. Ein Namespacebereichszertifikat wird auch zum Signieren von ACS-WS-Federation Metadaten verwendet.

  • Dediziertes – Wenn Sie ein Signaturzertifikat oder einen Schlüssel für eine bestimmte vertrauende Parteianwendung konfigurieren, verwendet ACS das Signaturzertifikat oder den Schlüssel nur zum Signieren von Token, die an die angegebene vertrauende Parteianwendung übermittelt werden.

    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 Access Control Namespace, um Token für die Anwendung zu signieren.

Hinweis

  • 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 sicher von mehreren Anwendungen in einem Access Control Namespace freigegeben 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 verwalteten Namespaces.

  • Wenn Sie eine vertrauende Parteianwendung konfigurieren, die das X.509-Zertifikat für den Access Control Namespace verwendet, um JWT-Token zu signieren, werden Links zu dem Access Control Namespacezertifikat und dem Access Control Namespaceschlüssel auf der Seite für die Anwendung der vertrauenden Partei im ACS-Verwaltungsportal angezeigt. ACS verwendet jedoch nur das Namespacezertifikat, um Token für die vertrauende Parteianwendung zu signieren.

Signaturzertifikate werden in der Regel zum Signieren von Token für die Anwendungen vertrauender Seiten in einem Namespace verwendet. Die öffentliche Schlüsselkomponente eines Namespacesignaturzertifikats wird in den ACS-WS-Federation Metadaten veröffentlicht, die es vertrauenden Parteienanwendungen ermöglicht, ihre Konfiguration zu automatisieren. Die öffentlichen Schlüssel von Zertifikaten, die nur einer bestimmten vertrauenden Parteianwendung zugewiesen sind, sind nicht in den ACS-WS-Federation-Metadaten vorhanden und werden nur verwendet, wenn die unabhängige Kontrolle über das Signaturzertifikat einer vertrauenden Parteianwendung erforderlich ist.

Primäre Zertifikate und Schlüssel

In ACS können Sie mehrere Zertifikate und Schlüssel verwalten, aber nur bestimmte 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. Wenn Sie dies tun, wird ACS automatisch alle vorhandenen primären Zertifikate oder Schlüssel zu nicht primären Zertifikaten demotieren.

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 jedoch keine der Zertifikate (oder Schlüssel) primär ist, verwendet ACS das nicht primäre Zertifikat, das das früheste gültige Startdatum aufweist.

Die öffentliche Schlüsselkomponente sowohl primärer als auch nicht primärer Zertifikate wird in den ACS-WS-Federation Metadaten veröffentlicht, um programmgesteuerte Zertifikatrollover zu ermöglichen. ACS verwendet jedoch nur primäre Zertifikate und Schlüssel, um Token zu signieren.

Gültigkeits- und Ablaufdaten von Signaturschlüsseln

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.

Verschlüsselnde Token

In ACS können Sie entscheiden, alle SAML 1.1- oder SAML 2.0-Token zu verschlüsseln, die ACS für Ihre vertrauenden Parteianwendungen ausgibt.

Wichtig

ACS unterstützt keine Verschlüsselung von SWT- oder JWT-Token.

Die Tokenverschlüsselung ist für Webdienste erforderlich, die Eigentumsnachweistoken über das WS-Verbundprotokoll verwenden. Wenn Sie ACS verwenden, um die Authentifizierung für eine solche vertrauende Parteianwendung zu verwalten, müssen alle ACS-ausgestellten Token für diese vertrauende Parteianwendung verschlüsselt werden. 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 vertrauenden Parteianwendungen.

Entschlüsselungstoken

ACS kann verschlüsselte Token von WS-Federation Identitätsanbietern akzeptieren, z. B. . Der WS-Federation Identitätsanbieter empfängt den öffentlichen Schlüssel eines X.509-Zertifikats, wenn er WS-Federation Metadaten aus ACS importiert und diesen öffentlichen Schlüssel verwendet, um das Sicherheitstoken zu verschlüsseln, das an ACS weitergeleitet wird. ACS entschlüsselt das Token mithilfe des privaten Schlüssels dieses X.509-Zertifikats. Weitere Informationen finden Sie unter Vorgehensweise: Konfigurieren von AD FS 2.0 als Identitätsanbieter.

Primäre Tokenentschlüsselungszertifikate

Sie können mehrere Tokenschlüsselungszertifikate für eine vertrauende Parteianwendung oder Access Control Namespace verwalten. Wenn Sie ein Zertifikat als primär festlegen, verwendet ACS dieses Zertifikat, um die Token von WS-Federation Identitätsanbietern zu entschlüsseln, und verwendet nur nicht primäre Zertifikate, wenn der Versuch, das primäre Zertifikat zu verwenden, fehlschlägt.

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. Wenn Sie tun, wird ACS automatisch alle vorhandenen primären Entschlüsselungszertifikate zu nicht primärer Primärschlüsselungszertifikate demotieren.

ACS-Einschränkungen für X.509-Zertifikatsdateien

In ACS können X.509-Zertifikate, die nur eine öffentliche Schlüsseldatei (CER-Datei) enthalten, beim Erstellen einer Dienstidentität verwendet werden, eine Signatur eines Identitätsanbieters überprüfen oder SAML-Token verschlüsseln. X.509-Zertifikatdateien, die nur einen öffentlichen Schlüssel (CER-Datei) enthalten, müssen MIT ACS codiert werden. Base64-codierte Zertifikatdateien werden derzeit nicht unterstützt. Das Hochladen eines base64-codierten Zertifikats in 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 selbst signiert oder direkt an eine öffentliche Zertifizierungsstelle gekettet und verkettet werden. ACS funktioniert nicht mit Zertifikaten, die von einer privaten Zertifizierungsstelle ausgestellt werden.

Hinweis

X.509 Ceritificate, die in ACS importiert werden, dürfen nicht abgelaufen sein.

Abrufen eines X.509-Zertifikats

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 Sie ein Self-Signed Zertifikat – Sie können ihr eigenes selbst signiertes Zertifikat generieren, das mit ACS verwendet werden soll. Wenn Sie ein Windows basiertes Betriebssystem ausführen, können Sie MakeCert.exe verwenden, ein Tool, das im Microsoft Windows Software Development Kit (https://go.microsoft.com/fwlink/?LinkID=214104) enthalten ist, um ein selbst signiertes 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>

wo <service_namespace_name> der Name Ihres Access Control Namespace ist.

Anschließend können Sie den privaten Schlüssel aus Ihrem persönlichen Speicher als PFX-Datei exportieren und das ACS-Verwaltungsportal verwenden, um ihn in ACS hochzuladen.

Exportieren eines selbstsignierten Zertifikats

In diesen Anweisungen wird erläutert, wie Sie eine selbst signierte Zertifizierung von einem Computer exportieren, auf dem Windows 8, Windows Server 2012 oder .

So exportieren Sie ein selbstsigniertes Zertifikat

  1. Starten Sie MMC.exe, und fügen Sie das Zertifikat-Snap-In ihrer 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.

Gültige Daten von Zertifikaten und Schlüsseln

ACS wertet die Anfangs- und Endtermine (und Datumsangaben) von Zertifikaten und Schlüsseln in koordinierter Weltzeit (UTC) aus. Daher kann ACS schlüssel und Zertifikate als ungültig betrachten, auch wenn sie in der lokalen Uhrzeit des lokalen Computers 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 nicht ausgeben, da der Schlüssel oder das Zertifikat noch nicht gültig ist.

Weitere Informationen

Konzepte

ACS 2.0-Komponenten
Anwendungen von vertrauenden Parteien
Verwaltungsrichtlinien für Zertifikate und Schlüssel