Table of contents
TOC
Minimera innehållsförteckningen
Maximera innehållsförteckningen

AD FS-scenarier för utvecklare

Bill Mathers|Senast uppdaterad: 2017-03-10
|
1 Medverkande

Gäller för: Windows Server 2016

AD FS i Windows Server 2016 [AD FS 2016] kan du lägga till industry standard OpenID ansluta och OAuth 2.0-baserad autentisering och auktorisering för program som du utvecklar och de program som autentiserar användare direkt mot AD FS.

AD FS 2016 har även stöd för WS-Federation, WS-Trust och SAML protokoll och profiler vi har funnits i tidigare versioner. Om du är intresserad av utvecklaren vägledning för dessa protokoll finns i den här artikeln. Den här artikeln att fokusera på hur du använder och dra nytta av nyare protokollstöd.

Varför Modern autentisering

Du kan fortsätta med AD FS för inloggning på WS-Federation, har WS-Trust och SAML-protokoll som du innan med nyare protokoll, får du följande fördelar:

  • Enkelhetens skull
    • Använd samma uppsättning API: er och mönster för att aktivera inloggning på för:
      • Flera typer av program (server, skrivbord, mobile, webbläsare)
      • Flera plattformar (android, iOS Windows)
      • Program i företagsnätverket eller finns i molnet
    • Använd samma uppsättning bibliotek som du kan redan använda du autentiserar användare mot AD Azure
  • Flexibilitet
    • Aktivera mer komplexa scenarier som förutom standardanvändare tillstånd:
      • ? 3-ledade inloggning flöden som en användare tillåter ett webbprogram eller en tjänst för att komma åt resurser som finns med en annan webbapp eller tjänst.
      • ? Server till server-flöden som en halva skikt tjänst får åtkomst till en backend API
      • ? JavaScript-baserade enkelsidig program (SPA)
  • Branschen support
    • OAuth 2.0 och OpenID ansluta Upplev bred användning i branschen, så kunskap om dessa mönster hjälper du aktivera autentisering och auktorisering utanför en Active Directory-miljö också

Så fungerar det: The grunderna

AD FS moderna autentisering kan du lägga till ditt program använder samma uppsättning verktyg och bibliotek som du redan kan använda för att autentisera användare mot Azure AD.

I AD FS-scenarier självklart är det AD FS och inte Azure AD som fungerar som identitetsprovider och auktorisering server. Annars begreppen är exakt likadana: användarna ange sina autentiseringsuppgifter och skaffa token, antingen direkt eller via en mellanhand för åtkomst till resurser.

Det vanligaste scenariot består av en användare eller "resursägaren", interagera med en webbläsare för att få åtkomst till ett webbprogram:

AD FS för utvecklare

Webbprogrammet kallas "klient" eftersom den initierar begäran till server för auktorisering (AD FS) för en åtkomsttoken till resursen. Resursen kan vara värd för själva webbappen eller vara tillgänglig som en webb-API någonstans i nätverket eller på internet. Användar- eller "resource ägare" auktoriserar klienten webbapp ta emot denna åtkomsttoken genom att tillhandahålla autentiseringsuppgifter till auktoriseringsservern.

Så fungerar det: komponenter

OAuth 2.0 och OpenID ansluta scenarier i AD FS kontrollera användningen av samma uppsättning verktyg och bibliotek som du använder Azure AD ID-provider. Dessa komponenter är:

  • Active Directory-autentisering Library (ADAL): klientbibliotek som förenklar insamling av användarautentiseringsuppgifter, skapa och skicka token begäranden och hämta de resulterande token.
  • OWIN (Öppna Webbgränssnitt för .NET) mellanprogramvara: medan OWIN är ett projekt för community-baserad, Microsoft har skapat en uppsättning server sida bibliotek för att skydda webbprogram och web API: erna med OpenID ansluta och OAuth 2.0

I diagrammet nedan visas roller av dessa komponenter:

