Table of contents
TOC
De inhoudsopgave samenvouwen
De inhoudsopgave uitvouwen

AD FS-scenario's voor ontwikkelaars

Bill Mathers|Laatst bijgewerkt: 10-3-2017
|
1 Inzender

Van toepassing op: WindowsServer 2016

AD FS in Windows Server 2016 [AD FS 2016] kunt u branche standaard OpenID verbinden en OAuth 2.0 gebaseerde verificatie en autorisatie voor toepassingen die u ontwikkelt toevoegen en deze verifiëren van gebruikers aan de hand AD FS rechtstreeks toepassingen hebt.

AD FS 2016 biedt ook ondersteuning voor de WS-Federation, WS-Trust en SAML protocollen en -profielen we hebben ondersteund in eerdere versies. Als u geïnteresseerd in de handleiding voor ontwikkelaars voor deze protocollen bent, Zie het artikel hier. In dit artikel wordt de nadruk gelegd op het gebruik en profiteren van de nieuwere Protocolondersteuning.

Waarom moderne authenticatie

U kunt doorgaan met behulp van AD FS voor aanmelding op met de WS-Federation, hebben WS-Trust en SAML-protocollen net zoals u voordat u met de nieuwere protocollen, krijgt u de volgende voordelen:

  • Eenvoud en consistentie
    • Gebruik dezelfde set API's en patronen voor aanmelding inschakelen voor:
      • Meerdere typen van toepassingen (server, bureaublad, mobiele, browser)
      • Meerdere platforms (android, iOS, Windows)
      • Toepassingen binnen het bedrijfsnetwerk of gehost in de cloud
    • Gebruik dezelfde set bibliotheken die u al gebruiken om te verifiëren van gebruikers aan de hand Azure AD
  • Flexibiliteit
    • Naast de standaardgebruiker autorisatie, schakelt u complexere scenario's zoals:
      • ? 3-legged aanmelding stromen waarin een gebruiker een webtoepassing of service voor toegang tot bronnen die zich met een andere web-app of service bevinden toestaat.
      • ? Server-naar-server stromen waarin een halverwege tier-service toegang heeft tot een back-end API
      • ? JavaScript op basis van één pagina toepassingen (SPA)
  • Industrie-ondersteuning
    • OAuth 2.0 en OpenID verbinding genieten van wide gebruik in de industrie, dus kennis van deze patronen helpt u inschakelen verificatie en autorisatie buiten een Active Directory-omgeving ook

Hoe het werkt: de basisbeginselen

U kunt AD FS moderne authenticatie toevoegen aan uw toepassing met behulp van dezelfde set hulpprogramma's en bibliotheken die u al gebruiken om te verifiëren van gebruikers aan de hand Azure AD.

In scenario's voor AD FS natuurlijk is AD FS en geen Azure AD die als de id-provider en autorisatie fungeert server. Anders de concepten identiek zijn: gebruikers hun referenties en verkrijgen van tokens, rechtstreeks of via tussenkomst voor toegang tot bronnen.

Het eenvoudigste scenario bestaat uit een gebruiker of 'resource-eigenaar, interactie met een browser toegang krijgen tot een webtoepassing:

AD FS voor ontwikkelaars

De webtoepassing is een 'client' genoemd, omdat deze de aanvraag voor de autorisatie-server (AD FS) geïnitieerd voor een toegangstoken voor de resource. De bron kan worden gehost door de web-app zelf mogelijk of toegankelijk als een web-API ergens op het netwerk of internet. De gebruiker of 'resource-eigenaar machtigt de web-clientapp ontvangt die toegangstoken referenties op met de autorisatie-server.

Hoe het werkt: onderdelen

OAuth 2.0 OpenID verbinding maken met scenario's en in AD FS maken gebruik van dezelfde set hulpprogramma's en bibliotheken die u gebruikt wanneer Azure AD de id-provider. Deze onderdelen zijn:

  • Active Directory Authentication Library (ADAL): clientbibliotheken die vergemakkelijken gebruikersreferenties verzamelen, maken en token aanvragen indienen en de resulterende tokens ophalen.
  • OWIN (Open Web Interface voor .NET) middleware: terwijl OWIN is een project op basis van community, Microsoft is gemaakt een set van server side-bibliotheken die voor het beveiligen van webtoepassingen en -API's met OpenID verbinding en OAuth 2.0

De functies van deze onderdelen worden weergegeven in het onderstaande diagram:

