Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Conversation

bgavrilMS
Copy link
Member

Fixes #

Changes proposed in this request

Testing

Performance impact

Documentation

  • All relevant documentation is updated.

@bgavrilMS bgavrilMS requested a review from a team as a code owner December 16, 2024 11:24
@bgavrilMS bgavrilMS marked this pull request as draft December 16, 2024 11:39
// TODO: test this on MacOs / Linux WSL
private static TokenCredential GetAzureCredentialForDevBox()
{
InteractiveBrowserCredential interactiveBrowserCredential = new InteractiveBrowserCredential(
Copy link
Contributor

@gladjohn gladjohn Dec 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

image

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

VS clientID is now authorized to call Lab API for an authorized user

var msalConfidentialClient = ConfidentialClientApplicationBuilder
.Create(ciamWebApi)
.WithCertificate(CertificateHelper.FindCertificateByName(TestConstants.AutomationTestCertName))
.WithCertificate(CertificateFinder.FindCertificateByName(TestConstants.AutomationTestCertName))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we create a new self signed cert for this purpose? and move away from the SNI cert for lab apps?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we move to use Visual Studio credential for DevBox and UAMI based acccess for CI, we do not need this app flow anymore

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

Morty Proxy This is a proxified and sanitized view of the page, visit original site.