2
votes

We have an Azure hosted ‘on-premise’ instance of Dynamics 2016 running as an IFD utilising ADFS authentication. We now have a requirement for an Azure hosted API to communicate with the Dynamics instance using the CRM Web API. To achieve this we need to authenticate using OAuth authentication using ADAL as outlined here https://msdn.microsoft.com/en-gb/library/gg327838.aspx , utilising the Microsoft.IdentityModel.Clients.ActiveDirectory library. We have the following code to retrieve a token from ADFS

var resource = "https://reosurce.com/";
var clientId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx";
var authProvider = "https://adfs.server.com/adfs/oauth2/token";
var redirectUri = "https://crm2Environment.com/";

var authContext = new AuthenticationContext(authProvider, false);
var authToken = authContext.AcquireTokenAsync(resource, clientId, new 
Uri(redirectUri), new PlatformParameters(PromptBehavior.Always)). 
Result.AccessToken;

The code example runs successfully, however is for use in an interactive flow situation and as soon as the AcquireTokenAsync method is called login dialog appears (makes sense as how else does ADFS know whether its ok to Authenticate), however this is obviously not going to work on the API which is domain agnostic and there is no way of passing credentials to ADFS (not that We would want to anyway). None of the alternative overloads to the AcquireTokenAsync method appear to be applicable to ADFS in the situation outlined (but open to suggestions). Are we missing something? Is there another way to retrieve the token with a non-interactive flow / without using Domain Account authentication? Bear in mind that the examples available for Azure AD do not appear to work in the ADFS scenario also we do not own or have access to the current ADSF server as this is managed by our infrastructure team (although if there is a requirement for them to make changes on the ADFS this is possible)

2

2 Answers

1
votes

What version of ADFS are you using?

If ADFS 4.0 and the flow is server to server (sounds like it is) use client credentials which uses the knowledge of a secret key - no login / password.

Good link here.

0
votes

Take a look at MSI (Managed Service Identity). This is a new communication protocol for Azure-to-Azure services.

Managed Service Identity (MSI) for Azure resources

As you research this, try not to fall into confusion with the old pattern (which is still valid for Service-to-AzureService communication) This is where you generate a ClientId/ClientSecret/Url on Azure that gives permissions, then share these values with the application that requires access. Here is an example of that Use Azure Key Vault from a Web Application The example demonstrates connecting to Azure Key Vault, but it could be any Azure service that uses Azure Active Directory Authentication.