Open kheiman61 opened 5 years ago
not opposed have to think about the cleanest way to add it
Yeah agreed, I did a quick fork and hack and got it to work, but not necessarily the cleanest :)
Personally I like that this library does not attempt to solve authentication and wrap that into the library. As-is the developer can choose the authentication method with Azure AD and pass the Bearer token along to this library.
How do you feel about exposing the CallerId properties directly on the API object? (preferably the AAD CallerObjectId Guid, but the CRM SystemUserId could be there also - see https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/webapi/impersonate-another-user-web-api)
For example, I'd like to be able to have an Azure web app with EasyAuth AAD Authentication, and have a cached, non-impersonated API object connected via S2S, then on each page/controller/etc. where impersonation is desired, grab a copy of the cached S2S API object and just set the current user's AAD user object id before issuing calls. I guess alternatively I could just cache the current S2S auth token and use the full constructor with the optional callerid each time, but I'm trying to use this in a library that hides the actual construction of the api object. It would be nice to have the ability to easily change impersonated AAD users (current or otherwise) as desired on an existing API object - plus support either AAD object user id or CRM systemuserid