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" <bbe...@gmail.com> 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 <swe...@weeksconsulting.us> 
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" <bbe...@gmail.com> 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 
<swe...@weeksconsulting.us> 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" <bbe...@gmail.com> 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 
<alopre...@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
    >     >     > alopre...@apache.org
    >     >     > alopresto.apa...@gmail.com
    >     >     > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 
2F7D EF69
    >     >     >
    >     >     > > On Jun 13, 2019, at 10:27 AM, Shawn Weeks 
<swe...@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 
<alopre...@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
    >     >     > >> alopre...@apache.org
    >     >     > >> alopresto.apa...@gmail.com
    >     >     > >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 
2F7D EF69
    >     >     > >>
    >     >     > >>> On Jun 13, 2019, at 10:00 AM, Shawn Weeks 
<swe...@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" <bbe...@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 
<bbe...@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 
<alopre...@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
    >     >     > >>>>> alopre...@apache.org
    >     >     > >>>>> alopresto.apa...@gmail.com
    >     >     > >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E 
F65B 2F7D EF69
    >     >     > >>>>>
    >     >     > >>>>>> On Jun 12, 2019, at 9:39 AM, Shawn Weeks 
<swe...@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
    >     >     > >>>
    >     >     > >>>
    >     >     > >>
    >     >     >
    >     >
    >     >
    >
    >
    

Reply via email to