<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>question Re: HandleHttpRequest / StandardRestrictedSSLContextService in Support Questions</title>
    <link>https://community.cloudera.com/t5/Support-Questions/HandleHttpRequest-StandardRestrictedSSLContextService/m-p/371772#M241082</link>
    <description>&lt;P&gt;&lt;a href="https://community.cloudera.com/t5/user/viewprofilepage/user-id/105206"&gt;@svenhans&lt;/a&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I would recommend you file an Apache NiFi Jira ticket for your new component processor request.&lt;BR /&gt;&lt;A href="https://issues.apache.org/jira/projects/NIFI" target="_blank"&gt;https://issues.apache.org/jira/projects/NIFI&lt;/A&gt;&lt;BR /&gt;&lt;BR /&gt;Let's say an AD/LDAP lookup processor was create. that means supplying the ldap search configuration properties along with manager DN and manager password in order to do the lookup.&amp;nbsp; To avoid exposing that to other users in NiFi, maybe creating an LDAPLookup Controller service would be better.&amp;nbsp; Then create a processor like getLDAPUser that gets configured to use that LDAPLookup CS along with a StandardSSL CS with user defined AD/LDAP attributes to return and require a user Identity property value.&amp;nbsp; &amp;nbsp;&lt;BR /&gt;&lt;BR /&gt;Of course you run the risk of other who have access to your NiFi copying your processor and using it to fetch any details they want about your AD/LDAP users.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Matt&lt;/P&gt;</description>
    <pubDate>Tue, 30 May 2023 18:19:12 GMT</pubDate>
    <dc:creator>MattWho</dc:creator>
    <dc:date>2023-05-30T18:19:12Z</dc:date>
    <item>
      <title>HandleHttpRequest / StandardRestrictedSSLContextService</title>
      <link>https://community.cloudera.com/t5/Support-Questions/HandleHttpRequest-StandardRestrictedSSLContextService/m-p/371386#M240964</link>
      <description>&lt;P&gt;How do I restrict the access to an endpoint provided by HandleHttpRequest to specific users?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I did setup successfully a&amp;nbsp;HandleHttpRequest-HandleHttpResponse chain, with Client Authentication = "Need Authentication". I provided a key- and truststore and users with a client certificate trusted by CA cert in the truststore can access the endpoint.&amp;nbsp;&lt;/P&gt;&lt;P&gt;However, I do not want everybody in my company to access this endpoint, I want to restrict this to a small group of users (actually to one single server).&amp;nbsp;&lt;/P&gt;&lt;P&gt;For testing purposes I created an empty truststore and imported into this truststore only my client certificate. However, now I cannot access the endpoint anymore (&lt;SPAN&gt;ERR_BAD_SSL_CLIENT_AUTH_CERT).&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;How do I configure the JKS truststore to only trust one specific client? Or how do I configure&amp;nbsp;HandleHttpRequest processor?&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;If this is not possible, are there any other possibilities?&lt;/P&gt;&lt;P&gt;Could I somehow use a Nifi-REST-API-Token?&lt;/P&gt;&lt;P&gt;Could I somehow authenticate with the help of LDAP?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Thank you!&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Tue, 23 May 2023 14:11:07 GMT</pubDate>
      <guid>https://community.cloudera.com/t5/Support-Questions/HandleHttpRequest-StandardRestrictedSSLContextService/m-p/371386#M240964</guid>
      <dc:creator>svenhans</dc:creator>
      <dc:date>2023-05-23T14:11:07Z</dc:date>
    </item>
    <item>
      <title>Re: HandleHttpRequest / StandardRestrictedSSLContextService</title>
      <link>https://community.cloudera.com/t5/Support-Questions/HandleHttpRequest-StandardRestrictedSSLContextService/m-p/371391#M240967</link>
      <description>&lt;P&gt;&lt;a href="https://community.cloudera.com/t5/user/viewprofilepage/user-id/105206"&gt;@svenhans&lt;/a&gt;&amp;nbsp;Welcome to the Cloudera Community!&lt;BR /&gt;&lt;BR /&gt;To help you get the best possible solution, I have tagged our NiFi experts&amp;nbsp;&lt;a href="https://community.cloudera.com/t5/user/viewprofilepage/user-id/35454"&gt;@MattWho&lt;/a&gt;&amp;nbsp;&lt;a href="https://community.cloudera.com/t5/user/viewprofilepage/user-id/80381"&gt;@SAMSAL&lt;/a&gt;&amp;nbsp; who may be able to assist you further.&lt;BR /&gt;&lt;BR /&gt;Please keep us updated on your post, and we hope you find a satisfactory solution to your query.&lt;/P&gt;</description>
      <pubDate>Tue, 23 May 2023 15:15:51 GMT</pubDate>
      <guid>https://community.cloudera.com/t5/Support-Questions/HandleHttpRequest-StandardRestrictedSSLContextService/m-p/371391#M240967</guid>
      <dc:creator>DianaTorres</dc:creator>
      <dc:date>2023-05-23T15:15:51Z</dc:date>
    </item>
    <item>
      <title>Re: HandleHttpRequest / StandardRestrictedSSLContextService</title>
      <link>https://community.cloudera.com/t5/Support-Questions/HandleHttpRequest-StandardRestrictedSSLContextService/m-p/371614#M241028</link>
      <description>&lt;P&gt;&lt;a href="https://community.cloudera.com/t5/user/viewprofilepage/user-id/105206"&gt;@svenhans&lt;/a&gt;&amp;nbsp;The truststore would contain the public certificate for your user and not the PrivateKeyEntry.&amp;nbsp; Is that what you added to the truststore?&amp;nbsp; Is your clientAuth certificate signed by a CA?&lt;BR /&gt;&lt;BR /&gt;Another option is to handle this programmatically via your NiFi dataflow.&amp;nbsp; Immediately after your HandleHTTPRequest processor, you could add a RouteOnAttribute processor that checks the value of the "&lt;SPAN&gt;http.remote.user" attribute added by the HandleHttpRequest and terminates any FlowFile where the remote-user is not allowed.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;FONT face="batang,apple gothic"&gt;If you found that the provided solution(s) assisted you with your query, please take a moment to login and click&lt;/FONT&gt;&amp;nbsp;&lt;FONT face="arial black,avant garde" color="#FF0000"&gt;Accept as Solution&amp;nbsp;&lt;/FONT&gt;&lt;FONT face="batang,apple gothic" color="#000000"&gt;below each response that helped.&lt;BR /&gt;&lt;BR /&gt;Thank you,&lt;/FONT&gt;&lt;/P&gt;&lt;P&gt;&lt;FONT face="batang,apple gothic" color="#000000"&gt;Matt&lt;/FONT&gt;&lt;/P&gt;</description>
      <pubDate>Fri, 26 May 2023 17:31:21 GMT</pubDate>
      <guid>https://community.cloudera.com/t5/Support-Questions/HandleHttpRequest-StandardRestrictedSSLContextService/m-p/371614#M241028</guid>
      <dc:creator>MattWho</dc:creator>
      <dc:date>2023-05-26T17:31:21Z</dc:date>
    </item>
    <item>
      <title>Re: HandleHttpRequest / StandardRestrictedSSLContextService</title>
      <link>https://community.cloudera.com/t5/Support-Questions/HandleHttpRequest-StandardRestrictedSSLContextService/m-p/371699#M241061</link>
      <description>&lt;P&gt;&lt;a href="https://community.cloudera.com/t5/user/viewprofilepage/user-id/35454"&gt;@MattWho&lt;/a&gt;&amp;nbsp;In my test the truststore did contain just a single certificate, the public certificate of the authorized user (not private key). However this did not work, the TLS handshake did fail.&lt;/P&gt;&lt;P&gt;In the end I did solve my problem like you suggested, with RouteOnAttribute on "http.subject.dn".&lt;/P&gt;&lt;P&gt;It would be nice to have a processor for accessing AD to compare if the selected dn is member of some AD-group.&lt;/P&gt;</description>
      <pubDate>Tue, 30 May 2023 08:14:41 GMT</pubDate>
      <guid>https://community.cloudera.com/t5/Support-Questions/HandleHttpRequest-StandardRestrictedSSLContextService/m-p/371699#M241061</guid>
      <dc:creator>svenhans</dc:creator>
      <dc:date>2023-05-30T08:14:41Z</dc:date>
    </item>
    <item>
      <title>Re: HandleHttpRequest / StandardRestrictedSSLContextService</title>
      <link>https://community.cloudera.com/t5/Support-Questions/HandleHttpRequest-StandardRestrictedSSLContextService/m-p/371772#M241082</link>
      <description>&lt;P&gt;&lt;a href="https://community.cloudera.com/t5/user/viewprofilepage/user-id/105206"&gt;@svenhans&lt;/a&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I would recommend you file an Apache NiFi Jira ticket for your new component processor request.&lt;BR /&gt;&lt;A href="https://issues.apache.org/jira/projects/NIFI" target="_blank"&gt;https://issues.apache.org/jira/projects/NIFI&lt;/A&gt;&lt;BR /&gt;&lt;BR /&gt;Let's say an AD/LDAP lookup processor was create. that means supplying the ldap search configuration properties along with manager DN and manager password in order to do the lookup.&amp;nbsp; To avoid exposing that to other users in NiFi, maybe creating an LDAPLookup Controller service would be better.&amp;nbsp; Then create a processor like getLDAPUser that gets configured to use that LDAPLookup CS along with a StandardSSL CS with user defined AD/LDAP attributes to return and require a user Identity property value.&amp;nbsp; &amp;nbsp;&lt;BR /&gt;&lt;BR /&gt;Of course you run the risk of other who have access to your NiFi copying your processor and using it to fetch any details they want about your AD/LDAP users.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Matt&lt;/P&gt;</description>
      <pubDate>Tue, 30 May 2023 18:19:12 GMT</pubDate>
      <guid>https://community.cloudera.com/t5/Support-Questions/HandleHttpRequest-StandardRestrictedSSLContextService/m-p/371772#M241082</guid>
      <dc:creator>MattWho</dc:creator>
      <dc:date>2023-05-30T18:19:12Z</dc:date>
    </item>
  </channel>
</rss>

