Develop Reference

Getting claims using MSAL

I am using Microsoft.Identity.Claim library to conenct to azure and authenticate user.
My first idea was to use AcquireTokenByIntegratedWindowsAuth method but that requires few days until network administrator people investigate how to enable single sign-in option and change that user are now "federated" and not "managed. So I now switched to AcquireTokenInteractive method because chances are that ure will be logged in, so he will just need to choose account from automatically opened browser and that's it. No big deal.
And this works:
string clientId = "xxx";
var tenantId = "yyy";
string[] scopes = new string[] { "User.Read", "User.ReadBasic.All"};
AuthenticationResult result;
var app = PublicClientApplicationBuilder.Create(clientId)
.WithRedirectUri("http://localhost")
.WithAuthority(AzureCloudInstance.AzurePublic, tenantId).Build();
try
{
result = await app.AcquireTokenInteractive(scopes)
.ExecuteAsync();
}
catch (MsalUiRequiredException) //see all possibl exceptions!
{
However, I don't receive claims inside token.
My idea is to send this token to server, then validate it, and if sucessfull create user in database and then use my own authenication mechanism I use for other users (that are not part of domain, completely separate user).
But I don't want all users from domain have access to this app.
So I would like to get claims, roles...
How to get claims, using this or any other lib given user email, or some other unique data?

Here I summarize all of the steps you may need to follow:
1. You need to register a app in azure ad for your service app, you can refer to this document
2. Then you need to register another app in ad as the client app, you can follow the steps in this document
3. After that, you need to do the steps in this document which I already provided in comments. Do it in the service app but not client app.
4. Then you can get the access token with your code and check the claim roles. Please note, do not add microsoft graph permissions into scopes in your code. You need to add api://<the client id of the registered app for service app>/.default into scopes.
5. Now you can find the claim roles in your access token.

How to setup Active Directory authentication with Vue.js and a .NET Core API

I am re-writing one of our intranet sites as a .NET Core 3.1 WebAPI backend with a Vue.js frontend. I'm an experienced programmer, but new to some of these technologies. I need to setup authentication with Active Directory so local network users don't have to login to the site.
I've seen some things about using tokens and sending that in the API requests, but don't know where to start. Eventually, there will be a second Vue.js frontend for external (third-party) users who will need to authenticate with a username/password form. So the API needs to be able to handle both kinds of users.
How do I set this up? Any instructions or guidance is appreciated. I'm sure I'll have other questions as I get into it.
Thanks!
EDIT
I was able to get this method working to take a username/password and validate it against our Active Directory domain (requires the Microsoft.Windows.Compaibility package)
using System.DirectoryServices.AccountManagement;
private bool IsValidUserAndPasswordCombination(string username, string password)
{
bool isValid = false;
using (PrincipalContext pc = new PrincipalContext(ContextType.Domain, "localdomainname.com"))
{
isValid = pc.ValidateCredentials(username, password);
}
return isValid;
}
Now I just need to know the best way to pass the current Windows user credentials to the API. The API is setup for anonymous authentication. Is there a way to get the credentials in Vue.js and pass them without using the authorization headers?

I think you can check this quesion that is analogue to yours.
So you can generate JWT Tokens manually (if you need it for authentication), checking users identity through LDAP Authentication.
EDIT
I think you cannot get the current user credentials inside a browser without a specific browser plugin... Maybe the only way is to prompt for user login like any other website and keep the Login Action Controller anonymous and use it to validate user.
When validated you can generate a JWT Token for the client to keep authenticated.
EDIT 2
To generate a JWT Token you can find may tutorials on the web, mainly you have to use the System.IdentityModel.Tokens.Jwt namespace eg.:
var tokenHandler = new JwtSecurityTokenHandler();
// The secret must be kept and used to validate the token
var key = Encoding.ASCII.GetBytes(_appSettings.Secret);
var tokenDescriptor = new SecurityTokenDescriptor
{
Subject = new ClaimsIdentity(new[] { new Claim("id", user.Id.ToString()) }),
Expires = DateTime.UtcNow.AddDays(7), // maybe you want it to be shorter
SigningCredentials = new SigningCredentials(new SymmetricSecurityKey(key), SecurityAlgorithms.HmacSha256Signature)
// If you want you can add as many claims you need in your token (roles etc.)
};
var token = tokenHandler.CreateToken(tokenDescriptor);
var tokenString = tokenHandler.WriteToken(token);
Send the tokenString to te client in the response to login request, and keep it in the client to send authenticated requests.
You also neet to configure the API to authorize users through JWT tokens and instruct it to accept only your one (see here for details)

Authenticate with Dynamics 365 from an Azure Function

Scenario
I have a Dynamics 365 v9 organisation hosted online. I have a set of Azure Functions hosted in an Azure Function App on a different tenant to my Dynamics organisation.
I've created web hooks using the Dynamics Plugin Registration Tool, which at certain events (such as when a Contact is created in Dynamics), POST data to my Azure Functions via their endpoint URLs.
Authentication between Dynamics 365 and my Azure Functions is achieved by passing an x-functions-key value in the HTTP request's authentication HttpHeader.
The Azure Functions receive data from the event in Dynamics in the form of a RemoteExecutionContext which I can read using the following code:
using System.Net;
public static async Task<HttpResponseMessage> Run(HttpRequestMessage req, TraceWriter log)
{
var jsonContent = await req.Content.ReadAsStringAsync();
log.Info(jsonContent);
return req.CreateResponse(HttpStatusCode.OK);
}
Question
How can the Azure Function then authenticate back with the calling Dynamics 365 organisation to read and write data?
What I've tried
Xrm Tooling
The simplest way to authenticate would be to use the CrmServiceClient from Microsoft.Xrm.Tooling.Connector.dll. However, I don't necessarily have a username and password to provide the CrmServiceClient's constructor. Perhaps credentials could be passed securely via the HTTP POST request?
Application User
I've tried registering an Application User in Dynamics. I supply the client id and client secret to my Azure Functions, but authentication fails because the user is in a different tenant to my Azure Functions.
Considered Solutions
One object of the received jsonContent string is called ParentContext . Perhaps this can be reused to authenticate back with the calling Dynamics organisation.
Marc Schweigert has recommended using S2S and has provided a sample to his AzureFunctionApp repository. If I can get this approach to work I'll post the solution here.

I wouldn't have thought you can sensibly use the 'real' users credentials to connect to CRM.
I would use a service account to connect back into CRM. Create a new CRM
user especially for this purpose, if you make the user non-interactive you shouldn't consume a license. You can then use the credentials of that service account to connect to CRM using CrmServiceClient. Alternatively have a look at Server to Server authentication.
If you are able to deliver a user id to your Function App, you use the service account to impersonate 'real' users via the CRM web services.
To impersonate a user, set the CallerId property on an instance of
OrganizationServiceProxy before calling the service’s Web methods.

I have done something similar recently, but without relying on the Azure subscription authentication functionality for connecting back into D365. In my case calls were coming to Azure functions from other places, but the connection back is no different. Authentication does NOT pass through in any of these cases. If an AAD user authenticates to your Function application, you still need to connect to D365 using an application user, and then impersonate the user that called you.
First, make sure that the application you registered in Azure AD under App Registrations is of the type "Web app / API" and not "Native". Edit the settings of the registered app and ensure the following:
Take not of the Application ID, which I'll refer to later as appId.
Under "API Access - Required Permissions", add Dynamics CRM Online (Microsoft.CRM) and NOT Dynamics 365.
Under "API Access - Keys", create a key with an appropriate expiry. You can create multiple keys if you have multiple functions/applications connecting back as this "App". I'll refer to this key as "clientSecret" later.
If the "Keys" option isn't available, you've registered a Native app.
I stored the appId and clientSecret in the application configuration section of the Function App, and accessed them using the usual System.Configuration.ConfigurationManager.AppSettings collection.
The below examples use a call to AuthenticationParameters to find the authority and resource URLs, but you could just as easily build those URLs manually using the countless examples online. I find this will just update itself if they ever change, so less work later.
These are simple examples and I'm glossing over the need to refresh tokens and all those things.
Then to access D365 using OData:
string odataUrl = "https://org.crm6.dynamics.com/api/data/v8.2/"; // trailing slash actually matters
string appId = "some-guid";
string clientSecret = "some key";
AuthenticationParameters authArg = AuthenticationParameters.CreateFromResourceUrlAsync(new Uri(odataUrl)).Result;
AuthenticationContext authCtx = new AuthenticationContext(authArg.Authority);
AuthenticationResult authRes = authCtx.AcquireTokenAsync(authArg.Resource, new ClientCredential(appId, clientSecret)).Result;
using (HttpClient client = new HttpClient()) {
client.TimeOut = TimeSpan.FromMinutes (2);
client.DefaultRequestHeaders.Add("Authorization", authRes.CreateAuthorizationHeader ());
using (HttpRequestMessage req = new HttpRequestMessage(HttpMethod.Get, $"{odataUrl}accounts?$select=name&$top=10")) {
using (HttpResponseMessage res = client.SendAsync(req).Result) {
if (res.IsSuccessStatusCode) {
Console.WriteLine(res.Content.ReadAsStringAsync().Result);
}
else {
// cry
}
}
}
}
If you want to access D365 using the Organization service, and LINQ, use the following. The two main parts that took me a while to find out are the format of that odd looking organization.svc URL, and using Microsoft.Xrm.Sdk.WebServiceClient.OrganizationWebProxyClient instead of Tooling:
string odataUrl = "https://org.crm6.dynamics.com/xrmservices/2011/organization.svc/web?SdkClientVersion=8.2"; // don't question the url, just accept it.
string appId = "some-guid";
string clientSecret = "some key";
AuthenticationParameters authArg = AuthenticationParameters.CreateFromResourceUrlAsync(new Uri(odataUrl)).Result;
AuthenticationContext authCtx = new AuthenticationContext(authArg.Authority);
AuthenticationResult authRes = authCtx.AcquireTokenAsync(authArg.Resource, new ClientCredential(appId, clientSecret)).Result;
using (OrganizationWebProxyClient webProxyClient = new OrganizationWebProxyClient(new Uri(orgSvcUrl), false)) {
webProxyClient.HeaderToken = authRes.AccessToken;
using (OrganizationServiceContext ctx = new OrganizationServiceContext((IOrganizationService)webProxyClient)) {
var accounts = (from i in ctx.CreateQuery("account") orderby i["name"] select i).Take(10);
foreach (var account in accounts)
Console.WriteLine(account["name"]);
}
}
Not sure what context you get back in your Webhook registration, not tried that yet, but just making sure that there's a bearer token in the Authorization header generally does it, and the two examples above inject it in different ways so you should be able to splice together what's needed from here.

This is something I'm curious about as well but I have not had the opportunity to experiment on this.
For your second option have you registered the application and granted consent in the target AAD?
https://learn.microsoft.com/en-us/dynamics365/customer-engagement/developer/use-multi-tenant-server-server-authentication
When they grant consent, your registered application will be added to the Azure AD Enterprise applications list and it is available to the users of the Azure AD tenant.
Only after an administrator has granted consent, you must then create the application user in the subscriber’s Dynamics 365 tenant.
I believe the root of the access issue is related to the Application's Service Principal Object (the Object local to the target Tenant)
Service Principal Object
https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-application-objects#service-principal-object
In order to access resources that are secured by an Azure AD tenant, the entity that requires access must be represented by a security principal. This is true for both users (user principal) and applications (service principal). The security principal defines the access policy and permissions for the user/application in that tenant. This enables core features such as authentication of the user/application during sign-in, and authorization during resource access.
Consider the application object as the global representation of your application for use across all tenants, and the service principal as the local representation for use in a specific tenant.
HTH
-Chris

Using S2S you can use AcquireToken to retrieve the Bearer
var clientcred = new ClientCredential(clientId, clientSecret);
AuthenticationContext authContext = new AuthenticationContext(aadInstance, false);
AuthenticationResult result = authContext.AcquireToken(organizationUrl, clientcred);
token = result.AccessToken;
ExpireDate = result.ExpiresOn.DateTime;
client.DefaultRequestHeaders.Authorization = new System.Net.Http.Headers.AuthenticationHeaderValue("Bearer", token);

Managing Credentials in Azure .NET Core 2.0 SDK

I'm a little bit lost on how you can create credentials in the Azure .NET SDK without having to call the credentials from a local file.
In my case, I have a few subscriptions and I'm storing my data in a local database. I want to make multiple calls to Azure for my VMs using the credentials I store in the database.
They have numerous classes representing ways to authenticate in the SDK Documentation, but I can't see a clear way to create access tokens or use credentials (tenant id, subscription id, client id and secret) through the SDK.
For example, when calling one of the Client classes (ComputeManagementClient) you can call it with credentials to authenticate the request to Azure but they don't seem to provide a Class to generate the credentials beyond from a file.
Does anyone have an MSDN reference?

Accoring to AzureCredentialsFactory class, we could know that we also could get the credentials FromServicePrincipal or FromUser. In your case I recomment that use the FromServicePrincipal and Microsoft.Azure.Management.Fluent to operate the Azure resource. I also do a demo for that.
Note: How to registry Azure AD Application and assign role please refer to this document.
var clientId = "clientId";
var secretKey = "secretKey";
var tenantId = "tenantId";
var subscriptionId = "subscriptionId";
var credentials = SdkContext.AzureCredentialsFactory.FromServicePrincipal(clientId, secretKey, tenantId,AzureEnvironment.AzureGlobalCloud);
ComputeManagementClient client = new ComputeManagementClient(credentials) {SubscriptionId = subscriptionId };
var result = client.VirtualMachines.ListAllAsync().Result;

Authenticating with openstack.net API cloud files using London account

When I use:
CloudIdentity identity =
new CloudIdentity()
{
Username = "files.user",
APIKey = "pswd",
};
var _storage = new CloudFilesProvider(identity);
Authentication fails. I figured that the problem is that I have a LON account and the default authentication target is US cloud instance. On openstack.net wiki, I saw the below example.
IIdentityProvider identityProvider = new CloudIdentityProvider();
var userAccess = identityProvider.Authenticate(new RackspaceCloudIdentity{
Username = "MyUserName",
Password = "MyPassword",
CloudInstance =CloudInstance.UK});
In the latest version of the library, RackspaceCloudIdentity has Domain parameter instead of CloudInstance. I guess the example is out dated.
How do I use the Domain parameter? Or is there a better way to authenticate with LON cloud instance?

Rackspace uses global authentication now, so the only difference between the US and UK accounts is the credentials you pass in. If authentication is failing then one of the following is the likely issue:
Your username and/or API key for the CloudIdentity instance are not correct.
The identity service experienced an outage of some sort at the particular moment you tried to authenticate.
Authentication is succeeding, but another error occurred which you have attributed to failed authentication (you didn't provide any exception details so I can't rule this out).

I have been seeing the same error. I believe that it is something to do with child accounts created via the UI. They do not have a DefaultRegion correctly set (it is null).
The only way around this is to use the parent account, or alternatively to manually set the region on every API call.