Dela via

Certifikat och nycklar

  • Artikel

Uppdaterad: 19 juni 2015

Gäller för: Azure

Microsoft Azure Active Directory Access Control (även kallat Access Control Service eller ACS) erbjuder två olika sätt att signera och kryptera token: X.509-certifikat med en privat nyckel och 256-bitars symmetriska nycklar. Du kan konfigurera varje certifikat eller nyckel för att signera token för vissa förlitande partprogram eller för alla förlitande partprogram i namnområdet, och du anger att certifikat och nycklar ska vara primära eller sekundära. Om du vill lägga till och konfigurera certifikat och nycklar för tokensignering, kryptering och dekryptering använder du ACS-hanteringstjänsten eller ACS-hanteringsportalen.

Signeringstoken

ACS signerar alla säkerhetstoken som det har problem med med ett X.509-certifikat (med en privat nyckel) eller en 256-bitars symmetrisk nyckel. Ditt val av typ av signeringsautentiseringsuppgifter (certifikat eller nyckel) beror på vilket tokenformat du väljer för dina ACS-utfärdade token. Mer information finns i "Tokensignering" i förlitande partprogram. När du väljer vilken typ av signeringsautentiseringsuppgifter du vill skapa bör du tänka på följande:

  • SAML-token signeras med X.509-certifikat. SAML är standardtokenformatet som används av program som bygger på Windows Identity Foundation (WIF). SAML-token kan utfärdas över flera protokoll, till exempel WS-Federation och WS-Trust.

  • SWT-token signeras med 256-bitars symmetriska nycklar. SWT-token kan utfärdas över flera protokoll, till exempel OAuth WRAP och WS-Federation.

  • JWT-token kan signeras av X.509-certifikat eller 256-bitars symmetriska nycklar. JWT-token kan utfärdas över flera protokoll, till exempel WS-Federation, WS-Trust och OAuth 2.0.

Namnområde eller dedikerade certifikat och nycklar

Du kan konfigurera ett signeringscertifikat eller en symmetrisk nyckel så att det används för hela Access Control namnområdet eller endast för ett visst förlitande partprogram i namnområdet. Skillnaden är följande:

  • Access Control namnområde – När ett signeringscertifikat eller en nyckel har konfigurerats för hela Access Control namnrymd använder ACS certifikatet eller nyckeln för att signera token för alla förlitande partprogram i det här namnområdet som inte har något programspecifikt certifikat eller nyckel. Ett namnområdesomfattande certifikat används också för att signera ACS-WS-Federation metadata.

  • Dedikerad – Om du konfigurerar ett signeringscertifikat eller en nyckel som ska användas för ett visst förlitande partprogram använder ACS signeringscertifikatet eller nyckeln endast för att signera token som levereras till det angivna förlitande partprogrammet.

    Om du skapar eller anger en dedikerad symmetrisk nyckel använder ACS den dedikerade nyckeln för att signera token för programmet. Om den dedikerade nyckeln upphör att gälla och inte ersätts använder ACS den symmetriska nyckeln för Access Control namnområde för att signera token för programmet.

Anteckning

  • Bästa praxis för säkerhet är att när du använder symmetriska nycklar skapar du en dedikerad nyckel för varje förlitande partprogram. Ett X.509-certifikat kan på ett säkert sätt delas av flera program i ett Access Control namnområde.

  • När du lägger till ett Microsoft-hanterat förlitande partprogram i ett hanterat namnområde, till exempel lägga till ett Service Bus förlitande part-program i ett Service Bus namnområde, ska du inte använda programspecifika (dedikerade) certifikat eller nycklar. Välj i stället alternativet ACS för att använda de certifikat och nycklar som har konfigurerats för alla program i det hanterade namnområdet. Använd programspecifika certifikat och nycklar för alla andra förlitande partprogram. Mer information finns i Hanterade namnområden.

  • När du konfigurerar ett förlitande partprogram som använder X.509-certifikatet för Access Control namnområde för att signera JWT-token, visas länkar till Access Control namnområdescertifikat och Access Control namnområdesnyckel på sidan för det förlitande partprogrammet i ACS-hanteringsportalen. ACS använder dock bara namnområdescertifikatet för att signera token för det förlitande partprogrammet.

