/// <summary>
/// Build a new ClientCredential
/// from the Azure Registered Application's
/// ClientId and ClientSecret.
/// </summary>
/// <param name="aaDClientInfo"></param>
/// <returns></returns>
public ClientCredential Build(AadApplicationRegistrationInformationConfigurationSettings aaDClientInfo)
{
//NOTE THAT CLIENT CREDENTIAL comes froms an a library that
// is using the older ADAL approach, and will probably get updated to MSAL,
// hence dragging it out to a Factory:
var result = new ClientCredential(aaDClientInfo.ClientId, aaDClientInfo.ClientSecret);
return(result);
}
/// <summary>
/// Application's that use Azure KeyVault are hosted in Azure.
/// Within Azure Application Registration, when registered, they get an Id.
/// Which is automaticall mapped to a Service Principal Name (SPN)
/// (New-AzureRmADServicePrincipal -ApplicationId <Guid> is invoked behind the scene)
/// (and for now think of it as a Psuedo User that this not visible in AAD Users).
/// Then within KeyVault, access is granted to the SPN.
/// When you sign in, you're using the AppClientId and AppSecret over a secure line.
/// That's how Azure recognizes the app (as an SPN, not a proper User or Service Account).
/// And hence why the App is given acces to the KeyVault to retrieve secrets and keys.
/// </summary>
/// <param name="aadClientInfo"></param>
/// <returns></returns>
public KeyVaultClient Build(AadApplicationRegistrationInformationConfigurationSettings aadClientInfo)
{
var clientCredential = new ClientCredentialFactory().Build(aadClientInfo);
return(Build(clientCredential));
}