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