Источник:
https://crmtipoftheday.com/1112/impe...zure-ad-users/
==============
Developers are familiar with the concept of
impersonating Dynamics 365 users. It’s easy – all you need to do is to add
MSCRMCallerID header to your Web API request, and you’re done (assuming that you have
prvActOnBehalfOfAnotherUser privilege).
One of the typical scenarios where you’d want to use the impersonation when you have a web site that connects to your Dynamics 365 instance using either non-interactive user or, better,
S2S authentication and then you need to impersonate a currently logged on Azure AD user. The typical flow is: look for a
UPN claim, then use that value to find the user in
systemuser entity filtered by
domainname attribute.
The problem is that UPN claim does not seem to be available when you’re using
B2B guest users. In both scenarios a different
oid claim is available that returns Azure AD object ID. That value can be used to query
systemuser entity using
azureactivedirectoryobjectid attribute. Then it’s business as usual, plonk
systemuserid value into
MSCRMCallerID header and you’re done.
Shortcut
The following approach is undocumented (hopefully not for long!). The usual Tîpp Jäår’s disclaimer applies: not [currently] supported, use at your own risk, contains small children between the flags, not to be consumed with alcohol while driving.
Instead of using Azure AD object ID to lookup the user, pass that id as
MSCRMCallerObjectID header.
POST [Organization URI]/api/data/v9.0/accounts HTTP/1.1MSCRMCallerObjectID: 00000000-0000-0000-000000000002Accept: application/jsonContent-Type: application/json; charset=utf-8OData-MaxVersion: 4.0OData-Version: 4.0Saves you the need to lookup
systemuser and splitting the logic depending on the user type.
Facebook and twitter cover photo by Greg Ortega on Unsplash.
Источник:
https://crmtipoftheday.com/1112/impe...zure-ad-users/