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
