none
Flowing logged-in user credentials to Web API

    Question

  • Hi all,

    I posted this in a Dynamics forum, but was asked to post here.

    Can I flow the logged-in user credentials to a Web API that is running in my customer's tenant in Azure?

    Background:

    I'm building a Web API in Azure using .Net Core 2.1.  I have a web app that will access this API, and plug-ins from various systems will access it as well -  Dynamics AX, Dynamics CRM, Dynamics 365, etc.  This application will be installed into the tenants of other customers.  So the caller is the plug-in, not the other way around.  The plug-ins will be installed into the customer's instance of the Dynamics systems.

    Right now, the API is secured using Oath2, with a client ID/password - in other words, not using the credentials of the calling user.  That's because I can't get the credentials of the user in an Oath2 form without requiring them to log in again. 

    Note that my team controls the web app and the plug-ins.


    Is there any way, in a plugin like I mentioned above, where I can get the user's credentials in a way that I could pass to the API without requiring another login? 

    I would prefer to use AAD/OpenID because:

    1) I really don't like the idea of a shared secret

    2) we are thinking about allowing our customers to write to the API as well

    3) My customer would like to enforce a 'Named User' licensing model.  Right now, I'm relying on the plug-ins to send me the name of the user.  If we allow #2, the customer could write code that always sends me the same name, bypassing the Named User licensing requirements.

    All of the examples (for every plug-in type) show getting a token by using a shared secret.

    Thanks in advance.

    Thursday, December 6, 2018 11:45 PM

All replies

  • Hi Phillip,

    Your Web API (protected by Azure AD) should be accessible by users from multiple tenants ,so you should register that as a Multi tenant app. This will ensure tokens issued by other Azure AD tenants are also accepted by your API. 

    Example: Web API and web app are protected by tenant A and are registered as multi tenant apps. In the required permissions for the web app we add the web API.

    Scenario A: Accessing the API from Web App

    1) Admin from tenant A tries to access the web app > provides consent for the API and will be able access the API.

    2) Admin from tenant B tries to access the web app > provides consent for the API and the app and will then be able to access the API.

    Check this sample which could help you.

    Scenario B : Plugins accessing the API using user impersonation. Check this thread for some ideas regarding this.

    User from any tenant  will sign in to CRM and if the plugin impersonates the user then you should be able to pass the same token to your API and provide access to it as well.

    Note: Microsoft Graph API is an example for your scenario. It is registered in one tenant by MS and is accessible for users from all Azure tenants.



    15 hours 25 minutes ago
    Moderator
  • Thanks for the reply Manoj.  I'm not sure that this is exactly what I need.

    What I don't have is a trust-worthy way to tell the API who I am from the plug-in.  From the plug-in, I can get a JWT token using the 'client credentials' grant, where I provide a client ID and client secret.  The ID and secret can come from an AzureAd App Registration, with a key.  This works right now, but I have to pass the user name in a header to the API so that I know who the user is.

    So the token is for the same user every time - like a 'service account'.  What I'd like to do is create a JWT for the user that's currently using the plug-in - or use one that is already in place, so that the user's claims are there, and I trust who the user is.

    This is the piece that I can't figure out how to do.  I'd like to do this so that I have more confidence that the user is who they say they are.

    Thanks,

    Phil

    13 hours 4 minutes ago