Delen via


Active Directory en verificatie op basis van claims

 

Gepubliceerd: januari 2017

Is van toepassing op: Dynamics 365 (online), Dynamics 365 (on-premises), Dynamics CRM 2016, Dynamics CRM Online

Op claims gebaseerde verificatie biedt een beveiligingsprotocol volgens industrienormen om een gebruiker op een hostcomputer te verifiëren. Op claims gebaseerde verificatie is een reeks WS-* standaarden die het gebruik van een Security Assertion Markup Language (SAML) token in passieve modus (indien WS-federatie wordt gebruikt met de Microsoft Dynamics 365 (online en on-premises) webtoepassing) of actieve modus (waarbij WS-trust wordt gebruikt met Windows Communication Foundation (WCF) clients.) Deze verificatie werkt samen met WCF om beveiligde gebruikersverificatie te bieden en een communicatiekanaal met een Microsoft Dynamics 365 server. Alle Microsoft Dynamics 365 versies ondersteunen op claims gebaseerde verificatie.

Op claims gebaseerde verificatie vereist de beschikbaarheid van een beveiligingstokenservice (STS) die op een server wordt uitgevoerd. Een STS-server kan zijn gebaseerd op Active Directory Federation Services (AD FS) V2 of een platform dat het officiële STS-protocol biedt. Zie voor meer informatie het volgende onderwerp in de documentatie voor Dynamics 365-installatie en -beheer: TechNet: IFD configureren voor Microsoft Dynamics CRM 2015.

In dit onderwerp

Ondersteuning van op verificatie gebaseerde scenario's

Niet-ondersteunde verificatiescenario's

Verificatieklasses

Verificatie door de clientproxyklasses te gebruiken

Kanaaluitzonderingen en fouten verwerken

Aanvullende informatie over het veiligheidstoken (SAML)

Ondersteuning van op verificatie gebaseerde scenario's

Microsoft Dynamics 365 ondersteunt de volgende verificatiescenario's voor elk installatietype.

Installatie

Verificatiemodel

Microsoft Dynamics 365 (online)

Op claims gebaseerde Active Directory (via federatie) verificatie

Microsoft Dynamics 365 on-premises

Op claims gebaseerde of Active Directory verificatie

Microsoft Dynamics 365Internet Facing Deployment (IFD)

Op claims gebaseerde of Active Directory verificatie

Hoe op claims gebaseerde verificatie werkt

Een aanvraag is om een gebruiker te verifiëren wordt verzonden van Microsoft Dynamics 365 of Microsoft Dynamics 365 (online) of een aangepaste toepassing naar de STS-server. De STS-server bepaalt of de gebruiker moet worden geverifieerd, en als dat zo is, geeft deze een getekend en gecodeerd SAML-token uit die informatie over gebruikersverificatie bevat. Het token heeft een bepaalde levensduur en moet mogelijk af en toe worden vernieuwd, afhankelijk van hoe lang uw toepassing het token gebruikt. Dit wordt later in dit onderwerp meer in detail besproken.

Hoe Active Directory-verificatie werkt

Een aanvraag om een gebruiker te verifiëren wordt verzonden van Microsoft Dynamics 365 of een aangepaste toepassing naar Active Directory. De WCF-stack beheert het verificatieproces voor Organisation Service-aanroepen vanuit een toepassing, terwijl Internet Information Services (IIS) verificatie voor een webtoepassing beheert.

Niet-ondersteunde verificatiescenario's

Het gebruik van clientcertificaten wordt niet ondersteund door Microsoft Dynamics 365 SDK. Als u de Microsoft Dynamics 365 website configureert om IIS-clientcertificaten te vereisen, krijgt u verificatiefouten voor alle toepassingen die met de SDK zijn gebouwd.

Voor meer informatie over verdere niet-ondersteunde programmeermethoden, raadpleegt u Niet-ondersteunde aanpassingen.

Verificatieklasses

De volgende tabel geeft de primaire verificatieklassen die beschikbaar zijn in de SDK, beschrijft wanneer deze kunnen worden gebruikt, en bevat koppelingen naar aanvullende relevante documentatie.

Klassen

Gebruik

Verwante documentatie

IServiceConfiguration<TService>, IServiceManagement<TService>

Alle installatietypes: on-premises/IFD, online (Microsoft-account en Office 365/MOS*)

Beste keuze voor multi-threaded toepassingen

Gebruikers van Office 365 verifiëren met webservices van Microsoft Dynamics 365 (online)