AD FS för utvecklare

De här scenarierna grupprincipmodellering i AD FS 2016

Programgrupper

För att representera dessa scenarier i AD FS-principen har vi introducerat ett nytt koncept som kallas programgrupper. En programgrupp kan innehålla alla tal och en kombination av följande grundläggande typer av program:

Programgrupp / Application TypeBeskrivningRoll
ProgramspecifikaKallas ibland en offentlig klient och ska detta vara en klientapp som körs på en dator eller enhet med vilket användaren interagerar med.Begäranden token från auktoriseringsservern (AD FS) för åtkomst till resurser. Skickar HTTP-begäranden till skyddade resurser som använder token som HTTP-huvuden.
ServerprogrammetEtt program som körs på en server och som normalt är tillgängliga för användare via en webbläsare. Eftersom det kan hantera sina egna klienthemlighet eller autentiseringsuppgifter, kallas ibland en klient som konfidentiell.Begäranden token från auktoriseringsservern (AD FS) för åtkomst till resurser. Skickar HTTP-begäranden till skyddade resurser som använder token som HTTP-huvuden.
Webb-APIAvsluta resursen användaren ansluter till. Tänk på dessa som nya representation av "förlitande part".Använder token hämtas av klienter

Skillnader jämfört med AD FS 2012 R2

Programgrupper kombinera förtroende och auktorisering element som AD FS 2012 R2 visas separat, som förlitande part-klienter och behörigheter för program.

I följande tabell jämförs de metoder som motsvarande programobjekt förtroende skapas i AD FS 2012 R2 vs AD FS 2016:

AD FS i Windows Server 2012 R2I PowerShellHantering av AD FS
Lägga till ursprunglig-klientAdd-AdfsClientNA
Lägg till serverprogrammet som klientAdd-AdfsClientNA
Lägga till webb-API: et / resursAdd-AdfsRelyingPartyTrustSkapa förlitande part-förtroende
AD FS 2016I PowerShellHantering av AD FS
Lägga till ursprunglig-klientAdd-AdfsNativeClientApplicationLägga till egna program grupp
Lägg till serverprogrammet som klientAdd-AdfsServerApplicationLägga till program servergrupp
Lägga till webb-API: et / resursAdd-AdfsWebApiApplicationLägga till webb-API: et program grupp

Behörigheter för program och tillstånd

Som standard tillåts klienter i en programgrupp åtkomst till resurser i samma grupp. Administratören behöver inte konfigurera behörigheter för specifika program. Programgrupper även tillåta administratörer att ange scope tillåts, till exempel openid eller user_impersonation. Scenario beskrivningarna nedan ange exakt vilka scope som krävs för vilket scenario.

Eftersom AD FS använder en modell av administratören tillstånd kan ombeds användarna inte tillstånd vid åtkomst till resurser. En administratör kan gälla tillstånd för alla användare genom att konfigurera programgruppen.

Scenarier som stöds

I följande avsnitt beskrivs scenarier som vi stöder mer detaljerat.

Token som används för

Dessa scenarier gör användningen av tre typer av token:

  • id_token: A JWT-token som används för att representera användarens identitet. Av id_token 'aud' eller publik anspråket matchar klient-ID: T för automatisk eller server-programmet.
  • access_token: A JWT-token som används i Oauth och OpenID ansluta scenarier och är avsedda att användas av resursen. 'Aud' eller publik anspråk på denna token måste stämma med identifieraren för resursen eller webb-API: et.
  • refresh_token: skickas denna token i stället för insamling av användarautentiseringsuppgifter för att tillhandahålla enkel inloggning på upplevelse. Denna token är både utfärdas och används av AD FS och är inte kan läsas av klienter eller resurser.

Ursprunglig klient till webben API

