Enable setting custom app registration ClientID via UI

[mattcockrell]

Can you add a config option to set the ClientID instead of requiring a custom build of the exe?

[cricketthomas]

I definitely can and will add custom app registration via the UI. I am working on the next version but i will make sure it's also in this version.

I do have some questions if you don't mind, I have 0 way of knowing anything about my users other than data that comes from the Microsoft Store, and that's limited to very short cryptic crash logs, and number installs or launches.

• Do you use the app on windows10/11, Mac or Linux?
• Do you or will you use it from the Microsoft store?
• What is the hesitation (if any) of using the application at your company?
• What features (other than aforementioned) does the app lack?
• Do you use the subscription page?
• how do you like the layout?

[mattcockrell]

Sure thing. I'd be happy to help with testing if needed.

• Windows 11
• my company has blocked the MS Store, so I tested exe release and a custom exe build
• my company's security team won't approve 3rd party app registrations, I'll need to go through our request process to get an internal app registration with the appropriate permissions
• I'll have more insight on features/layout/etc once I'm able to use the app in our environment, but a capability that will be vital for my use case is compatibility with the Azure Gov Cloud APIs. this was a major shortcoming in the old Microsoft app.

[mattcockrell]

@cricketthomas I was thinking about this issue along with #107 and I wonder if both issues would be resolved by acting as a user instead of an app registration. That would at least be preferable at my company.

[cricketthomas]

The app registration is actually required for user impersonation.

The app has no rights at all, it's performing all actions as the signed in user, if the user can't do it, the app can't do it. #107 is mainly around some assumptions I made when building the application which will have to be fixed, since it was a bad approach to assume most users in the tenant have global reader over subscriptions and RGs.

The app just needs to be installed in your tenant so you can sign into it with your from your domain, I have no control over anything other than registering in my own tenant as a multi-tenanted application.

Also, since your firm has blocked the Microsoft store, would an MSIX package solve your issue so you can install it (outside of the store)?

I'm on vacation right now so I can't actually code anything right now, but when I get back I'll work on getting these issues taken care of.

[mattcockrell]

Yes, an MSIX would be very helpful.

I guess that explanation makes me wonder how the old MS Keyvault app made things work. Were they using some all-powerful app reg specially provision by MS?

[cricketthomas]

They offer multiple methods. One uses a vault.json settings file that lets you add any vault with a client secret. The other is their internal app. I assume they have it set up so this internal app is automatically trusted, but I haven’t been able to download or compile the code to confirm.

With that in mind, I’m going to focus on which approach might be more beneficial for companies. Setting your own app/client ID, or simply adding vaults via service principals in a JSON file the way they’ve done. Which do you think is best?

https://github.com/microsoft/AzureKeyVaultExplorer/blob/cb261d00a591621c63f6b2549061531354b6f558/Vault/Library/VaultAccess.cs#L20

[mattcockrell]

My use of the old app was with the VaultAccessUserInteractive mode. Personally, I'd rather not have to manage a raw json file that's external to the app UI. Could you provide an option to get the user token with Microsoft's first party appId, like here?
https://github.com/microsoft/AzureKeyVaultExplorer/blob/cb261d00a591621c63f6b2549061531354b6f558/Vault/Library/VaultAccess.cs#L62