Voorbeeld: Gebruikers verifiëren met Microsoft Dynamics 365-webservices

De prestaties bij toewijzing van het servicekanaal verbeteren

DiscoveryServiceProxy, OrganizationServiceProxy

Alle installatietypes: on-premises/IFD, online (Microsoft-account en Office 365/MOS*)

Verificatie door de clientproxyklasses te gebruiken

Voorbeeld: Toegang tot de Discovery-service

De prestaties bij toewijzing van het servicekanaal verbeteren

CrmConnection-klasse

Alle installatietypes: on-premises/IFD, online (Microsoft-account en Office 365/MOS*)

Vereenvoudigde verbinding met Microsoft Dynamics CRM

Voorbeeld: Snel aan de slag met een vereenvoudigde verbinding met Microsoft Dynamics 365

ServerConnection

Alle installatietypes: on-premises/IFD, online (Microsoft-account en Office 365/MOS*)

Gebruik voor de consoletesttoepassingen en voorbeeldcode.

Ontworpen om de bruikbaarheid te verbeteren bij het uitvoeren van SDK-voorbeeldcode en het gebruik van de verificatieklasses weer te geven. Bevat code van de console-uitvoer.

Helpercode: klasse ServerConnection

Voorbeeld: Aan de slag voor Microsoft Dynamics 365

*Microsoft Online Services-omgeving

Verificatie door de clientproxyklasses te gebruiken

Een manier om te verifiëren met de Microsoft Dynamics 365 webservices is het gebruik van de OrganizationServiceProxy en DiscoveryServiceProxy klasses in de toepassingen die u schrijft. De constructor met vier parameters voor deze klasses ondersteunt Microsoft Dynamics 365 (online en on-premises) implementaties. Deze proxyklasses verwerken automatisch claims of Active Directory verificatie en beheren ook resourcelimieten op het WCF-kanaaleindpunt.

De volgende code toont hoe u een exemplaar maakt van de organisatieserviceproxy:

using (OrganizationServiceProxy _serviceProxy =    new OrganizationServiceProxy(organizationUri, homeRealmUri, userCredentials, deviceCredentials))

De volgende code toont hoe u een exemplaar maakt van de discoveryserviceproxy:

using (DiscoveryServiceProxy _discProxy =    new DiscoveryServiceProxy(organizationUri, homeRealmUri, userCredentials, deviceCredentials))

Het is belangrijk om het exemplaar van de serviceproxy in uw toepassing goed te verwijderen voordat u de toepassing afsluit. De verklaring using zorgt ervoor dat de serviceproxy correct wordt verwijderd door automatisch Dispose aan te roepen wanneer deze buiten bereik raakt. Voor een verbeterde prestatie van de toepassing is het echter aan te raden een exemplaar van de serviceproxy beschikbaar te hebben in uw toepassing voor de volledige toepassingssessie in plaats van het te verwijderen en ergens anders in de toepassingscode opnieuw toe te wijzen. De reden is dat het maken en verifiëren van een servicekanaal een dure bewerking (wat betreft tijd) is. In dit geval moet u, wanneer u klaar bent met het exemplaar van de serviceproxy, rechtstreeks de methode Dispose op de proxy aanroepen voordat de toepassing wordt beëindigd.

De apparaatreferenties van het geregistreerde gegevensverwerkingsapparaat worden alleen gebruikt voor verificatie met Microsoft Dynamics 365 (online) via Microsoft-account identiteitsprovider. Voor voorbeeldcode die laat zien hoe u de parameters van de proxyconstructor invult, raadpleegt u Voorbeeld: Toegang tot de Discovery-service.

Belangrijk

Voor een on-premises of een Internet-facing deployment (IFD) installatie van Microsoft Dynamics 365, gebruiken de klassen van de clientproxy op claims gebaseerde verificatie als er een STS-server beschikbaar is. Anders wordt Active Directory verificatie gebruikt.

Als u Microsoft Dynamics 365 vroeg gebonden entiteittypes in uw code wilt gebruiken, moet u de volgende regel code toevoegen nadat een exemplaar is gemaakt van de serviceproxy van de organisatie, maar voordat u de webservicemethode aanroep:

_serviceProxy.EnableProxyTypes()
System_CAPS_security Beveiliging Opmerking

WCF ondersteunt een functie waarmee het de gebruiker interactief kan vragen naar aanmeldgegevens indien nodig. Deze functie is ingeschakeld door de eigenschap SupportInteractive van de klasse ClientCredentials in te stellen. Deze referenties worden gebruikt in de parameter userCredentials in het vorige codestukje.

