nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Bende <bbe...@gmail.com>
Subject Re: NiFi Toolkit CLI Token Creation
Date Thu, 13 Jun 2019 17:30:36 GMT
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 <alopresto@apache.org> 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
> alopresto@apache.org
> alopresto.apache@gmail.com
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> > On Jun 13, 2019, at 10:27 AM, Shawn Weeks <sweeks@weeksconsulting.us> 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 <alopresto@apache.org> 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
> >> alopresto@apache.org
> >> alopresto.apache@gmail.com
> >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >>
> >>> On Jun 13, 2019, at 10:00 AM, Shawn Weeks <sweeks@weeksconsulting.us>
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" <bbende@gmail.com> 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 <bbende@gmail.com>
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 <alopresto@apache.org>
> >>>> 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
> >>>>> alopresto@apache.org
> >>>>> alopresto.apache@gmail.com
> >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >>>>>
> >>>>>> On Jun 12, 2019, at 9:39 AM, Shawn Weeks <sweeks@weeksconsulting.us>
> >>>>> 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
> >>>
> >>>
> >>
>

Mime
View raw message