Det här scenariot kan användare med en automatisk klientprogram för att anropa en AD FS 2016 skyddade webb-API: et.

  • Automatisk klientprogrammet använder ADAL för att skicka auktorisering och token som begär att AD FS att fråga efter autentiseringsuppgifter från användaren, om det behövs och skickar den resulterande token som ett HTTP-huvud i begäran till API: T för webben
  • [Den här delen är endast för demonstration] Webb-API läser anspråken från ClaimsPrincipal objektet som resultat från den åtkomsttoken som skickas från klienten och skickar dem till klienten.

Beskrivning av flödet för protokollet

  1. Automatisk klientprogrammet initierar flödet med ett anrop till ADAL-bibliotek. Detta utlöser en webbläsarbaserad HTTP GET till AD FS auktorisera slutpunkt:

Autentiseringsbegäran:
https://fs.contoso.com/adfs/oauth2/authorize?

ParameternVärde
response_type"code"
resursRP ID: T (ID) för webb-API: et i programgrupp
client_idklient-Id för programspecifika i programgruppen
redirect_uriOmdirigerings-URI för program som skapades i programgrupp

Auktorisering begäran svar:
Om användaren inte har loggat in innan uppmanas användaren att ange autentiseringsuppgifter.
AD FS svarar genom att returnera en auktoriseringskod som parametern "code" i frågekomponenten i redirect_uri. Exempel: HTTP/1.1 302 hitta platsen: http://redirect_uri:80/?code=<kod&gt;.

  1. Automatisk klienten skickar sedan koden och följande parametrar till slutpunkten för AD FS-token:

Token begäran:
POST https://fs.contoso.com/adfs/oautincludes

ParameternVärde
grant_type"authorization_code"
kodAuktoriseringskod från 1
resursRP ID: T (ID) för webb-API: et i programgrupp
client_idklient-Id för programspecifika i programgruppen
redirect_uriOmdirigerings-URI för program som skapades i programgrupp

Token begäran svar:
AD FS svarar med en HTTP-200 med access_token, refresh_token och id_token i meddelandetexten.

  1. Programspecifika sedan skickar access_token en del av ovanstående svaret som Authorization-huvud i HTTP-begäran till webb-API.

Beteendet för enkel inloggning

Efterföljande klienten begär inom 1 timme (som standard) access_token kommer fortfarande vara giltiga i cacheminnet och en ny begäran utlöser inte all trafik till AD FS. Access_token hämtas automatiskt från cacheminnet genom ADAL.

När åtkomsttoken upphör skickar ADAL automatiskt en token baserade uppdateringsbegäran till AD FS-token slutpunkten (hopp auktoriseringsbegäran automatiskt).
Uppdatera token begäran:
POST https://fs.contoso.com/adfs/oautincludes

ParameternVärde
grant_type"refresh_token"
resursRP ID: T (ID) för webb-API: et i programgrupp
client_idklient-Id för programspecifika i programgruppen
refresh_tokenUppdateringstoken som utfärdats av AD FS som svar på den ursprungliga åtkomsttoken begäran

Uppdatera token begäran svar:
Om uppdateringstoken finns i < SSO_period > resulterar begäran i en ny åtkomsttoken. Användaren behöver inte ange autentiseringsuppgifter. Mer information om enkel Inloggning inställningar Se AD FS enkel inloggning på inställningar

Om din uppdateringstoken har gått ut begäran resulterar i en HTTP 401 med felet "invalid_grant" och "error_description" "MSIS9615: mottagna refresh_token parameter uppdateringstoken har gått ut". I det här fallet skickar ADAL automatiskt nya auktoriseringsbegäran ser ut precis som #1 ovan.

Webbläsare för att Webbapp

I detta fall kan en användare med en webbläsare som behöver åtkomst till resurserna i ett webbprogram.
Det finns två scenarier som gör detta.

Konfidentiell OAuth-klient

Det här scenariot liknar ovanstående i att det finns en auktoriseringsbegäran, följt av en kod för token exchange. (Modelleras som en servertillämpning i AD FS) för webbprogram initierar auktoriseringsbegäran via webbläsaren och utbyter koden för token (genom att ansluta direkt till AD FS)