Signeringscertifikat används vanligtvis för att signera token för alla förlitande partprogram i ett namnområde. Den offentliga nyckelkomponenten i ett namnområdessigneringscertifikat publiceras i ACS-WS-Federation metadata, vilket gör det möjligt för förlitande partprogram att automatisera sin konfiguration. De offentliga nycklarna för certifikat som endast tilldelas till ett visst förlitande partprogram finns inte i ACS-WS-Federation metadata och används endast när oberoende kontroll över ett förlitande partsprograms signeringscertifikat krävs.

Primära certifikat och nycklar

I ACS kan du underhålla flera certifikat och nycklar, men endast använda avsedda certifikat och nycklar för att signera token. Certifikaten och nycklarna som är avsedda för signering kallas för primära certifikat och nycklar.

Om du vill ange ett certifikat eller en nyckel som primärt väljer du objektet Gör primärt på sidan för certifikatet eller nyckeln. Om du vill ange ett annat certifikat som primärt väljer du objektet Gör primärt på sidan för det andra certifikatet eller nyckeln. När du gör det degraderar ACS automatiskt alla befintliga primära certifikat eller nycklar till icke-primära.

När minst ett certifikat eller en nyckel är primärt används inte icke-primära certifikat och nycklar för signering förrän de befordras till primär status av administratören, även om det primära certifikatet eller nyckeln är ogiltig eller har upphört att gälla. Men om inget av certifikaten (eller nycklarna) är primärt använder ACS det icke-primära certifikat som har det tidigaste giltiga startdatumet.

Den offentliga nyckelkomponenten för både primära och icke-primära certifikat publiceras i ACS-WS-Federation metadata för att aktivera programmatisk certifikatförnyelse. ACS använder dock bara primära certifikat och nycklar för att signera token.

Giltighets- och förfallodatum för signeringsnycklar

När du lägger till 256-bitars symmetriska signeringsnycklar måste du också ange ett effektivt datum och ett förfallodatum. Det gällande datumet anger det datum då den här nyckeln börjar gälla. Förfallodatumet anger det datum då den här nyckeln upphör att gälla och kan inte användas för att signera token.

Kryptera token

I ACS kan du välja att kryptera alla SAML 1.1- eller SAML 2.0-token som ACS utfärdar till dina förlitande partprogram.

Viktigt

ACS stöder inte kryptering av SWT- eller JWT-token.

Tokenkryptering krävs för webbtjänster som använder proof-of-possession-token via WS-Trust-protokollet. Om du använder ACS för att hantera autentisering för ett sådant förlitande partprogram måste alla ACS-utfärdade token för det här förlitande partprogrammet krypteras. I alla andra scenarier är tokenkryptering valfritt.

ACS krypterar SAML-token med hjälp av ett X.509-certifikat som innehåller en offentlig nyckel (cer-fil). Den förlitande partens programtoken dekrypterar token med hjälp av en privat nyckel för X.509-certifikatet. Mer information finns i " Tokenkryptering" i förlitande partprogram.

Dekryptera token

ACS kan acceptera krypterade token från WS-Federation identitetsprovidrar, till exempel . den WS-Federation identitetsprovidern tar emot den offentliga nyckeln för ett X.509-certifikat när den importerar WS-Federation metadata från ACS och använder den här offentliga nyckeln för att kryptera säkerhetstoken som vidarebefordras till ACS. ACS dekrypterar token med hjälp av den privata nyckeln för det här X.509-certifikatet. Mer information finns i Så här konfigurerar du AD FS 2.0 som identitetsprovider.

Certifikat för dekryptering av primär token

Du kan underhålla flera tokendekrypteringscertifikat för ett förlitande partprogram eller Access Control namnområde. När du anger ett certifikat som primärt använder ACS certifikatet för att dekryptera token från WS-Federation identitetsprovidrar och använder endast icke-primära certifikat om försöket att använda det primära certifikatet misslyckas.

