No, client cert authentication bypasses the JWT behavior completely. Because a client cert is automatically sent on every request, it makes no sense to delegate the credential to a token in that case.
Andy LoPresto [email protected] [email protected] PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Jun 13, 2019, at 11:52 AM, Shawn Weeks <[email protected]> wrote: > > Completely agree on username and password but I'll probably still do > something somewhat generic around access tokens vs 2 way ssl as in the future > there might be something else. On a related note is it possible to get a JWT > with 2 way ssl? If so we could use the same auth method for everything. > > Thanks > Shawn > > On 6/13/19, 1:36 PM, "Bryan Bende" <[email protected]> wrote: > > Ah thanks for pointing that out, I completely forgot that apparently I > was thinking ahead in the JerseyNiFiClient of how we could support > tokens :) > > You would need to make the same changes in the > JerseyNiFiRegistryClient, and then build a new toolkit based on a new > version of nifi-registry-client. > > Also, you are correct that we could support username/password, but I > think Kerberos is much better from a security perspective since you > don't really need to give your credentials to the CLI. With > username/password, you would either need to add those properties to > the .props files for the CLI, which then gets into encrypting the > password, or you need to provide them on a command as arguments which > again gets into whether the password is in plain text or not. > > On Thu, Jun 13, 2019 at 2:28 PM Shawn Weeks <[email protected]> > wrote: >> >> Got it, I've been trying to read some of this on my phone and missed >> something. Currently it looks like the NiFi Client JerseyNiFiClient.java was >> setup to support token(JWT) based requests but from what I can tell those >> methods are never called anywhere. NiFi Registry Client only implemented the >> implicit security and proxied entity methods. >> >> It looks like I should be able to lookup the auth token and add it to the >> Jersey WebTarget Headers in the two clients so it would be there on every >> request. I'll have to do some testing but that might not require too many >> changes. In theory it could also support username/password auth as well >> doing it the same way. >> >> https://stackoverflow.com/questions/29056051/adding-authorization-header-to-jersey-sse-client-request >> >> Thanks >> Shawn >> >> On 6/13/19, 1:04 PM, "Bryan Bende" <[email protected]> wrote: >> >> 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 >>>>>>> >>>>>>> >>>>>> >>>> >>> >>> >> >> > >
