[
https://issues.apache.org/jira/browse/NIFI-7064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Mashkov updated NIFI-7064:
---------------------------------
Description:
HandleHTTPRequest processor as server, supports 2Way SSL( ie client
authentication). InvokeHTTP processor as client, unfortunately not. I would
like provide my patch for InvokeHTTP processor.See attach.
Here some comments for code.
I added Client.Auth methods
I added hostname validator.
Due to original code base and chosen HTTP client, I changed OkHttpClient
reference to OkHttpClient.Builder for host validation handler. I have not way
to support EL in properties and pass them to handler from setupto trigger via
context.
{code:java}
AtomicReference<OkHttpClient.Builder> okHttpClientBuilderAtomicReferenc{code}
Most hard and long operations done before trigger, while scheduler starts,
building client is relatively lightweight.
Some comments about host validator, reasons to do this.
My case is build RESTful services with 2-way SSL authentication by IP. Remote
client can be a servers at same time as a clients, like mutual communication,
but no domains, only IPs in green field. More over, clients can change
dynamically their IP due to selected channel, LAN or Cellular, here is not way
to provide SAN to certificate at configuration. Now you can provide dynamically
via EL/param IP addresses to check hostname for client authentication.
PS. It's not clear code, why processor build SSLContext in SSL Context
Controlller, but not use it anyhow? This is strange and unclear, possibly, here
we can reduce the code.
PPS. It not clear, how to build tests for this case.
Sincerely,
Dmitry.
was:
HandleHTTPRequest processor as server, supports 2Way SSL( ie client
authentication). InvokeHTTP processor as client, unfortunately not. I would
like provide my patch for InvokeHTTP processor.See attach.
Here some comments for code.
I added Client.Auth methods
I added hostname validator.
Due to original code base and chosen HTTP client, I changed OkHttpClient
reference to OkHttpClient.Builder for host validation handler. I have not way
to support EL in properties and pass them to handler from setupto trigger via
context.
{code:java}
AtomicReference<OkHttpClient.Builder> okHttpClientBuilderAtomicReferenc{code}
Most hard and long operations done before while scheduler starts, building
client is relatively lightweight.
Some comments about host validator, reasons to do this.
My case is build RESTful services with 2-way SSL authentication by IP. Remote
client can be a servers at same time as a clients, like mutual communication,
but no domains, only IPs in green field. More over, clients can change
dynamically their IP due to selected channel, LAN or Cellular, here is not way
to provide SAN to certificate at configuration. Now you can provide dynamically
via EL/param IP addresses to check hostname for client authentication.
PS. It's not clear code, why processor build SSLContext in SSL Context
Controlller, but not use it anyhow? This is strange and unclear, possibly, here
we can reduce the code.
PPS. It not clear, how to build tests for this case.
Sincerely,
Dmitry.
> Support 2-way SSL by InvokeHTTP processor
> -----------------------------------------
>
> Key: NIFI-7064
> URL: https://issues.apache.org/jira/browse/NIFI-7064
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework, Security
> Affects Versions: 1.10.0
> Reporter: Dmitry Mashkov
> Priority: Major
> Labels: features, patch, ready-to-commit, security
> Attachments: InvokeHTTP_2-way_SSL_support.patch
>
>
> HandleHTTPRequest processor as server, supports 2Way SSL( ie client
> authentication). InvokeHTTP processor as client, unfortunately not. I would
> like provide my patch for InvokeHTTP processor.See attach.
> Here some comments for code.
> I added Client.Auth methods
> I added hostname validator.
> Due to original code base and chosen HTTP client, I changed OkHttpClient
> reference to OkHttpClient.Builder for host validation handler. I have not way
> to support EL in properties and pass them to handler from setupto trigger via
> context.
> {code:java}
> AtomicReference<OkHttpClient.Builder> okHttpClientBuilderAtomicReferenc{code}
> Most hard and long operations done before trigger, while scheduler starts,
> building client is relatively lightweight.
> Some comments about host validator, reasons to do this.
> My case is build RESTful services with 2-way SSL authentication by IP. Remote
> client can be a servers at same time as a clients, like mutual communication,
> but no domains, only IPs in green field. More over, clients can change
> dynamically their IP due to selected channel, LAN or Cellular, here is not
> way to provide SAN to certificate at configuration. Now you can provide
> dynamically via EL/param IP addresses to check hostname for client
> authentication.
>
> PS. It's not clear code, why processor build SSLContext in SSL Context
> Controlller, but not use it anyhow? This is strange and unclear, possibly,
> here we can reduce the code.
> PPS. It not clear, how to build tests for this case.
>
>
> Sincerely,
> Dmitry.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