AD FS voor ontwikkelaars

Deze scenario's modelleren in AD FS 2016

Toepassingsgroepen

Voor deze scenario's in AD FS-beleid, hebben we een nieuw concept voor toepassingsgroepen aangeroepen geïntroduceerd. Een groep van toepassingen kan bevatten een aantal en de combinatie van de volgende fundamentele typen van toepassing:

Toepassingsgroep / toepassing TypBeschrijvingFunctie
Systeemeigen toepassingEen openbare client genoemd, is dit bedoeld als een clientapp die wordt uitgevoerd op een pc of apparaat en die de gebruiker de interactie.Aanvragen tokens van de autorisatie-server (AD FS) voor de gebruikerstoegang tot bronnen. HTTP-aanvragen verzendt tot beveiligde bronnen, met behulp van de tokens als HTTP-headers.
ServertoepassingEen webtoepassing die wordt uitgevoerd op een server en in het algemeen toegankelijk is voor gebruikers via een browser. Omdat het is geschikt is voor eigen geheim' client' of de referentie onderhouden, is het soms een vertrouwelijk client genoemd.Aanvragen tokens van de autorisatie-server (AD FS) voor de gebruikerstoegang tot bronnen. HTTP-aanvragen verzendt tot beveiligde bronnen, met behulp van de tokens als HTTP-headers.
Web-APIDe resource einde de gebruiker wordt geopend. Beschouw dit als de nieuwe representatie van 'relying party's '.Verbruikt tokens die zijn verkregen door clients

Verschillen van AD FS 2012 R2

Toepassingsgroepen worden gecombineerd vertrouwt en autorisatie-elementen die AD FS 2012 R2 als relying party's, clients en Toepassingsmachtigingen afzonderlijk weergegeven.

De volgende tabellen worden de methoden waarmee overeenkomstige toepassing vertrouwensrelatie objecten worden gemaakt in AD FS 2012 R2 AD FS 2016 vs vergeleken:

AD FS in Windows Server 2012 R2In PowerShellAD FS-Management
Native client toevoegenAdd-AdfsClientNA
Servertoepassing toevoegen als de clientAdd-AdfsClientNA
Web-API toevoegen / resourceAdd-AdfsRelyingPartyTrustRelying Party-vertrouwensrelatie maken
AD FS 2016In PowerShellAD FS-Management
Native client toevoegenAdd-AdfsNativeClientApplicationSysteemeigen toepassing groep toevoegen
Servertoepassing toevoegen als de clientAdd-AdfsServerApplicationServergroep toepassingen toevoegen
Web-API toevoegen / resourceAdd-AdfsWebApiApplicationWeb-API toepassing groep toevoegen

Toepassingsmachtigingen en toestemming

Standaard worden de clients in een groep van toepassingen toegestaan voor toegang tot de bronnen in dezelfde groep. De beheerder heeft geen machtigingen voor een specifieke toepassing configureren. Toepassingsgroepen kunnen ook beheerders de bereiken die is toegestaan, zoals openid of user_impersonation opgeven. De onderstaande scenario beschrijvingen opgeven precies welke bereiken zijn vereist voor welke scenario.

Omdat een model van de administrator toestemming gebruikmaakt van AD FS, worden gebruikers niet gevraagd om toestemming bij het openen van bronnen. Door het configureren van de groep van toepassingen, biedt de beheerder van kracht toestemming voor alle toepassingsgebruikers.

Ondersteunde scenario 's

De volgende sectie worden de scenario's die wordt ondersteund in meer detail beschreven.

Tokens die worden gebruikt

Deze scenario's maken gebruik van de drie typen van token:

  • id_token: een JWT-token gebruikt voor de identiteit van de gebruiker. De claim 'aud' of de doelgroep van het id_token komt overeen met de client-ID van de toepassing systeemeigen of de server.
  • access_token: een JWT-token gebruikt in Oauth- en OpenID verbinding maken met scenario's en bedoeld om te worden verbruikt door de resource. De claim 'aud' of de doelgroep van dit token moet overeenkomen met de id van de resource of Web-API.
  • refresh_token: dit token wordt verzonden in plaats van gebruikersreferenties te bieden van eenmalige aanmelding van ervaring verzamelen. Dit token is verleend en die worden gebruikt door AD FS en kan niet worden gelezen door clients of resources.

Native client naar de Web-API

