[ 
https://issues.apache.org/jira/browse/NIFI-4273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Koji Kawamura resolved NIFI-4273.
---------------------------------
       Resolution: Fixed
         Assignee: Koji Kawamura
    Fix Version/s: 1.7.0

This use-case is now supported by NIFI-4932.

[~WaterslideKid] Please refer NiFi Admin guid for how to configure NiFi 
hostname/port for S2S behind a reverse proxy.
https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#site_to_site_reverse_proxy_properties

> incorrect data access urls when using site to site when connecting through 
> reverse proxies.  Inability for site to site data access urls to utilize 
> proxied user identites.
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: NIFI-4273
>                 URL: https://issues.apache.org/jira/browse/NIFI-4273
>             Project: Apache NiFi
>          Issue Type: Bug
>          Components: Core Framework
>    Affects Versions: 1.3.0
>         Environment: ubuntu 16.04 64bit, openjdk version "1.8.0_131"
> OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-2ubuntu1.16.04.3-b11)
> OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)
>            Reporter: WaterslideKid
>            Assignee: Koji Kawamura
>            Priority: Minor
>             Fix For: 1.7.0
>
>
> Issue:
>    Data access using site-to-site binding is based on local environment and 
> does not easily support a reverse proxy configuration.  The UI works great 
> under a reverse proxy configuration, but a site to site configuration fails.  
> It appears that the underlying site to site data access URLs are built from 
> local environment information rather than configuration and do not honor the 
> SSL X-ProxiedEntitiesChain or other reverse proxy context information to 
> build proper URLs.
> My configuration:
> I have two nifi systems that I want to connect to each other via NIFI site to 
> site.  One is monitoring logs and intending to publish these logs by offering 
> a site to site web service/server in order to be collected by a client nifi.  
> My desire is to have the client nifi contact the server to pull logs by 
> connecting through a nginx reverse proxy.  All of this is done over SSL using 
> mutual SSL.  I'm able to get these systems talking to each over directly but 
> having issues talking through a reverse proxy.
> In my preferred configuration, the nifi server behind the reverse proxy is 
> bound to localhost on port 8443.  The reverse proxy is bound to an external 
> ip address on port 4443.  The client is set up to talk to the server using 
> site to iste over the reverse proxy on the external ip on port 4443.  In the 
> UI, the configuration is able to view the flow ports for site to site but 
> data refuses to flow.  The client complains that it is unable to talk with 
> the data channel via site to site to the server because it is unable to 
> connect to <hostname>:8443 - which is incorrect.  It appears that the site to 
> site data channel gets its configuration by choosing the hostname and port of 
> the nifi service rather than obeying the reverse proxy configuration of the 
> UI.  There is no way to configure the client or server to use an alternative 
> port or hostname for site to site data.    
>    I have a successful configuration of a mutual SSL enabled NIFI reverse 
> proxy that allows UI clients to access a NIFI server and pass on client SSL 
> information.
>    Here is my site to site configuration
> {code:java}
> # --- the following is a snipplet from an nginx configuration
> listen 4443 ssl default_server;
> ssl_certificate      /etc/nginx/cert/nifi/server.pem;
> ssl_certificate_key  /etc/nginx/cert/nifi/server.key;
>       #require clients to authenticate with certs that are part of CA
>       #force mutual SSL
>       ssl_client_certificate /etc/nginx/cert/nifi/ca.pem;
>       ssl_verify_client on;
>       ssl on;
>        location / {
>                 #give the reverse proxy server a client certificate for nifi
>                 proxy_ssl_certificate /etc/nginx/cert/nifi/rproxy.pem;
>                 proxy_ssl_certificate_key /etc/nginx/cert/nifi/rproxy.key;
>                 
>                 #note that you have to give this client the "proxy user 
> requests"
>                 #access policy so that it can pass on clients using the
>                 # X-ProxiedEntitiesChain header -- only valid under mutual ssl
>                 #do some other proxy optimization
>                 proxy_buffering off;
>                 #the following are special headers needed by nifi to build 
> proper urls
>                 proxy_set_header X-ProxyScheme https;
>                 proxy_set_header X-ProxyHost $host; 
>                 proxy_set_header X-ProxyPort $server_port;
>                 proxy_set_header X-ProxiedEntitiesChain 
> "<${ssl_client_s_dn}>";
>                 #talk to nifi server bound to localhost
>                 proxy_pass https://127.0.0.1:8443;
>         }
> #-- end sniplet
> {code}
> Attempt #2 -
> I'm able to configure the nginx to listen on 8443 when bound to the external 
> ip and have the nifi service bound to 8443 on the localhost/loopback 
> interface- this configuraiton allows the URLS provided over site to site will 
> work but another issue arrises.  I get a wierd error on the client that 
> states:
> o.a.nifi.remote.StandardRemoteGroupPort 
> RemoteGroupPort[name=nifiout,targets=https://rproxy:8443/nifi] failed to 
> communicate with https://rproxy:8443/nifi due to 
> org.apache.nifi.remote.exception.HandshakeException: 
> StandardRootGroupPort[id=<redacted>] authorization failed for user <redacted> 
> because Unable to modify data transfers to Output Port with ID <redacted>. 
> Contact the system administrator.
> What I have been able to determine is that the site to site data access 
> service is not able to handle the X-ProxiedEntitiesChain to get access the 
> data api.
> Attempt #3 -
> I can get site to site working through a reverse proxy by tricking out the 
> nifi systems to think they are talking directly to each other.  In this 
> configuration I bind the nifi to localhost:8443, bind the reverse proxy on 
> the same host to externalIP:8443 and replicate the nifi client certificates 
> on the nifi endpoint to the nginx proxy.  The nifi client connect through the 
> reverse proxy and the reverse proxy pretends to be the nifi client to talk to 
> the localhost server.  This works.
> This looks like:
> {code:java}
>       #--- the following is a snipplet from an nginx configuration
>        listen $externalip:8443 ssl default_server;
>        ssl_certificate      /etc/nginx/cert/nifi/server.pem;
>       ssl_certificate_key  /etc/nginx/cert/nifi/server.key;
>       #require clients to authenticate with certs that are part of CA
>       #force mutual SSL
>       ssl_client_certificate /etc/nginx/cert/nifi/ca.pem;
>       ssl_verify_client on;
>       ssl on;
>        location / {
>                 #give the reverse proxy server a client certificate for nifi
>                 proxy_ssl_certificate /etc/nginx/cert/nifi/nifi_client.pem;
>                 proxy_ssl_certificate_key 
> /etc/nginx/cert/nifi/nifi_client.key;
>                 #this is replicated from the connecting nifi-client
>                
>                 #do some other proxy optimization
>                 proxy_buffering off;
>                 #talk to nifi server bound to localhost
>                 proxy_pass https://127.0.0.1:8443;
>         }
>          #-- end sniplet
> {code}
> I am able to trick out a reverse proxy in order to get site to site working, 
> but would prefer a configuration option that supports site to site data 
> access through an alternative reverse proxy hostname and port using either a 
> server or client configuration alternative.  Currently the site to site proxy 
> configuration is based on the assumption of a client proxy rather than a 
> server-site reverse proxy.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to