Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add credential support to ASP.NET Core integration layer #6805

Merged
merged 21 commits into from
Jul 17, 2019

Conversation

pakrym
Copy link
Contributor

@pakrym pakrym commented Jul 2, 2019

Adding support for multiple features:

  1. Loading client secret and certificate credentials from IConfiguration
  2. Having a global default credential
  3. Having a global client options configuration
  4. Extension methods for Azure.KeyVault.Secrets

In extensions methods, the credential parameter should be made optional. The default value means that a global default credential would be used.

New extension type name pattern SomethingClientBuilderExtensions, method name AddSomethingClient

@@ -38,14 +39,14 @@
<PackageReference Update="Microsoft.CodeAnalysis.CSharp.Workspaces" Version="2.6.1" />
<PackageReference Update="Microsoft.CodeAnalysis.FxCopAnalyzers" Version="2.6.2" />
<PackageReference Update="Microsoft.CodeAnalysis" Version="2.3.0" />
<PackageReference Update="Microsoft.Extensions.Configuration.Abstractions" Version="2.2.0" />
<PackageReference Update="Microsoft.Extensions.Configuration.Binder" Version="2.2.0" />
<PackageReference Update="Microsoft.Extensions.Configuration.Abstractions" Version="2.1.0" />
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've downgraded versions of dependencies to the current LTS version. Azure.Core.Extensions is the only project using them

private string _clientId;
private X509Certificate2 _clientCertificate;
private AadIdentityClient _client;
public string TenantId { get; }
Copy link
Contributor Author

Choose a reason for hiding this comment

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

cc @schaabs

I've exposed the properties to enable testing.

@pakrym pakrym marked this pull request as ready for review July 3, 2019 23:00
@pakrym
Copy link
Contributor Author

pakrym commented Jul 3, 2019

Hm, pipeline tries to pack my sample project for some reason.

@pakrym pakrym requested review from schaabs, jsquire, maririos and tg-msft and removed request for schaabs July 15, 2019 21:40
Copy link
Member

@jsquire jsquire left a comment

Choose a reason for hiding this comment

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

Looks good to me, but I'm not overly familiar with some of the context; I'd recommend not using me as the only approval.

<WarnOnPackingNonPackableProject>false</WarnOnPackingNonPackableProject>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.App" IsImplicitlyDefined="true" />
Copy link
Member

Choose a reason for hiding this comment

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

Orthogonal to these changes: I'm not familiar with IsImplicitlyDefined and a quick search didn't turn up anything. I'd be grateful for a quick pointer to a reference or explanation of what it is for. :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sooooo, you are not supposed to have package version for Microsoft.AspNetCore.App package, SDK would pick the highest patch for you based on the target framework.

Unfortunately, this conflicts with our central version management strategy that produces a warning when something outside of Packages.Data.props set a package version. IsImplicitlyDefined suppresses this warning.

sdk/core/Azure.Core.Extensions/samples/CustomPolicy.cs Outdated Show resolved Hide resolved
sdk/core/Azure.Core.Extensions/samples/appsettings.json Outdated Show resolved Hide resolved
@@ -29,6 +29,7 @@
</ItemGroup>

<ItemGroup>
<ProjectReference Include="..\..\..\identity\Azure.Identity\src\Azure.Identity.csproj" />
Copy link
Member

Choose a reason for hiding this comment

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

Should this use a package reference rather than a project reference?

Copy link
Contributor Author

@pakrym pakrym Jul 17, 2019

Choose a reason for hiding this comment

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

I'll keep it a package reference until preview2 so we can iterate them in parallel.

Copy link
Member

@tg-msft tg-msft left a comment

Choose a reason for hiding this comment

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

I haven't used ASP.NET in five years and don't recognize any of this... so feel free to disregard most of my comments/questions if you're following standard patterns I'm oblivious to.

The only real issue I see is specializing everything to TokenCredential when we have other types for different services. I'm okay with it if you and @schaabs decide that's the plan, but think it'll feel weird if users are trying to setup a default StorageSharedKeyCredential to use with all their BlobClients.

@@ -39,9 +39,10 @@

<PropertyGroup>
<IsTestProject Condition="$(MSBuildProjectName.EndsWith('.Tests'))">true</IsTestProject>
<IsSamplesProject Condition="$(MSBuildProjectName.EndsWith('.Samples'))">true</IsSamplesProject>
Copy link
Member

Choose a reason for hiding this comment

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

Nit - any reason not to follow our existing .Samples.Tests approach for testable samples?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I really want to give folks outside our team an easy way to play with new APIs in ASP.NET Core app

Copy link
Member

Choose a reason for hiding this comment

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

We can also consider checking for /samples/ in the path.


services.AddAzureClients(builder => {

builder.AddSecretClient(Configuration.GetSection("KeyVault"))
Copy link
Member

Choose a reason for hiding this comment

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

When I see it written like this, I wonder if we should be calling it AddKeyVaultSecretClient.

Copy link
Contributor Author

@pakrym pakrym Jul 17, 2019

Choose a reason for hiding this comment

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

We've been back and forth on this couple of times with @KrzysztofCwalina, I'm open to any naming schema but would prefer to follow up on this later.

sdk/core/Azure.Core.Extensions/samples/Startup.cs Outdated Show resolved Hide resolved
return credential;
}

// TODO: More logging
Copy link
Member

Choose a reason for hiding this comment

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

Should we throw an exception if they don't provide enough detail? Like say they forgot the clientId, would it be helpful to tell them that here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We should, something similar to constructor not found exception.

sdk/core/Azure.Core/src/Extensions/IAzureClientsBuilder.cs Outdated Show resolved Hide resolved
@pakrym pakrym merged commit 336bc87 into Azure:master Jul 17, 2019
@pakrym pakrym deleted the pakrym/creds branch July 17, 2019 18:44
openapi-bot-tih-dev bot referenced this pull request in AzureSDKAutomation/azure-sdk-for-net Aug 7, 2019
openapi-bot-tih-dev bot referenced this pull request in AzureSDKAutomation/azure-sdk-for-net Aug 7, 2019
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.

4 participants