Dit scenario kan de gebruiker van een clienttoepassing native een AD FS 2016 beveiligd Web API aan te roepen.

  • De systeemeigen clienttoepassing ADAL gebruikt voor het verzenden van autorisatie en token te vragen om referenties van de gebruiker indien nodig, AD FS en vervolgens verzendt het resulterende token als een HTTP-header op de aanvraag voor de Web-API
  • [Dit onderdeel is alleen ter demonstratie] De web-API leest de claims in het ClaimsPrincipal-object dat wordt veroorzaakt door het toegangstoken verzonden door de client en stuurt ze terug naar de client.

Beschrijving van het protocol stroom

  1. De toepassing native client initieert de stroom met een oproep naar de ADAL-bibliotheek. Dit activeert een browsergebaseerde endpoint HTTP GET voor de AD FS toestaan:

Autorisatieaanvraag:
GET https://fs.contoso.com/adfs/oauth2/authorize?

ParameterWaarde
response_type"code"
resourceRP-ID (id) van Web-API in de groep van toepassingen
client_idclient-Id van de oorspronkelijke toepassing in de groep van toepassingen
redirect_uriOmleidings-URI van bedrijfseigen toepassing die in de groep van toepassingen

Reactie van autorisatie-aanvraag:
Als de gebruiker is niet aangemeld voordat de gebruiker wordt gevraagd om referenties.
AD FS antwoordt door een autorisatiecode retourneren als de parameter "code" in de queryonderdeel van de redirect_uri. Bijvoorbeeld: HTTP/1.1 302 gevonden locatie: http://redirect_uri:80/?code=<code&gt;.

  1. De native client stuurt de code, samen met de volgende parameters met het eindpunt van de AD FS-token:

Tokenaanvraag:
POST https://fs.contoso.com/adfs/oautincludes

ParameterWaarde
grant_type'authorization_code'
codeAutorisatiecode van 1
resourceRP-ID (id) van Web-API in de groep van toepassingen
client_idclient-Id van de oorspronkelijke toepassing in de groep van toepassingen
redirect_uriOmleidings-URI van bedrijfseigen toepassing die in de groep van toepassingen

Tokenaanvraag reactie:
AD FS reageert met een HTTP-200 met access_token, refresh_token en id_token in de hoofdtekst.

  1. De systeemeigen toepassing wordt vervolgens verzendt het access_token deel van de bovenstaande reactie als de autorisatie-header in de HTTP-aanvraag naar de web-API.

Eenmalige aanmelding gedrag

Volgende client vraagt binnen 1 uur (standaard) de access_token wordt nog steeds geldig in de cache en een nieuwe aanvraag wordt al het verkeer naar AD FS niet geactiveerd. De access_token worden automatisch opgehaald uit de cache door ADAL.

Nadat het toegangstoken is verlopen, worden ADAL een vernieuwing op basis tokenaanvraag automatisch verzonden naar de AD FS-token-eindpunt (de autorisatieaanvraag automatisch overslaan).
Tokenaanvraag vernieuwen:
POST https://fs.contoso.com/adfs/oautincludes

ParameterWaarde
grant_type'refresh_token'
resourceRP-ID (id) van Web-API in de groep van toepassingen
client_idclient-Id van de oorspronkelijke toepassing in de groep van toepassingen
refresh_tokenHet vernieuwingstoken dat is uitgegeven door AD FS in reactie op de eerste tokenaanvraag

Vernieuwen tokenaanvraag reactie:
Als het vernieuwingstoken binnen < SSO_period >, leidt de aanvraag in een nieuwe toegangstoken. De gebruiker wordt niet gevraagd om referenties. Voor meer informatie over SSO instellingen Zie AD FS één teken op instellingen

Als het vernieuwingstoken is verlopen, wordt de aanvraag resulteert in een 401 HTTP met fout "invalid_grant" en "error_description" "MSIS9615: het vernieuwingstoken dat is ontvangen in de parameter refresh_token is verlopen '. In dit geval verzendt ADAL automatisch een nieuwe autorisatieaanvraag die net zoals #1 hierboven.

Webbrowser voor Web-app

In dit scenario moet een gebruiker met een browser toegang krijgen tot bronnen die worden gehost door een webtoepassing.
Er zijn twee scenario's die u kunt dit doen.

Vertrouwelijke OAuth-client

