Certificaten en sleutels

Bijgewerkt: 19 juni 2015

Van toepassing op: Azure

Microsoft Azure Active Directory Access Control (ook wel bekend als Access Control Service of ACS) biedt twee verschillende manieren om tokens te ondertekenen en te versleutelen: X.509-certificaten met een persoonlijke sleutel en 256-bits symmetrische sleutels. U kunt elk certificaat of elke sleutel configureren voor het ondertekenen van tokens voor bepaalde relying party-toepassingen of voor alle relying party-toepassingen in de naamruimte en u wijst certificaten en sleutels aan die primair of secundair zijn. Als u tokenondertekening, versleuteling en ontsleutelingscertificaten en sleutels wilt toevoegen en configureren, gebruikt u de ACS Management Service of de ACS-beheerportal.

Ondertekeningstokens

ACS ondertekent alle beveiligingstokens die het heeft met een X.509-certificaat (met een persoonlijke sleutel) of een 256-bits symmetrische sleutel. Uw keuze voor een handtekeningreferentietype (certificaat of sleutel) is afhankelijk van de tokenindeling die u selecteert voor uw DOOR ACS uitgegeven tokens. Zie Token-ondertekening in Relying Party-toepassingen voor meer informatie. Houd rekening met het volgende wanneer u selecteert welk type handtekeningreferentie u wilt maken:

• SAML-tokens worden ondertekend met X.509-certificaten. SAML is de standaardtokenindeling die wordt gebruikt door toepassingen die zijn gebouwd op de Windows Identity Foundation (WIF). SAML-tokens kunnen worden uitgegeven via meerdere protocollen, zoals WS-Federation en WS-Trust.

• SWT-tokens worden ondertekend met 256-bits symmetrische sleutels. SWT-tokens kunnen worden uitgegeven via meerdere protocollen, zoals OAuth WRAP en WS-Federation.

• JWT-tokens kunnen worden ondertekend door X.509-certificaten of 256-bits symmetrische sleutels. JWT-tokens kunnen worden uitgegeven via meerdere protocollen, zoals WS-Federation, WS-Trust en OAuth 2.0.

Naamruimte of toegewezen certificaten en sleutels

U kunt een handtekeningcertificaat of een symmetrische sleutel configureren, zodat het wordt gebruikt voor de volledige Access Control naamruimte of alleen voor een bepaalde relying party-toepassing in de naamruimte. Het verschil is als volgt:

• Access Control naamruimte: wanneer een handtekeningcertificaat of sleutel is geconfigureerd voor de volledige Access Control naamruimte, gebruikt ACS het certificaat of de sleutel om tokens te ondertekenen voor alle relying party-toepassingen in deze naamruimte die geen toepassingsspecifiek certificaat of sleutel hebben. Een naamruimtecertificaat wordt ook gebruikt voor het ondertekenen van ACS-WS-Federation metagegevens.

• Toegewezen: als u een handtekeningcertificaat of sleutel configureert dat moet worden gebruikt voor een bepaalde relying party-toepassing, gebruikt ACS het handtekeningcertificaat of de handtekeningsleutel alleen om tokens te ondertekenen die worden geleverd aan de opgegeven relying party-toepassing.

  Als u een toegewezen symmetrische sleutel maakt of invoert, gebruikt ACS de toegewezen sleutel om tokens voor de toepassing te ondertekenen. Als de toegewezen sleutel verloopt en niet wordt vervangen, gebruikt ACS de symmetrische sleutel voor de Access Control naamruimte om tokens voor de toepassing te ondertekenen.

Notitie

• Als best practice voor beveiliging maakt u bij het gebruik van symmetrische sleutels een toegewezen sleutel voor elke relying party-toepassing. Een X.509-certificaat kan veilig worden gedeeld door meerdere toepassingen in een Access Control naamruimte.
  
  
• Wanneer u een door Microsoft beheerde relying party-toepassing toevoegt aan een beheerde naamruimte, zoals het toevoegen van een Service Bus relying party-toepassing aan een Service Bus naamruimte, gebruikt u geen toepassingsspecifieke (toegewezen) certificaten of sleutels. Selecteer in plaats daarvan de ACS-optie om de certificaten en sleutels te gebruiken die zijn geconfigureerd voor alle toepassingen in de beheerde naamruimte. Gebruik toepassingsspecifieke certificaten en sleutels voor alle andere relying party-toepassingen. Zie Managed Namespaces voor meer informatie.
  
  
• Wanneer u een relying party-toepassing configureert die gebruikmaakt van het X.509-certificaat voor de Access Control-naamruimte om JWT-tokens te ondertekenen, worden koppelingen naar het Access Control naamruimtecertificaat en de Access Control naamruimtesleutel weergegeven op de pagina voor de relying party-toepassing in de ACS-beheerportal. ACS gebruikt echter alleen het naamruimtecertificaat om tokens te ondertekenen voor de relying party-toepassing.
  
  

