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 |
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 |
|
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. |
*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()
.jpeg "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:
|
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