Om du vill ange ett dekrypteringscertifikat som primärt väljer du objektet Gör primärt på sidan för certifikatet. Om du vill ange ett annat certifikat som primärt väljer du objektet Gör primärt på sidan för det andra certifikatet. När du gör det degraderar ACS automatiskt alla befintliga primära dekrypteringscertifikat till icke-primära.

ACS-begränsningar för X.509-certifikatfiler

I ACS kan X.509-certifikat som endast innehåller en offentlig nyckel (cer-fil) användas när du skapar en tjänstidentitet, validerar en signatur för en identitetsprovider eller krypterar SAML-token. X.509-certifikatfiler som endast innehåller en offentlig nyckel (.cer-fil) måste vara DER-kodade för att användas med ACS. Base64-kodade certifikatfiler stöds för närvarande inte. Om du laddar upp ett base64-kodat certifikat till ACS resulterar det i ett valideringsfel när ACS tar emot en inkommande token som kräver certifikatet.

I ACS måste X.509-certifikat antingen vara självsignerade eller signerade och länkade direkt till en offentlig certifikatutfärdare. ACS fungerar inte med certifikat som utfärdas av en privat certifikatutfärdare.

Anteckning

X.509-certifikat som importeras till ACS får inte upphöra att gälla.

Hämta ett X.509-certifikat

Det finns flera sätt att hämta ett X.509-certifikat för tokensignering, tokenkryptering eller dekryptering. Vilken metod du använder beror på dina krav och vilka verktyg som är tillgängliga i din organisation.

Kommersiell certifikatutfärdare – Du kan köpa ett X.509-certifikat från en kommersiell certifikatutfärdare.

Generera ett Self-Signed certifikat – Du kan generera ett eget självsignerat certifikat som ska användas med ACS. Om du kör ett Windows-baserat operativsystem kan du använda MakeCert.exe, ett verktyg som ingår i Microsoft Windows Software Development Kit (https://go.microsoft.com/fwlink/?LinkID=214104) för att generera ett självsignerat certifikat.

Följande kommando genererar till exempel ett självsignerat certifikat i ditt personliga certifikatarkiv.

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

där <service_namespace_name> är namnet på ditt Access Control namnområde.

Du kan sedan exportera den privata nyckeln från ditt personliga arkiv som en PFX-fil och använda ACS-hanteringsportalen för att ladda upp den till ACS.

Exportera ett Self-Signed certifikat

De här anvisningarna beskriver hur du exporterar en självsignerad certifiering från en dator som kör Windows 8, Windows Server 2012, eller .

Exportera ditt självsignerade certifikat

  1. Starta MMC.exe och lägg till snapin-modulen Certifikat i MMC-konsolen.

  2. Dubbelklicka på Certifikat – Aktuell användare, Personlig och sedan Certifikat.

  3. Högerklicka på ett certifikat, klicka på Alla uppgifter och klicka sedan på Exportera.

  4. På sidan Välkommen till guiden Certifikatexport klickar du på Nästa.

  5. Välj Ja, exportera den privata nyckeln på sidan Exportera privat nyckeloch klicka sedan på Nästa.

  6. På sidan Exportera filformat klickar du på Personlig information Exchange – PKCS #12 (. PFX).

  7. I fälten Lösenord anger du ett lösenord och ett bekräftelselösenord och klickar sedan på Nästa.

  8. I fältet Filnamn anger du en sökväg och ett filnamn med filnamnstillägget .pfx och klickar sedan på Nästa.

  9. Klicka på Finish.

Giltiga datum för certifikat och nycklar

ACS utvärderar start- och slutdatum (och datum-tider) för certifikat och nycklar i Coordinated Universal Time (UTC). Därför kan ACS betrakta nycklar och certifikat som ogiltiga även om de är giltiga i den lokala tiden på den lokala datorn eller i en annan tidszon.

För att säkerställa att certifikatet eller nyckeln är giltigt omedelbart justerar du datumen till UTC-tid. Annars kan ACS misslyckas med att utfärda en token eftersom nyckeln eller certifikatet ännu inte är giltigt.

Se även

Begrepp

ACS 2.0-komponenter
Program från förlitande part
Riktlinjer för hantering av certifikat och nycklar