Extend AuthenticationBuilder to support SSLContext for mTLS authentication

[jiteshkhatri11]

Problem

AuthenticationBuilder currently has no way to set an SSLContext for
client certificate / mTLS based authentication.

Although HTTP transporters already consume AuthenticationContext.SSL_CONTEXT,
for example in JdkTransporter:

sslContext = repoAuthContext.get(AuthenticationContext.SSL_CONTEXT, SSLContext.class);

there was no way for callers to actually set it via AuthenticationBuilder.
The only workaround was via system properties as described in
https://maven.apache.org/guides/mini/guide-repository-ssl.html

Closes #1851

---

Solution

Adds a new addSslContext(SSLContext) method to AuthenticationBuilder,
consistent with the existing addHostnameVerifier(HostnameVerifier) pattern,
so that mTLS credentials can be set and consumed through
AuthenticationContext.SSL_CONTEXT.

Usage

Authentication auth = new AuthenticationBuilder()
    .addSslContext(mySSLContext)
    .build();

---

Testing

• mvn verify passes locally — 422 tests, 0 failures, 0 errors.
• Unit test for addSslContext() can be added if maintainer requests it.

---

Checklist

• Pull request addresses just one issue
• Description explains what, how, and why
• Commit has a meaningful subject line and body
• Unit tests written
• mvn verify passed locally
• Integration tests run
• I hereby declare this contribution to be licenced under the
  Apache License Version 2.0, January 2004

[cstamas]

Please add @since

Suggested change

	*/
	* @since 2.0.19
	*/

[gnodet]

Minor Javadoc suggestion: consider adding a @see cross-reference to AuthenticationContext.SSL_CONTEXT for discoverability, similar to how the constant's own Javadoc references javax.net.ssl.SSLContext:

Suggested change

	* @return this builder for chaining, never {@code null}
	* Adds an SSL context for SSL/TLS connections. <strong>Note:</strong> This method assumes that all possible
	* instances of the SSL context's runtime type exhibit the exact same behavior, i.e. the behavior of the SSL
	* context depends solely on the runtime type and not on any configuration. For SSL contexts that do not fit
	* this assumption, use {@link #addCustom(Authentication)} with a suitable implementation instead.
	*
	* @param sslContext the SSL context, may be {@code null}
	* @return this builder for chaining, never {@code null}
	* @see AuthenticationContext#SSL_CONTEXT
	*/

This is purely optional — it helps users navigating the API discover the constant key and the Javadoc on it that describes the expected type.

[gnodet]

Thanks for this contribution, @jiteshkhatri11! This is a well-motivated addition — addSslContext() is the natural complement to the existing addHostnameVerifier() method (added back in Bug 411445 / commit 78261748), and it fills a real gap for mTLS use cases.

What I checked:

• Code correctness: The implementation correctly mirrors addHostnameVerifier — null guard, ComponentAuthentication delegation with AuthenticationContext.SSL_CONTEXT as the key, and builder chaining. ✔️

• Import ordering: javax.net.ssl.SSLContext is correctly placed alongside HostnameVerifier in the javax import group, before the blank-line separator and java.util imports. ✔️

• Javadoc: The <strong>Note:</strong> warning about ComponentAuthentication semantics (digest based on runtime type, not configuration) is correctly adapted from addHostnameVerifier. This is important — ComponentAuthentication.digest() uses value.getClass().getName(), so two SSLContext instances of the same implementation class but configured with different KeyManagers will produce the same digest. The Javadoc properly directs users to addCustom(Authentication) for configuration-sensitive contexts. ✔️

• Transporter support: All three transport implementations already read AuthenticationContext.SSL_CONTEXT:

  • JdkTransporter.java (line 478)
  • JettyTransporter.java (line 378)
  • ConnMgrConfig.java (line 67, used by the Apache transport)

  So the new builder method will work across all currently supported transports. ✔️

• Null-safety: Consistent with every other method in AuthenticationBuilder — null input is a no-op, returns this. ✔️

One minor Javadoc suggestion (posted as an inline comment): consider adding @see AuthenticationContext#SSL_CONTEXT to help users navigating the API find the constant and its documentation. This is optional.

On tests: I see the PR checklist has "Unit tests written" unchecked. There's no AuthenticationBuilderTest in the project today — the underlying ComponentAuthentication is already covered by ComponentAuthenticationTest (fill, digest, equals, hashCode). Given that this is a thin convenience method delegating to well-tested infrastructure, the lack of a dedicated test isn't a blocker. That said, if you'd like to add one, the existing ComponentAuthenticationTest pattern would work well as a template.

Overall this looks good to me. Clean, minimal, follows the established pattern.

— gnodet

[jiteshkhatri11]

Thanks for the reviews and feedback, @cstamas and @gnodet.

I've updated the Javadoc to include the requested @since 2.0.19 tag and added the @see AuthenticationContext#SSL_CONTEXT reference for discoverability.

Please let me know if there are any further changes you'd like me to make.