Dit scenario is vergelijkbaar met het bovenstaande in dat er een autorisatieaanvraag, gevolgd door een code voor token exchange. De web-app (gemodelleerd als een servertoepassing in AD FS) start de autorisatieaanvraag via de browser en de code voor het token uitwisselt (door rechtstreeks verbinding maken met AD FS)

Beschrijving van het protocol stroom

  1. De Web-app initieert een machtiging vragen via de browser, die een HTTP GET verzendt naar de AD FS toestaan endpoint
    Autorisatieaanvraag:
    GET https://fs.contoso.com/adfs/oauth2/authorize?
ParameterWaarde
response_type"code"
resourceRP-ID (id) van Web-API in de groep van toepassingen
client_idClient-Id van de oorspronkelijke toepassing in de groep van toepassingen
redirect_uriOmleidings-URI van web-app (servertoepassing) in de groep van toepassingen

Reactie van autorisatie-aanvraag:
Als de gebruiker is niet aangemeld voordat de gebruiker wordt gevraagd om referenties.
AD FS reageert door een autorisatiecode bijvoorbeeld als de parameter "code" in de queryonderdeel van de redirect_uri terug te keren: HTTP/1.1 302 gevonden locatie: https://webapp.contoso.com/?code=<code&gt;.

  1. Als gevolg van de bovenstaande 302 de browser initieert een HTTP GET naar de web-app, bijvoorbeeld: GET http://redirect_uri:80/?code=<code&gt;.

  2. Op dit moment initieert de web-app ontvangst van de code wordt een aanvraag voor de AD FS-token-eindpunt verzenden van de volgende
    Tokenaanvraag:
    POST https://fs.contoso.com/adfs/oautincludes

ParameterWaarde
grant_type'authorization_code'
codeAutorisatiecode uit 2 hierboven
resourceRP-ID (id) van Web-API in de groep van toepassingen
client_idClient-Id van de web-app (servertoepassing) in de groep van toepassingen
redirect_uriOmleidings-URI van web-app (servertoepassing) in de groep van toepassingen
client_secretGeheim van de web-app (servertoepassing) in de groep van toepassingen. Opmerking: De referentie van de client niet hoeft te worden van een client_secret. AD FS ondersteunt de mogelijkheid om te gebruiken ook certificaten of geïntegreerde Windows-verificatie.

Tokenaanvraag reactie:
AD FS reageert met een HTTP-200 met access_token, refresh_token en id_token in de hoofdtekst.
claims

  1. Het web toepassing vervolgens ofwel het access_token deel van het bovenstaande antwoord (in het geval waarin de web-app zelf als host de bron fungeert) verbruikt of anderszins verzonden als de autorisatie-header in de HTTP-aanvraag naar de web-API.

Eenmalige aanmelding gedrag

Terwijl het toegangstoken nog steeds geldig 1 uur (standaard) in de clientcache, mag u denkt dat de tweede aanvraag werkt zoals in de bovenstaande - native client-scenario dat een nieuwe aanvraag niet al het verkeer naar AD FS wordt geactiveerd als het toegangstoken automatisch worden opgehaald uit de cache door ADAL. Het is echter mogelijk dat de web-app kunt verzendt verschillende autorisatie en token aanvragen, de oude via verschillende URL koppelen, zoals in ons voorbeeld.

In dit geval is de AD FS browser SSO cookie waarmee AD FS en uitgeven van een nieuwe autorisatiecode zonder tussenkomst van de gebruiker om referenties. De web-app wordt vervolgens roept voor AD FS voor het uitwisselen van de nieuwe autorisatiecode voor een nieuwe toegangstoken. De gebruiker wordt niet gevraagd om referenties.

Als de web-app smart anders voldoende weten dat als de gebruiker is al geverifieerd, de aanvraag machtigen worden overgeslagen en beide:

  • Het in de cache toegangstoken als niet is verlopen, is opgehaald en gebruikt, of
  • Een aanvraag gebaseerde tokenaanvraag kan worden verzonden naar het eindpunt van de AD FS-token, zoals hieronder wordt beschreven

Tokenaanvraag vernieuwen:
POST https://fs.contoso.com/adfs/oautincludes

ParameterWaarde
grant_type'refresh_token'
resourceRP-ID (id) van Web-API in de groep van toepassingen
client_idClient-Id van de web-app (servertoepassing) in de groep van toepassingen
refresh_tokenToken dat is uitgegeven door AD FS in reactie op de eerste tokenaanvraag vernieuwen
client_secretGeheim van de web-app (servertoepassing) in de groep van toepassingen