Ondertekeningscertificaten worden doorgaans gebruikt om tokens te ondertekenen voor alle relying party-toepassingen in een naamruimte. Het openbare-sleutelonderdeel van een certificaat voor naamruimteondertekening wordt gepubliceerd in de ACS-WS-Federation metagegevens, waarmee relying party-toepassingen hun configuratie kunnen automatiseren. De openbare sleutels van certificaten die alleen zijn toegewezen aan een bepaalde relying party-toepassing, zijn niet aanwezig in de ACS-WS-Federation metagegevens en worden alleen gebruikt wanneer onafhankelijke controle over het handtekeningcertificaat van een relying party-toepassing is vereist.

Primaire certificaten en sleutels

In ACS kunt u verschillende certificaten en sleutels onderhouden, maar alleen aangewezen certificaten en sleutels gebruiken om tokens te ondertekenen. De certificaten en sleutels die zijn aangewezen voor ondertekening, worden primaire certificaten en sleutels genoemd.

Als u een certificaat of sleutel wilt aanwijzen als primair, selecteert u het primaire item maken op de pagina voor het certificaat of de sleutel. Als u een ander certificaat wilt aanwijzen als primair, selecteert u het primaire item maken op de pagina voor het andere certificaat of de andere sleutel. Wanneer u dit doet, degradeert ACS automatisch bestaande primaire certificaten of sleutels naar niet-primaire certificaten.

Wanneer ten minste één certificaat of sleutel primair is, worden niet-primaire certificaten en sleutels niet gebruikt voor ondertekening totdat ze door de beheerder worden gepromoveerd tot een primaire status, zelfs als het primaire certificaat of de primaire sleutel ongeldig is of is verlopen. Als geen van de certificaten (of sleutels) echter primair is, gebruikt ACS het niet-primaire certificaat met de vroegste geldige begindatum.

Het openbare-sleutelonderdeel van zowel primaire als niet-primaire certificaten wordt gepubliceerd in de ACS-WS-Federation metagegevens om programmatisch certificaatoverschakeling mogelijk te maken. ACS gebruikt echter alleen primaire certificaten en sleutels om tokens te ondertekenen.

Effectieve en vervaldatums van ondertekeningssleutels

Wanneer u 256-bits symmetrische ondertekeningssleutels toevoegt, moet u ook een effectieve datum en een vervaldatum opgeven. De ingangsdatum geeft de datum aan waarop deze sleutel van kracht wordt. De vervaldatum geeft de datum aan waarop deze sleutel verloopt en niet kan worden gebruikt om tokens te ondertekenen.

Tokens versleutelen

In ACS kunt u ervoor kiezen om elk SAML 1.1- of SAML 2.0-token te versleutelen dat ACS aan uw relying party-toepassingen uitgeeft.

Belangrijk

ACS biedt geen ondersteuning voor versleuteling van SWT- of JWT-tokens.

Tokenversleuteling is vereist voor webservices die gebruikmaken van proof-of-possession-tokens via het WS-Trust-protocol. Als u ACS gebruikt voor het beheren van verificatie voor een dergelijke relying party-toepassing, moeten alle DOOR ACS uitgegeven tokens voor deze relying party-toepassing worden versleuteld. In alle andere scenario's is tokenversleuteling optioneel.

ACS versleutelt SAML-tokens met behulp van een X.509-certificaat met een openbare sleutel (CER-bestand). Het token van de relying party-toepassing ontsleutelt het token met behulp van een persoonlijke sleutel voor dat X.509-certificaat. Zie Tokenversleuteling in Relying Party-toepassingen voor meer informatie.

Tokens ontsleutelen

ACS kan versleutelde tokens accepteren van WS-Federation id-providers, zoals . De WS-Federation id-provider ontvangt de openbare sleutel van een X.509-certificaat wanneer deze WS-Federation metagegevens uit ACS importeert en deze openbare sleutel gebruikt om het beveiligingstoken te versleutelen dat wordt doorgestuurd naar ACS. ACS ontsleutelt het token met behulp van de persoonlijke sleutel van dit X.509-certificaat. Zie Procedures voor meer informatie : AD FS 2.0 configureren als id-provider.

Primaire tokenontsleutelingscertificaten

U kunt meerdere tokenontsleutelingscertificaten onderhouden voor een relying party-toepassing of Access Control naamruimte. Wanneer u een certificaat als primair aanwijst, gebruikt ACS dat certificaat om de tokens van WS-Federation id-providers te ontsleutelen en gebruikt deze alleen niet-primaire certificaten als de poging om het primaire certificaat te gebruiken mislukt.