Beskrivning av flödet för protokollet

  1. Web App-initierar auktorisation begäran via webbläsaren, som skickar en HTTP GET till AD FS auktorisera slutpunkt
    Autentiseringsbegäran:
    https://fs.contoso.com/adfs/oauth2/authorize?
ParameternVärde
response_type"code"
resursRP ID: T (ID) för webb-API: et i programgrupp
client_idKlient-ID: T för programspecifika i programgruppen
redirect_uriOmdirigerings-URI för webbapp (serverprogrammet) i programgrupp

Auktorisering begäran svar:
Om användaren inte har loggat in innan uppmanas användaren att ange autentiseringsuppgifter.
AD FS svarar genom att returnera en auktoriseringskod som parametern "code" i frågekomponenten i redirect_uri, till exempel: HTTP/1.1 302 hitta platsen: https://webapp.contoso.com/?code=<kod&gt;.

  1. Till följd av ovanstående 302, webbläsaren initierar en HTTP GET till webbapp, till exempel: GET http://redirect_uri:80/?code=<kod&gt;.

  2. I det här läget initierar webbapp, efter att ha mottagit koden en begäran till AD FS token slutpunkt skickar följande
    Token begäran:
    POST https://fs.contoso.com/adfs/oautincludes

ParameternVärde
grant_type"authorization_code"
kodAuktoriseringskod från 2 ovan
resursRP ID: T (ID) för webb-API: et i programgrupp
client_idKlient-Id för webbapp (serverprogrammet) i gruppen
redirect_uriOmdirigerings-URI för webbapp (serverprogrammet) i programgrupp
client_secretHemligheten för webbapp (serverprogrammet) i programgruppen. Obs: Klientens autentiseringsuppgifter behöver inte vara en client_secret. AD FS stöder möjligheten att använda certifikat eller Windows-integrerad autentisering även.

Token begäran svar:
AD FS svarar med en HTTP-200 med access_token, refresh_token och id_token i meddelandetexten.
anspråk

  1. Webben programmet och sedan antingen förbrukar access_token en del av ovanstående svaret (i de fall där webbappen resursen) eller på annat sätt skickas som Authorization-huvud i HTTP-begäran till webben API.

Beteendet för enkel inloggning

När åtkomsttoken fortfarande är giltiga för 1 timme (som standard) på klientens cacheminne, kan du tror att andra begäran kommer att fungera som i ovanstående – scenario för-klienten att en ny begäran utlöser inga all trafik till AD FS som åtkomsttoken automatiskt ska hämtas från cacheminnet ADAL. Det är dock möjligt att webbapp kan skickar distinkta auktorisering och token-begäranden, tidigare via olika URL länkar, som i vårt exempel.

I det här fallet är det AD FS webbläsaren SSO cookien som gör att AD FS ska utfärda ett nytt auktoriseringskod utan att användaren tillfrågas om autentiseringsuppgifter. Webbapp sedan anrop till AD FS nya Auktoriseringskoden med en ny åtkomsttoken. Användaren behöver inte ange autentiseringsuppgifter.

I annat fall smarta om webbapp är tillräckligt för att veta om användaren redan har autentiserats auktorisera begäran kan du hoppa över och antingen:

  • Cachelagrade åtkomsttoken, om inte gått ut, hämtas och används, eller
  • En begäran token baserade begäran kan skickas till AD FS token slutpunkten som beskrivs nedan

Uppdatera token begäran:
POST https://fs.contoso.com/adfs/oautincludes

ParameternVärde
grant_type"refresh_token"
resursRP ID: T (ID) för webb-API: et i programgrupp
client_idKlient-Id för webbapp (serverprogrammet) i gruppen
refresh_tokenUppdatera token som utfärdas av AD FS som svar på den ursprungliga åtkomsttoken begäran
client_secretHemligheten för webbapp (serverprogrammet) i programgruppen