Bij het maken van SDK-aanroepen naar de Microsoft Dynamics 365 webservices, kan eigendom van de bewerking en wijziging van entiteitgegevens, uitgevoerd door de SDK-oproep, worden gewijzigd door deze WCF-functie, ongeacht uw code.

Microsoft Dynamics 365 verwerkt de ingevoerde referenties in webserviceaanroepen als volgt:

  • Als de referenties niet in de webserviceaanroep worden geleverd, bepaalt de WCF-stack welke aanmeldingsgegevens moeten worden gebruikt. In dat geval, wordt de SupportInteractive eigenschapwaarde automatisch ingesteld op false.

  • Als aanmeldgegevens uitdrukkelijk door uw code worden aangeleverd, wordt de huidige SupportInteractive waarde doorgegeven aan de WCF-kanaalfabriek.SupportInteractive is standaard ingesteld op true tenzij u dit uitdrukkelijk wijzigt.

  • Als SupportInteractive is ingesteld op true en de opgegeven referenties bevatten een fout, kan een WCF-dialoogvenster worden weergegeven. Eventuele referenties die door de gebruiker in het dialoogvenster zijn ingevoerd, worden gebruikt in plaats van de meegeleverde gegevens in de webservice die uw toepassing aanroept.

Kanaaluitzonderingen en fouten verwerken

Uw code moet de volgende uitzonderingen en fouten bevatten. Zie de C#-voorbeelden in de Microsoft Dynamics 365 SDK voor een lijst met aanvullende uitzonderingen om op te vangen:

Voor meer informatie, zie de .NET FrameworkWCF-documentatie over het verwerken van WCF-fouten en uitzonderingen. Zie Het voorbeeld en de helpercode gebruiken voor aanvullende voorbeeldcode.

Aanvullende informatie over het veiligheidstoken (SAML)

Het SAML token dat werd gebruikt tijdens gebruikersverificatie wordt hieronder beschreven.

Inhoud van de SAML token

De op XML gebaseerde SAML 2.0 token bevat een identiteit die een of meerdere claims over een gebruiker bepaalt. Het token is doorgegeven tussen een identiteitsprovider (STS) server en Microsoft Dynamics 365 voor op claims gebaseerde verificatie. Claims in de identiteit zijn als volgt gedefinieerd.

Claim

Gebruiken

Universal Principal Name (UPN)

Bevat de gebruikers-id in domain\aliasindeling op de doel Microsoft Dynamics 365 server.

Naam

Als de geverifieerde gebruiker ook een Deployment Administrator is in Microsoft Dynamics 365, bevat deze claim de ide van de deployment administrator in domein/aliasindeling op de doel Microsoft Dynamics 365 server.Windows Identity Foundation koppelt de claim Name aan de eigenschap Identity.name.

Andere claims

Niet gebruikt door Microsoft Dynamics 365.

Ondersteunde types beveiligingstoken

Microsoft Dynamics 365 (online en on-premises) ondersteunt twee types SAML-tokens:

  • Webtoepassing De Microsoft Dynamics 365 webtoepassing ontvangt een dragerstoken van STS. In dit token ontbreekt wat vereiste informatie zodat een op Transport Layer Security (TLS) of Secure Sockets Layer (SSL) gebaseerde URL (https://) wordt gebruikt voor beveiliging wanneer u het WCF-eindpunt opent.

  • SDK - Een aangepaste toepassing ontvangt een actieve token met een bewijssleutel die de vereiste informatie bevat.

De levenscyclus van de beveiligingstoken

Een SecurityToken heeft een levensduur die wordt bepaald door ValidFrom en ValidTo eigenschappen. Uw toepassingontwerp moet rekening houden met de mogelijkheid dat het token kan verlopen, wat leidt tot een ExpiredSecurityTokenException die door de Microsoft Dynamics 365 webservices wordt geretourneerd wanneer de volgende berichtaanvraag van uw toepassing wordt verwerkt.

Zie ook

Overzicht: een Dynamics 365-app registreren bij Active Directory
Verbinding maken met Microsoft Office 365 en Microsoft Dynamics 365 (online)
Eenmalige aanmelding vanaf een ASPX-webpagina of IFRAME implementeren
Voorbeeld: Gebruikers verifiëren met Microsoft Dynamics 365-webservices

Microsoft Dynamics 365

© 2017 Microsoft. Alle rechten voorbehouden. Auteursrecht