Als u een ontsleutelingscertificaat als primair wilt aanwijzen, selecteert u het primaire item maken op de pagina voor het certificaat. Als u een ander certificaat wilt toewijzen als primair, selecteert u het primaire item maken op de pagina voor het andere certificaat. Wanneer u dit doet, degradeert ACS alle bestaande primaire ontsleutelingscertificaten automatisch naar niet-primaire certificaten.

ACS-beperkingen voor X.509-certificaatbestanden

In ACS kunnen X.509-certificaten die alleen een openbare sleutel (CER-bestand) bevatten, worden gebruikt bij het maken van een service-id, het valideren van een handtekening van een id-provider of het versleutelen van SAML-tokens. X.509-certificaatbestanden die alleen een openbare sleutel (.cer-bestand) bevatten, moeten der-gecodeerd zijn om te worden gebruikt met ACS. Base64-gecodeerde certificaatbestanden worden momenteel niet ondersteund. Het uploaden van een base64-gecodeerd certificaat naar ACS resulteert in een validatiefout wanneer ACS een binnenkomend token ontvangt waarvoor dat certificaat is vereist.

In ACS moeten X.509-certificaten zelfondertekend zijn of rechtstreeks zijn ondertekend en gekoppeld aan een openbare certificeringsinstantie. ACS werkt niet met certificaten die zijn uitgegeven door een particuliere certificeringsinstantie.

Notitie

X.509-certificaten die in ACS worden geïmporteerd, mogen niet verlopen zijn.

Een X.509-certificaat verkrijgen

Er zijn verschillende manieren om een X.509-certificaat te verkrijgen voor tokenondertekening, tokenversleuteling of ontsleuteling. De methode die u gebruikt, is afhankelijk van uw vereisten en de hulpprogramma's die beschikbaar zijn in uw organisatie.

Commerciële certificeringsinstantie: u kunt een X.509-certificaat kopen bij een commerciële certificeringsinstantie.

Een Self-Signed-certificaat genereren: u kunt uw eigen zelfondertekende certificaat genereren voor gebruik met ACS. Als u een op Windows gebaseerd besturingssysteem uitvoert, kunt u MakeCert.exe gebruiken, een hulpprogramma dat is opgenomen in de Microsoft Windows Software Development Kit (https://go.microsoft.com/fwlink/?LinkID=214104) om een zelfondertekend certificaat te genereren.

Met de volgende opdracht wordt bijvoorbeeld een zelfondertekend certificaat gegenereerd in uw persoonlijke certificaatarchief.

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

waarbij <service_namespace_name> de naam van uw Access Control naamruimte is.

Vervolgens kunt u de persoonlijke sleutel exporteren uit uw persoonlijke archief als pfx-bestand en de ACS-beheerportal gebruiken om deze te uploaden naar ACS.

Een Self-Signed-certificaat exporteren

In deze instructies wordt uitgelegd hoe u een zelfondertekende certificering exporteert vanaf een computer met Windows 8, Windows Server 2012 of .

Uw zelfondertekende certificaat exporteren

1. Startmenu MMC.exe en voeg de module Certificaten toe aan uw MMC-console.

2. Dubbelklik op Certificaten - Huidige gebruiker, persoonlijk en vervolgens op Certificaten.

3. Klik met de rechtermuisknop op een certificaat, klik op Alle taken en klik vervolgens op Exporteren.

4. Klik op de welkomstpagina van de wizard Certificaat exporteren op Volgende.

5. Selecteer in de pagina Persoonlijke sleutel exporterenJa, de persoonlijke sleutel exporterenen klik op Volgende.

6. Klik op de pagina Bestandsindeling exporteren op Persoonlijke gegevens Exchange - PKCS #12 (. PFX).

7. Voer in de velden Wachtwoord een wachtwoord en bevestigingswachtwoord in en klik op Volgende.

8. Voer in het veld Bestandsnaam een pad en bestandsnaam in met de extensie .pfx en klik vervolgens op Volgende.

9. Klik op Voltooien.

Geldige datums van certificaten en sleutels

ACS evalueert de begin- en einddatums (en datums) van certificaten en sleutels in Coordinated Universal Time (UTC). Als gevolg hiervan kan ACS overwegen om sleutels en certificaten ongeldig te maken, zelfs wanneer ze geldig zijn in de lokale tijd van de lokale computer of in een andere tijdzone.

Om ervoor te zorgen dat het certificaat of de sleutel onmiddellijk geldig is, past u de datums aan in UTC-tijd. Anders kan ACS geen token uitgeven omdat de sleutel of het certificaat nog niet geldig is.

Zie ook

Concepten

ACS 2.0-onderdelen
Relying Party-toepassingen
Richtlijnen voor het beheer van certificaten en sleutels