I'm not sure if I confused things... the clients that I mentioned are wrappers for the REST API implemented with Jersey client, so the CLI does exclusively use the REST API.
I was just drawing attention to the clients to say that part of the work is outside of the CLI in nifi-registry-client to allow it to support kerberos auth. On Thu, Jun 13, 2019 at 1:54 PM Shawn Weeks <[email protected]> wrote: > > Ok, I was thinking the CLI used the Rest API exclusively and that's what I > was missing. Unfortunately I don't have the option to use self-signed > certificate due to organizational security policies and we don't have a way > to get SSL Certificates issued to individuals only servers. > > Thanks > Shawn > > On 6/13/19, 12:30 PM, "Bryan Bende" <[email protected]> wrote: > > Just to further elaborate, within the CLI there are commands that work > against registry and commands that work against NiFi. For registry > commands, they use the Java client that is provided by registry [1]. > For NiFi commands, there is mini client developed as need with in the > CLI [2]. > > None of these client calls currently have any concept of a JWT/token. > > In order to do the kerberos auth correctly across both systems, I > think both of these clients would need to be updated to support a > method that called the /access/kerberos end point to obtain a token, > and then also provide a way to pass back that token on future > requests. It would likely be the CLI's job to store that token > somewhere (in memory for interactive shell, or on filesystem for > individual executions) and pass it back on each request. In order to > call the /access/kerberos end-point there also needs to be code in the > client that handles the negotiation to provide the kerberos > credentials that are present from having done a kinit. > > Long story short, Andy's first suggest would be a much easier option > with no code changes. > > [1] > https://github.com/apache/nifi-registry/tree/master/nifi-registry-core/nifi-registry-client > [2] > https://github.com/apache/nifi/tree/master/nifi-toolkit/nifi-toolkit-cli/src/main/java/org/apache/nifi/toolkit/cli/impl/client > > On Thu, Jun 13, 2019 at 1:28 PM Andy LoPresto <[email protected]> > wrote: > > > > You’ll probably have to write (minimal) code to expose the > ClientBuilder constructor/factory methods to the part that parses > command-line arguments. > > > > Andy LoPresto > > [email protected] > > [email protected] > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > > > > On Jun 13, 2019, at 10:27 AM, Shawn Weeks <[email protected]> > wrote: > > > > > > Is there a way to pass 2 currently? Because you can get the token via > curl like I’m currently doing? > > > > > > Thanks > > > Shawn > > > > > > Sent from my iPhone > > > > > >> On Jun 13, 2019, at 12:21 PM, Andy LoPresto <[email protected]> > wrote: > > >> > > >> I see a couple choices here: > > >> > > >> 1. Use the CA to generate and sign a new certificate for > deployments. This certificate would not be as sensitive as the server > certificate, as you can put stricter permissions on that identity within the > NiFi access controls, and the cert would be issued for a DN that cannot be > used to impersonate the server itself. Use this certificate to authenticate > for deployment activities. > > >> 2. Manually extract the user’s JWT from the Developer Tools in your > browser and pass that into the CLI. This token expires regularly, so you will > need to continually update it. > > >> 3. Build the Kerberos implementation of the authentication aspects > of the CLI toolkit. > > >> > > >> Andy LoPresto > > >> [email protected] > > >> [email protected] > > >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > >> > > >>> On Jun 13, 2019, at 10:00 AM, Shawn Weeks > <[email protected]> wrote: > > >>> > > >>> For our organization the server certificate is considered sensitive > and not available to the users who need to deploy to NiFi. Actual > authentication to NiFi is handled through Knox and our SSO Service so the end > user never deals with SSL or has access to a certificate. Originally I > started down the path of writing a bunch of tools based on NiPyAPI to handle > deployments but since the CLI already does that I was hoping to save some > work. Currently we do several other things via rest using the Kerberos Token. > > >>> > > >>> As I looked through the tool kit CLI I was seeing that auth token > being passed into all the rest calls so I was hoping I could hijack wherever > that was being generated via 2way ssl and add an option to call Kerberos > instead to get the token. When I say token I mean the auth bearer token that > you can get from a post request to /access/kerberos in NiFi and > /access/token/Kerberos in NiFi registry. > > >>> > > >>> Thanks > > >>> Shawn > > >>> > > >>> On 6/12/19, 12:06 PM, "Bryan Bende" <[email protected]> wrote: > > >>> > > >>> I meant to say that you obviously could generate certs for CLI > users, but I > > >>> was just mentioning an alternative where you can proxy an identity. > > >>> > > >>> Right now the CLI never obtains a token because it is all cert > based. > > >>> > > >>>> On Wed, Jun 12, 2019 at 1:03 PM Bryan Bende <[email protected]> > wrote: > > >>>> > > >>>> Right now the idea is that whoever is running the CLI would have > access to > > >>>> a NiFi server certificate and then you can proxy any user you > want. There > > >>>> should be examples of this in the readme or toolkit guide. > > >>>> > > >>>> Supporting Kerberos auth was something I wanted to do, but it’s > definitely > > >>>> not a trivial effort. > > >>>> > > >>>> On Wed, Jun 12, 2019 at 12:57 PM Andy LoPresto > <[email protected]> > > >>>> wrote: > > >>>> > > >>>>> Shawn, > > >>>>> > > >>>>> I’m not sure I understand your question. > > >>>>> > > >>>>> I am in the process of refactoring the TLS Toolkit to integrate > with > > >>>>> public certificate authorities, so in the near future it will be > easier to > > >>>>> use certificates signed by external authorities rather than > self-signed. > > >>>>> > > >>>>> My understanding is that you are talking about the CLI Toolkit > rather > > >>>>> than the TLS Toolkit, but your reference to “token” was > ambiguous, so I’m > > >>>>> going to proceed with the understanding that you are referring to > the JWT > > >>>>> token used to identify an authenticated user when communicating > with the > > >>>>> NiFi API. > > >>>>> > > >>>>> You may want to look at JerseyNiFiClient [1], which has methods > for > > >>>>> getting various clients given an authentication token. > > >>>>> > > >>>>> You can create the token via the POST /access/kerberos API [2]. > > >>>>> > > >>>>> [1] > > >>>>> > https://github.com/apache/nifi/blob/master/nifi-toolkit/nifi-toolkit-cli/src/main/java/org/apache/nifi/toolkit/cli/impl/client/nifi/impl/JerseyNiFiClient.java#L163 > > >>>>> < > > >>>>> > https://github.com/apache/nifi/blob/master/nifi-toolkit/nifi-toolkit-cli/src/main/java/org/apache/nifi/toolkit/cli/impl/client/nifi/impl/JerseyNiFiClient.java#L163 > > >>>>>> > > >>>>> [2] https://nifi.apache.org/docs/nifi-docs/rest-api/index.html < > > >>>>> https://nifi.apache.org/docs/nifi-docs/rest-api/index.html> > > >>>>> > > >>>>> Andy LoPresto > > >>>>> [email protected] > > >>>>> [email protected] > > >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D > EF69 > > >>>>> > > >>>>>> On Jun 12, 2019, at 9:39 AM, Shawn Weeks > <[email protected]> > > >>>>> wrote: > > >>>>>> > > >>>>>> I work in an environment reluctant to create self signed ssl > > >>>>> certificates and I’m looking at the feasibility of having the > toolkit cli > > >>>>> authenticate via Kerberos. I was expecting it to be as simple as > adding > > >>>>> another way to get the authentication token but I’m having > trouble figuring > > >>>>> out exactly when the token is created. I see lots of references > to it after > > >>>>> it’s been created. > > >>>>>> > > >>>>>> Thanks > > >>>>>> Shawn > > >>>>> > > >>>>> -- > > >>>> Sent from Gmail Mobile > > >>>> > > >>> -- > > >>> Sent from Gmail Mobile > > >>> > > >>> > > >> > > > >
