[
https://issues.apache.org/jira/browse/KNOX-3377?focusedWorklogId=1030253&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1030253
]
ASF GitHub Bot logged work on KNOX-3377:
----------------------------------------
Author: ASF GitHub Bot
Created on: 14/Jul/26 09:22
Start Date: 14/Jul/26 09:22
Worklog Time Spent: 10m
Work Description: smolnar82 opened a new pull request, #1305:
URL: https://github.com/apache/knox/pull/1305
[KNOX-3377](https://issues.apache.org/jira/browse/KNOX-XXXX) - Support
secure LDAP (LDAPS) for the Knox embedded LDAP service
## What changes were proposed in this pull request?
`KnoxLDAPService` previously operated over plaintext LDAP only, on both of
its connection paths. This PR adds configurable, credential-store-integrated
LDAPS support to both, and updates the docker-based integration tests to
exercise the feature end-to-end. The three commits are self-contained:
1. Front-end (embedded server) LDAPS - the embedded ApacheDS server can now
expose a TLS listener instead of accepting only plaintext.
- New config in the existing gateway.ldap.* namespace (defaults off,
behavior unchanged):
- `gateway.ldap.ssl.enabled`
- `gateway.ldap.ssl.keystore.path` (defaults to the gateway identity
keystore)
- `gateway.ldap.ssl.keystore.password.alias` (defaults to the gateway
identity keystore password)
- `gateway.ldap.ssl.enabled.cipher.suites` (optional)
- The keystore password is resolved through `AliasService`, consistent
with the existing bind-password handling. Invalid SSL config (missing keystore)
fails fast at startup with a clear message.
2. Backend (proxy) LDAPS - `LdapProxyBackend` can now connect to the
remote/backing LDAP server over LDAPS. Before, an `ldaps://` URL was parsed but
SSL was never enabled on the connection, so secure backend connections silently
did not work. TLS is applied to both the pooled search connections and the
authentication bind.
Per-backend config (`gateway.ldap.interceptor.<name>.*`): `useSsl`
(auto-enabled by an `ldaps://` URL), `trustAllCertificates`,
`trustStore/trustStoreType/trustStorePassword`, `sslProtocol`,
`enabledProtocols`, `enabledCipherSuites`, `connectionTimeout`.
- Required dependency alignment for client-side LDAPS to work under the
`MINA 2.2.8` that Knox ships (for CVEs): `Apache Directory client API 2.0.0 →
2.1.8` (2.0.0's SSL code calls MINA APIs removed in 2.2.x), and `ApacheDS
server 2.0.0.AM26 → 2.0.0.AM27` (AM26's LdapsInitializer references
`NoVerificationTrustManager`, removed in directory-api 2.1.8; AM27 is built for
2.1.x + MINA 2.2.x). MINA stays at 2.2.8.
All directory-api artifacts are pinned to one version;
`commons-collections4` is converged to 4.5.0; and the legacy `jdk15on`
BouncyCastle that AM27 pulls is excluded in favor of Knox's `jdk18on` artifacts
(same packages), keeping `dependency:analyze` and the shipped BouncyCastle
consistent.
3. Integration test over LDAPS - the docker-based LDAP proxy search test now
runs entirely over TLS: the client connects to the embedded Knox LDAP service
over LDAPS, and Knox proxies to the demo LDAP backend over LDAPS. The demo LDAP
(SimpleLdapDirectoryServer) gained optional system-property-driven SSL;
ldap.sh/gateway.sh provision dev keystores and the knoxldap Shiro realm was
moved to ldaps:// (its cert imported into the JVM cacerts so the JNDI realm
trusts it).
## How was this patch tested?
- Unit tests (gateway-server):
- Front-end: TLS handshake presenting the configured certificate (JSSE
SSLSocket), plaintext-access-to-secure-port rejection, and missing-keystore
fail-fast.
- Backend: a new `LdapProxyBackendSslTest` starts an SSL-enabled embedded
ApacheDS instance and drives the backend over TLS (user/group lookups and
binds), and verifies an untrusted server certificate is rejected when
validation is enabled.
- Full LDAP package (129 tests) passes against the upgraded ApacheDS AM27
/ directory-api 2.1.8, plus `gateway-demo-ldap` and `gateway-util-common`.
- Build: reactor-wide `mvn validate` (dependency convergence) and
`dependency:analyze-only` pass after the version bumps and BouncyCastle
exclusion.
- Manual: `mvn -Ppackage clean install` then the docker-compose stack.
## Integration Tests
Updated `.github/workflows/tests/test_knox_ldap_proxy_search.py` to connect
over LDAPS (use_ssl=True, Tls(validate=CERT_NONE) for the self-signed dev
cert), and the supporting docker fixtures (`gateway-site.xml`, `gateway.sh`,
`ldap.sh`, `knoxldap.xml`) so both the client → Knox and Knox → demo-LDAP legs
are TLS.
`test_knox_auth_service_and_ldap.py` is unchanged but now implicitly
exercises the secure backend (group resolution flows through it).
Full stack result: 32/32 integration tests pass, including the
`knoxldap/remoteauth/extauthz` auth suites that authenticate through the
now-LDAPS embedded service.
## UI Changes
N/A
Issue Time Tracking
-------------------
Worklog Id: (was: 1030253)
Remaining Estimate: 0h
Time Spent: 10m
> Support secure LDAP (LDAPS) for the Knox embedded LDAP service
> --------------------------------------------------------------
>
> Key: KNOX-3377
> URL: https://issues.apache.org/jira/browse/KNOX-3377
> Project: Apache Knox
> Issue Type: Task
> Components: Server
> Affects Versions: 3.0.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
> Priority: Critical
> Fix For: 3.0.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The org.apache.knox.gateway.services.ldap.KnoxLDAPService currently operates
> over plaintext LDAP only. There are two distinct connection paths, and
> neither supports TLS today:
> 1. {*}Front-end{*}: the embedded ApacheDS server that clients connect to.
> {{KnoxLDAPServerManager}} binds a plain {{{}TcpTransport{}}}; no keystore/SSL
> is ever configured, so the listener is plaintext-only.
> 2. *Backend:* the {{LdapProxyBackend}} connection to the remote/backing LDAP
> server. An {{ldaps://}} URL is parsed for host/port, but SSL is never enabled
> on the {{{}LdapConnectionConfig{}}}, so the connection is always plaintext
> (and would fail against a real LDAPS endpoint).
> This JIRA adds configurable, credential-store-integrated TLS support to both
> paths so Knox can expose LDAPS to clients and proxy to a secure backend LDAP
> server.
> +Scope:+
> - Secure transport on the embedded server (front-end)
> - Secure transport for the proxy backend (backend)
> - Configuration must fit the existing {{gateway.ldap.*}} namespace and
> resolve secrets through the gateway credential store (AliasService) where
> applicable.
> - Unit/integration test coverage for both paths.
> +Out of scope / follow-ups:+
> - StartTLS for the backend (LDAPS only for now; StartTLS through the pooled
> connection factory needs a dedicated factory and can be a follow-up).
> - Mutual TLS / client-certificate authentication.
> _Dependency note:_ Enabling client-side LDAPS requires aligning the Apache
> Directory API / ApacheDS server versions with the MINA 2.2.8 that Knox ships
> for CVE reasons (details in the backend sub-task). MINA itself is not
> downgraded.
> Acceptance criteria:
> - LDAPS can be enabled for the embedded server and for the proxy backend via
> configuration.
> - Certificate material and passwords are sourced from the gateway
> keystore/credential store (front-end) and configurable trust material
> (backend).
> - Existing plaintext behavior is unchanged when the new options are disabled
> (default off).
> - All existing LDAP tests continue to pass; new tests cover the secure paths.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
