I'm not sure I totally follow... is there a reason that the token
methods in NiFIClient can't be used?
I would expect that it is the CLI's decision whether to call
getXYZForProxiedEntities or getXYZForToken.
The client factories in CLI currently wrap the client and force the
use of proxied
Turns out there isn't going to be an easy way like I thought. Looking at
everything it seems to me that you can generalize all the different jersey
clients as with headers or without headers. Currently they all support this as
a way to implement proxies that the Client Factory wraps things at
Got it, for now I'm just going to work on implementing a Kerberos solution that
either allows you to configure a keytab and principal or pulls from the current
subject if your already logged in.
I created NIFI-6378 and NIFIREG-281. Can one of you assign the registry one to
me as I'm not a
It would be a little bit weird because you'd still need the client
cert for the initial request to get the JWT, so then in that case why
not just keep using the client cert.
Registry does things a little bit different than NiFi and has a few
variations of the token end-point:
/access/token/login
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
alopre...@apache.org
alopresto.apa...@gmail.com
PGP Fingerprint: 70EC B3E5 98A6
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.
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.
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
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
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
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
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 wrote:
>
> I see a couple choices here:
>
> 1. Use the CA to generate and sign a new certificate for
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
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
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 wrote:
> Right now the idea is that
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
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
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
18 matches
Mail list logo