Uppdatera token begäran svar:
Om uppdateringstoken finns i < SSO_period > resulterar begäran i en ny åtkomsttoken. Användaren behöver inte ange autentiseringsuppgifter. Mer information om enkel Inloggning inställningar Se AD FS enkel inloggning på inställningar

Om din uppdateringstoken har gått ut begäran resulterar i en HTTP 401 med felet "invalid_grant" och "error_description" "MSIS9615: mottagna refresh_token parameter uppdateringstoken har gått ut". I det här fallet skickar ADAL automatiskt nya auktoriseringsbegäran ser ut precis som #1 ovan.

Anslut OpenID: Hybrid flödet

Det här scenariot liknar ovanstående i som det initieras en auktoriseringsbegäran av webbapp via webbläsaren omdirigering och en kod för token-utbyte från webbapp AD FS. Skillnaden i det här scenariot är att AD FS utfärdar en id_token som en del av det ursprungliga tillstånd begäran svaret.

Beskrivning av flödet för protokollet

  1. Web App-initierar auktorisation begäran via webbläsaren, som skickar en HTTP GET till AD FS auktorisera slutpunkt

Autentiseringsbegäran:
https://fs.contoso.com/adfs/oauth2/authorize?

ParameternVärde
response_type"kod + id_token"
response_mode"form_post"
resursRP ID: T (ID) för webb-API: et i programgrupp
client_idKlient-Id för webbapp (serverprogrammet) i gruppen
redirect_uriOmdirigerings-URI för webbapp (serverprogrammet) i gruppen

Auktorisering begäran svar:
Om användaren inte har loggat in innan uppmanas användaren att ange autentiseringsuppgifter.
AD FS svarar med HTTP-200 och formulär som innehåller de dolda element som nedan:

  • kod: auktoriseringskod
  • id_token: en JWT-token som innehåller anspråk som beskriver användarautentiserings
  • Formuläret skickar automatiskt till redirect_uri av webbapp, skicka koden och id_token till webbapp.
  1. I det här läget initierar webbapp, efter att ha mottagit koden en begäran till AD FS token slutpunkt skickar följande

Token begäran:
POST https://fs.contoso.com/adfs/oautincludes

ParameternVärde
grant_type"authorization_code"
kodAuktoriseringskod ovanifrån
resursRP ID: T (ID) för webb-API: et i programgrupp
client_idKlient-Id för webbapp (serverprogrammet) i gruppen
redirect_uriOmdirigerings-URI för webbapp (serverprogrammet) i programgrupp
client_secretHemligheten för webbapp (serverprogrammet) i programgruppen

Token begäran svar:
AD FS svarar med en HTTP-200 med access_token, refresh_token och id_token i meddelandetexten.

  1. Webben programmet och sedan antingen förbrukar access_token en del av ovanstående svaret (i de fall där webbappen resursen) eller på annat sätt skickas som Authorization-huvud i HTTP-begäran till webben API.

Beteendet för enkel inloggning

Enkel inloggning beteendet är samma som för Oauth 2.0 konfidentiell klienten flödet ovan.

För

I det här scenariot används en webbapp ursprungliga åtkomsttoken från en användare kan begära och erhålla en annan åtkomsttoken för en annan webbplats API som webbapp sedan kommer åt som slutanvändaren. Detta kallas "för"-flödet.

Beskrivning av flödet för protokollet

Steg 1 och 2 fungerar precis som steg 3 och 4 i föregående flödet.
I steg 3 är det viktigaste kravet att parametern client_id klient-ID: T för webbapp 2, måste matcha RP-ID för webben API: et A. Med andra ord måste målgruppen för åtkomsttoken som utbyts för den nya token som matcha klient-ID: T för den entitet som begär den nya token.

Relaterat innehåll

Se utveckling av AD FS för en fullständig lista över hanteringspaketen artiklar som ger stegvisa instruktioner om hur du använder relaterade flöden.

© 2017 Microsoft