Refactor lab API and remove certificate based auth #5023
Conversation
bgavrilMS
force-pushed
the
bogavril/lab
branch
from
428359c to
333f687
Compare
bgavrilMS
force-pushed
the
bogavril/lab
branch
from
333f687 to
95a8a2b
Compare
bgavrilMS
force-pushed
the
bogavril/lab
branch
from
95a8a2b to
f5b456d
Compare
| // TODO: test this on MacOs / Linux WSL | ||
| private static TokenCredential GetAzureCredentialForDevBox() | ||
| { | ||
| InteractiveBrowserCredential interactiveBrowserCredential = new InteractiveBrowserCredential( |
There was a problem hiding this comment.
can we use VisualStudioCredential instead?
// Set the Key Vault URL
string keyVaultUrl = "https://msidlabs.vault.azure.net/";
// Create a new Visual Studio Credential
var credential = new VisualStudioCredential();
// Create a new SecretClient using the Visual Studio Credential
var client = new SecretClient(new Uri(keyVaultUrl), credential);
// Retrieve a secret from Azure Key Vault
KeyVaultSecret secret = client.GetSecret("msidlab1");
Console.WriteLine($"Secret: {secret.Value}");this will use the Azure Service Authentication account
There was a problem hiding this comment.
No, we can't use any of the DefaultAzureCredential options, because there is no option to change the clientID. If you use VSCredentail, it'll use VS clientID.
And VS clientID is not authorized to call MSIDlab.
I was thinking that if we were to directly call the KV that might work though. Maybe not VS client ID, but az cli or some tool might do it
There was a problem hiding this comment.
VS clientID is now authorized to call Lab API for an authorized user
| @@ -184,7 +171,7 @@ public async Task OBOCiam_CustomDomain_ReturnsValidTokens() | |||
| //Acquire tokens for OBO | |||
| var msalConfidentialClient = ConfidentialClientApplicationBuilder | |||
| .Create(ciamWebApi) | |||
| .WithCertificate(CertificateHelper.FindCertificateByName(TestConstants.AutomationTestCertName)) | |||
| .WithCertificate(CertificateFinder.FindCertificateByName(TestConstants.AutomationTestCertName)) | |||
There was a problem hiding this comment.
should we create a new self signed cert for this purpose? and move away from the SNI cert for lab apps?
There was a problem hiding this comment.
It still makes sense to have a single cert secure all our tests apps.
| public class LabApiConstants | ||
| public static class LabApiConstants | ||
| { | ||
| public const string LabClientId = "f62c5ae3-bf3a-4af5-afa8-a68b800396e9"; |
There was a problem hiding this comment.
if we move to use Visual Studio credential for DevBox and UAMI based acccess for CI, we do not need this app flow anymore
Fixes #
Changes proposed in this request
Testing
Performance impact
Documentation