[FEATURE REQ] Allow MSFT Fluent SDK to reuse auth context from Powershell AZ Module

[eosfor]

Cross-referencing the request here: Azure/azure-libraries-for-net#1075

We use Fluent SDK to develop some binary PowerShell modules to manage some pieces of our Azure resources. It does not mean we re-implementing the AZ module, but rather, adding some extensions to it. According to the Auth document you have already integrated with Azure CLI, which allows Fluent to reuse CLI authentication context. We would like to have a similar feature to be implemented with the PowerShell AZ module, where we could refer and reuse its authentication context inside Fluent SDK.

[eosfor]

Here is the simple test to see what is happening

using System.Management.Automation;
using Microsoft.Azure.Management.ResourceManager.Fluent.Authentication;
using Microsoft.Azure.Management.ResourceManager.Fluent;
using Microsoft.Azure.Management.Fluent;
using System;
//using Microsoft.IdentityModel.Clients.ActiveDirectory;

namespace pstest3
{
    [Cmdlet(VerbsCommon.New, "Test")]
    public class NewTestCmdlet : PSCmdlet
    {
        protected override void ProcessRecord()
        {
            var env = AzureEnvironment.AzureGlobalCloud;
            var c = new AzureCredentialsFactory();
            var cred =  c.FromDevice("e988df20-46b9-4de9-9eb7-82c52c9ac406", "8db27d07-03f0-41f0-9254-9ba7db634e6d", env, c => {
                Console.WriteLine(c.Message);
                return true;
            });
            var azure = Azure.Authenticate(cred).WithDefaultSubscription();
            // base.ProcessRecord();
        }
    }
}

Then I run the cmdlet above, it works, but then when I load the AZ module, it fails to load.

[dingmeng-xue]

@eosfor, you need to ensure that your project is using the same version of Az.Accounts. Otherwise, dotnet core has the problem to load the different version of assembly with the same name.

[eosfor]

@dingmeng-xue , that is the problem. The Az.Accounts uses Microsoft.IdentityModel.Clients.ActiveDirectory Version=3.19.2.6005. On the other hand, my cmdlet uses MSFT Fluent SDK, which in turn uses Microsoft.IdentityModel.Clients.ActiveDirectory/4.3.0. So when I try to load or execute my cmdlet after AZ it fails with the message above. When I do it in reverse order, the following thing happens

[dingmeng-xue]

@eosfor , I have no good idea to support this case. Current dotnet core cannot load the 2 assembly versions into one process. It is the one reason that current Azure PowerShell cmdlets doesn't use any Fluent SDK. For your case, Azure CLI is one option, and another one is you have to use management SDK for your module.

[eosfor]

@dingmeng-xue, what do you think, in general, what is the best way to consume AZ module authentication context in some external binary module?

[erich-wang]

@eosfor , could you please try the following two options:

• You may try Windows PowerShell if you don't care about PowerShell platform
• If need to stick to PowerShell 7, try Az.Accounts 2.0.1-preview which use MSAL.NET instead of ADAL.NET, it should have no version conflict with your cmdlet, but may need credential adapter as Fluent SDK use ADAL.NET

[eosfor]

@erich-wang , is there any adapter ready to use? In general, is it ok to pull the AZ context from it and reuse it elsewhere? Or, maybe there is another way you suggest to use?

[erich-wang]

@eosfor , per my understanding, Azure CLI exposes access token as plain text in one file and fluent SDK may reuse the access token, is this what you mean in "According to the Auth document you have already integrated with Azure CLI, which allows Fluent to reuse CLI authentication context."? Actually Azure CLI is going to retire exposing access token as there's security concern.
Currently Azure CLI, Azure PowerShell and SDKs is moving from ADAL to MSAL, and there'll be SSO among them.

[eosfor]

@erich-wang , yes, this is what I meant.

Currently Azure CLI, Azure PowerShell and SDKs is moving from ADAL to MSAL, and there'll be SSO among them.

Do you mean, Fluent is also moving? What do you mean by "SSO among them"?

[eosfor]

@erich-wang , and the main thing is, how do you want me to integrate to AZ auth context in a way, that I do not authenticate twice in my PowerShell binary module, which, in turn, uses Fluent. What is the correct way to do it? :)

[erich-wang]

SSO means single sign on. Currently Azure PowerShell doesn't suppprt to integrate Az module and your module based on fluent. Just curious, is there any particular reason that you need to use .net fluent sdk to develop powershell module? Is there any functionality you need that does not exist in Az modules?

[erich-wang]

@eosfor, could you please reply my questions? I'll close the issue if we don't get your response by end of this June.

[eosfor]

Well, it was a long story, basically. It is hard to capture a particular reason. I'd say that our development group was more familiar with C# and it's workflows, so we decided to go with it. Probably it was a fair decision at that point. And we found fluent and liked it "style", I'd say.

It sounds like that fluent is going to be deprecated soon, so I think I close the issue. Thanks @erich-wang