HandleHttpRequest / StandardRestrictedSSLContextService

[#1]

How do I restrict the access to an endpoint provided by HandleHttpRequest to specific users?

I did setup successfully a 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. 

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). 

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 (ERR_BAD_SSL_CLIENT_AUTH_CERT). 

How do I configure the JKS truststore to only trust one specific client? Or how do I configure HandleHttpRequest processor? 

If this is not possible, are there any other possibilities?

Could I somehow use a Nifi-REST-API-Token?

Could I somehow authenticate with the help of LDAP?

Thank you!

[#2]

@svenhans Welcome to the Cloudera Community!

To help you get the best possible solution, I have tagged our NiFi experts @MattWho @SAMSAL  who may be able to assist you further.

Please keep us updated on your post, and we hope you find a satisfactory solution to your query.

[#3 · Accepted solution]

@svenhans The truststore would contain the public certificate for your user and not the PrivateKeyEntry.  Is that what you added to the truststore?  Is your clientAuth certificate signed by a CA?

Another option is to handle this programmatically via your NiFi dataflow.  Immediately after your HandleHTTPRequest processor, you could add a RouteOnAttribute processor that checks the value of the "http.remote.user" attribute added by the HandleHttpRequest and terminates any FlowFile where the remote-user is not allowed.

If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped.

Thank you,

Matt

[#4]

@MattWho 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.

In the end I did solve my problem like you suggested, with RouteOnAttribute on "http.subject.dn".

It would be nice to have a processor for accessing AD to compare if the selected dn is member of some AD-group.

[#5]

@svenhans 

I would recommend you file an Apache NiFi Jira ticket for your new component processor request.
https://issues.apache.org/jira/projects/NIFI

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.  To avoid exposing that to other users in NiFi, maybe creating an LDAPLookup Controller service would be better.  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.   

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.

Matt