Vernieuwen tokenaanvraag reactie:
Als het vernieuwingstoken binnen < SSO_period >, leidt de aanvraag in een nieuwe toegangstoken. De gebruiker wordt niet gevraagd om referenties. Voor meer informatie over SSO instellingen Zie AD FS één teken op instellingen

Als het vernieuwingstoken is verlopen, wordt de aanvraag resulteert in een 401 HTTP met fout "invalid_grant" en "error_description" "MSIS9615: het vernieuwingstoken dat is ontvangen in de parameter refresh_token is verlopen '. In dit geval verzendt ADAL automatisch een nieuwe autorisatieaanvraag die net zoals #1 hierboven.

OpenID Connect: Hybride stroom

Dit scenario is vergelijkbaar met het bovenstaande in dat er een autorisatieaanvraag wordt geïnitieerd door de web-app via de browser-omleiding en een code voor token uitwisseling van de web-app met AD FS. Het verschil in dit scenario is dat AD FS problemen met een id_token als onderdeel van het antwoord eerste autorisatie-aanvraag.

Beschrijving van het protocol stroom

  1. De Web-app initieert een machtiging vragen via de browser, die een HTTP GET verzendt naar de AD FS toestaan endpoint

Autorisatieaanvraag:
GET https://fs.contoso.com/adfs/oauth2/authorize?

ParameterWaarde
response_type'code + id_token'
response_mode'form_post'
resourceRP-ID (id) van Web-API in de groep van toepassingen
client_idClient-Id van de web-app (servertoepassing) in de groep van toepassingen
redirect_uriOmleidings-URI van web-app (servertoepassing) in de groep van toepassingen

Reactie van autorisatie-aanvraag:
Als de gebruiker is niet aangemeld voordat de gebruiker wordt gevraagd om referenties.
AD FS reageert met een HTTP-200 en formulier die de hieronder als verborgen elementen:

  • code: de autorisatiecode
  • id_token: een JWT-token met claims met een beschrijving van de verificatie van gebruiker
  • Het formulier berichten automatisch aan de redirect_uri van de web-app, de code en de id_token verzenden naar de web-app.
  1. Op dit moment initieert de web-app ontvangst van de code wordt een aanvraag voor de AD FS-token-eindpunt verzenden van de volgende

Tokenaanvraag:
POST https://fs.contoso.com/adfs/oautincludes

ParameterWaarde
grant_type'authorization_code'
codeVan bovenstaande autorisatiecode
resourceRP-ID (id) van Web-API in de groep van toepassingen
client_idClient-Id van de web-app (servertoepassing) in de groep van toepassingen
redirect_uriOmleidings-URI van web-app (servertoepassing) in de groep van toepassingen
client_secretGeheim van de web-app (servertoepassing) in de groep van toepassingen

Tokenaanvraag reactie:
AD FS reageert met een HTTP-200 met access_token, refresh_token en id_token in de hoofdtekst.

  1. Het web toepassing vervolgens ofwel het access_token deel van het bovenstaande antwoord (in het geval waarin de web-app zelf als host de bron fungeert) verbruikt of anderszins verzonden als de autorisatie-header in de HTTP-aanvraag naar de web-API.

Eenmalige aanmelding gedrag

De eenmalige aanmelding gedrag is hetzelfde als de bovenstaande Oauth 2.0 vertrouwelijke client stroom.

Namens

In dit scenario een web-app gebruikmaakt van het oorspronkelijke toegangstoken van een gebruiker aanvragen en een andere toegangstoken verkrijgen voor een andere Web-API, waarmee de web-app vervolgens toegang de eindgebruiker tot wordt. Dit is een stroom "op namens van" genoemd.

Beschrijving van het protocol stroom

Stap 1 en 2 werken net als stappen 3 en 4 in de vorige stroom.
In stap 3 is is de belangrijkste vereiste dat de parameter client_id, de client-ID van de Web-app 2, moet overeenkomen met de RP-ID van de Web-API A. Met andere woorden, de client-ID van de entiteit aanvragen van het nieuwe token moet overeenkomen met de doelgroep van het toegangstoken voor het nieuwe token wordt uitgewisseld.

Gerelateerde inhoud

Zie AD FS-ontwikkeling voor de volledige lijst van overzicht artikelen die vindt u stapsgewijze instructies over het gebruik van de verwante stromen.

© 2017 Microsoft