Azure-sdk-for-java: Support managed-idendity for aad-starter

[chenrujun]

azure-spring-boot-starter-keyvault-secret and azure-spring-boot-starter-keyvault-certificates support managed identity.
azure-spring-boot-starter-active-directory does not support managed identity,

Need to investigate whether it's possible to support managed identity in azure-spring-boot-starter-active-directory, if it's possible, user do not need to configure client-id and client-secret to use azure-spring-boot-starter-active-directory .

My current understanding is that client-id and client-secret is required according to current code.

Maybe we can extract client-id and client-secret from managed identity?

[saragluna]

Is this a reasonable feature for the AAD starter?

[chenrujun]

@saragluna

I need more investigation. Now I'm not familiar with managed-identity.

[chenrujun]

Hi, @idg-sam .

Is this a reasonable feature-request?

[idg-sam]

Hi @chenrujun ,
Yes, obtaining secrets/certs through key vault using managed identity is an important feature. In our app service deployment samples, we strongly encourage developers to use it. I don't have any strong opinions on how the feature should be made available, but I do have some questions for you to consider.

As your initial comment says, azure-spring-boot-starter-keyvault-secret and azure-spring-boot-starter-keyvault-certificates can be used with managed identity to get secrets/certs.

Is it currently possible to set the relevant secret/cert configuration in AAD spring boot starter client library at runtime, after obtaining the value by utilizing a key vault boot starter ?

1. If yes, then:
   
   
   
   • Is there a need for a new feature? Assuming the developer can run something like the pseudo-code below, before AADWebAppConfiguration.createClientBuilder() executes:
     
     java // pseudo-code. void onProgramStartupOrBeforeAADStarterInitialization() { // assuming the application utilizes Key Vault boot starter or something similar: properties.set( "azure.activedirectory.client-secret", keyVaultClient.getSecret("CLIENT_SECRET"); }
   
   
2. If not, then:
   
   
   
   • Should we surface a way for the developer to set the Azure AD boot starter client configuration values programatically at run time? To allow the dev the option to implement some version of the above.
   
   
3. In both cases (yes and no):
   
   
   
   • Should we consider automating the above process for the developer? For example, using some configuration property that tells the AAD boot starter to get secret or cert or other from vault.
   
   

[chenrujun]

Hi, @idg-sam

Is it currently possible to set the relevant secret/cert configuration in AAD spring boot starter client library at runtime, after obtaining the value by utilizing a key vault boot starter ?

Yes, it's possible.

---

If yes, then: Is there a need for a new feature?

1. Save client-id client-secret in keyvault.
2. Get the client-id client-secret from keyvault, then config aad-starter

This feature is already implemented.
My question is that can we avoid using client-id and client secret in keyvault, just get the value from managed-identity?

---

In both cases (yes and no):
Should we consider automating the above process for the developer? For example, using some configuration property that tells the AAD boot starter to get secret or cert or other from vault.

It's already implemented, just use aad-starter and keyvault-starter at the same time.

[idg-sam]

Hi @chenrujun ,

My question is that can we avoid using client-id and client secret in keyvault, just get the value from managed-identity?

I see. That's not a use-case that I am familiar with. I was under the impression that MI's main role was to help obtain secrets from AzureKV.
Do you know of an example of using MI directly for obtaining secrets, without using AzureKV?

[chenrujun]

@idg-sam

Do you know of an example of using MI directly for obtaining secrets, without using AzureKV?

No. I don't know this kind of example.

Now I'm not sure whether it's an possible feature.
This feature is required by a customer.