Skip to content

Enable client TLS auth for Netty #1390

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

Merged
merged 1 commit into from
Aug 23, 2019
Merged

Conversation

dagnir
Copy link
Contributor

@dagnir dagnir commented Aug 19, 2019

Description

This commit enables customers to configure a TlsKeyManagersProvider on the Netty
client which will be used to authenticate the client during client TLS
authentication.

Motivation and Context

Part of new feature, see #858.

Testing

New unit tests.

Screenshots (if appropriate)

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)

Checklist

  • I have read the CONTRIBUTING document
  • Local run of mvn install succeeds
  • My code follows the code style of this project
  • My change requires a change to the Javadoc documentation
  • I have updated the Javadoc documentation accordingly
  • I have read the README document
  • I have added tests to cover my changes
  • All new and existing tests passed
  • A short description of the change has been added to the CHANGELOG
  • My change is to implement 1.11 parity feature and I have updated LaunchChangelog

License

  • I confirm that this pull request can be released under the Apache 2 license

@dagnir
Copy link
Contributor Author

dagnir commented Aug 19, 2019

Note, builds on #1379, #1384, so those should be merged first.

@dagnir dagnir changed the title Netty tls client auth Enable client TLS auth for Netty Aug 19, 2019
@dagnir dagnir force-pushed the netty-tls-client-auth branch from 7b4d85f to 0e435fd Compare August 20, 2019 23:41
@dagnir
Copy link
Contributor Author

dagnir commented Aug 21, 2019

BTW the JDK11 failure in Travis

[ERROR] Redundant nullcheck of storeIs, which is known to be non-null in software.amazon.awssdk.internal.http.AbstractFileStoreTlsKeyManagersProvider.createKeyStore(Path, String, char[]) [software.amazon.awssdk.internal.http.AbstractFileStoreTlsKeyManagersProvider, software.amazon.awssdk.internal.http.AbstractFileStoreTlsKeyManagersProvider] Redundant null check at AbstractFileStoreTlsKeyManagersProvider.java:[line 50]Another occurrence at AbstractFileStoreTlsKeyManagersProvider.java:[line 53] RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE

appears to caused by this open bug in SpotBugs: spotbugs/spotbugs#756

It's complaining about this bit:

try (InputStream storeIs = Files.newInputStream(storePath)) {
ks.load(storeIs, password);
return ks;
}

@dagnir dagnir force-pushed the netty-tls-client-auth branch from fe3a5fe to 47e73f3 Compare August 22, 2019 01:06
@codecov-io
Copy link

codecov-io commented Aug 23, 2019

Codecov Report

Merging #1390 into master will increase coverage by 0.05%.
The diff coverage is 86.66%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master    #1390      +/-   ##
============================================
+ Coverage     71.13%   71.19%   +0.05%     
- Complexity      650      654       +4     
============================================
  Files           839      843       +4     
  Lines         26538    26608      +70     
  Branches       2091     2097       +6     
============================================
+ Hits          18879    18943      +64     
- Misses         6795     6804       +9     
+ Partials        864      861       -3
Flag Coverage Δ Complexity Δ
#unittests 71.19% <86.66%> (+0.05%) 654 <4> (+4) ⬆️
Impacted Files Coverage Δ Complexity Δ
...amazon/awssdk/http/SdkHttpConfigurationOption.java 0% <0%> (ø) 0 <0> (ø) ⬇️
...are/amazon/awssdk/http/TlsKeyManagersProvider.java 100% <100%> (ø) 1 <1> (?)
...ssdk/internal/http/NoneTlsKeyManagersProvider.java 100% <100%> (ø) 3 <3> (?)
...tp/nio/netty/internal/StaticKeyManagerFactory.java 100% <100%> (ø) 0 <0> (?)
...awssdk/http/nio/netty/NettyNioAsyncHttpClient.java 65.89% <100%> (+0.53%) 0 <0> (ø) ⬇️
...nio/netty/internal/StaticKeyManagerFactorySpi.java 100% <100%> (ø) 0 <0> (?)
...dk/http/nio/netty/internal/NettyConfiguration.java 93.33% <100%> (+0.47%) 0 <0> (ø) ⬇️
...re/amazon/awssdk/http/apache/ApacheHttpClient.java 75.4% <100%> (+0.4%) 0 <0> (ø) ⬇️
...p/nio/netty/internal/AwaitCloseChannelPoolMap.java 89.65% <83.33%> (+0.56%) 0 <0> (ø) ⬇️
...tomization/CodegenCustomizationProcessorChain.java 81.81% <0%> (-8.19%) 0% <0%> (ø)
... and 50 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 313c15e...d101175. Read the comment docs.

keyManagers = keyManagersProvider.keyManagers();
TlsKeyManagersProvider provider = standardOptions.get(TLS_KEY_MANAGERS_PROVIDER);
if (provider == null) {
provider = SystemPropertyTlsKeyManagersProvider.create();
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this still needed now that we have mergeDefaults?

Copy link
Contributor

@millems millems left a comment

Choose a reason for hiding this comment

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

lgtm, other than the one small comment

@dagnir dagnir force-pushed the netty-tls-client-auth branch from d944cbd to c984051 Compare August 23, 2019 16:42
This commit enables customers to configure a TlsKeyManagersProvider on the Netty
client which will be used to authenticate the client during client TLS
authentication.
@dagnir dagnir force-pushed the netty-tls-client-auth branch from c984051 to d101175 Compare August 23, 2019 16:45
@dagnir dagnir merged commit 926b67b into aws:master Aug 23, 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