Add an option for certificateBase64Encoded to login command

[YannickRe]

There already is an option to use the path to an .pfx file as input to the m365 login command, by specifying --certificateFile as an option. Internally, CLI goes and reads the file and then continues with the base64 encoded version of it.
Similar to what PnP.Powershell does, I'd like to propose an additional switch (--certificateBase64Encoded?) that would allow us to pass in the base64 encoded version of the .pfx directly.

This is particularly useful in Azure DevOps when using a Variable Group that connects to an Azure Key Vault and exposes the certificate (as base64 encoded) in a variable. With this new switch, it would allow us to pass in that variable directly without converting it to a local .pfx first (which gets converted back to base64 immediately by CLI anyways).

What do you think?

Side note: I don't see why it is required to pass in the '--thumbprint' for that certificate (both with --certificateFile en --certificateBase64Encoded). I don't see it being used anywhere in the code of CLI (but I might not have looked good enough).

[waldekmastykarz]

Thanks for the feedback and this is very helpful. I like the suggestion of us supporting other formats for the certificate. Right now, we have a contributor working on adding support for retrieving them directly from the Windows cert store. Adding support for KeyVault would be another good step, especially in combination with managed identity which would allow you to have 0 credentials anywhere in the pipeline.

Would you mind creating an issue with a feature request to add support for --certificateBase64Encoded and another one for KeyVault (if you think it would be helpful)?

As for the thumbprint, we need to retrieve the token using cert via ADAL:

cli-microsoft365/src/Auth.ts

Line 329 in ac891a4

this.service.thumbprint as string,

[YannickRe]

I'll create the feature request for certificateBase64Encoded! I don't really need Key Vault support as that is already baked into Azure DevOps pipelines: you can create a Variable Group, connect it to a Key Vault and your secrets and certificates turn into pipeline variables. The certificates come in base64Encoded format, that's why I'd like CLI to take that as an input.

I do get it from an Azure Cloud Shell perspective in combo with Managed Identities, as you'd be able to leverage the managed identity to connect to Key Vault and fetch the secret/certificate that way. It could potentially require more parameters tho: the Key Vault, which secret or certificate, etc.
Not something I can see the whole impact of, nor design a spec for. I'll add the feature request but it'll be limited...

[waldekmastykarz]

Thanks for the additional clarification of the use case and the considerations. I see the added value for supporting KeyVault in automation scenarios where you would want to use CLI in an Azure Function in a secure manner.

[YannickRe]

I don't get the added value: if you have a Managed Identity why would it need to go to the Key Vault and not use that directly to access the resource? Except for the fact that it is easier to assign permissions to an Azure AD app registration than to a Managed Identity.

[waldekmastykarz]

I vaguely recall some restrictions around using Managed Identities and specific differences between user- and system-assigned identities, but don't recall them off the top of my head. I believe @garrytrinder or @VelinGeorgiev had a closer look at them and might know more. If there is indeed no point in going to KeyVault and you can do everything you need through an MI, then that's even better as it lowers the number of moving parts for the user 👍

[garrytrinder]

The difference is

• System identity is tied to the resource lifecycle, delete the resource and the identity is removed, so there is a 1-1 relationship
• User-assigned identity is a resource in itself that can be used as an identity across multiple resources, so is not tied to a specific resource lifecycle.

In regards to the authentication process, they are identical and both use certificate based authentication behind the scenes.

Access to Key Vault to obtain certificates would be useful using managed identity if you needed to call a downstream API that is not backed by Azure AD.

[YannickRe]

That's what I thought. So I don't get the use case yet, as CLI only connects to AAD backed API's (for now) correct?
In essence, all necessary scopes could be added to the Managed Identity and do the auth so I don't get the why for needing a Key Vault. It doesn't mean that I oppose it being implemented, I just don't get it 😃