Hi Curtis, There has definitely been some discussion about this and it is picking up recently. I understand the difficulty faced when using NiFi in conjunction with a reverse proxy or external identity provider. I am not saying the current way is perfect, or even the best.
…but…
Always allowing X.509 authentication has been the standard for years (due to
NiFi’s original design requirements), and changing this will have far-reaching
impact on the application. The additional identity providers have been added
piece-meal as requirements arose, and because of the multiple contexts NiFi
supports, there are additional changes required for each — issuing one time
tokens for file downloads, etc.
The code you identified returns a boolean value, but it is not simply reading a
boolean flag from the properties file — it is calculating the presence/absence
of the other (non-credential-based) identity providers:
/**
* Returns true if client certificates are required for REST API. Determined
* if the following conditions are all true:
* <p>
* - login identity provider is not populated
* - Kerberos service support is not enabled
* - openid connect is not enabled
* - knox sso is not enabled
* </p>
*
* @return true if client certificates are required for access to the REST API
*/
public boolean isClientAuthRequiredForRestApi() {
return !isLoginIdentityProviderEnabled() &&
!isKerberosSpnegoSupportEnabled() && !isOidcEnabled() && !isKnoxSsoEnabled();
}
There is active planning for a complete rewrite of the authentication mechanism
ordering, but because this is such a wide-reaching change and will have
substantial impact across the project, I strongly advocate for this to go in a
major release. As the number of users of the project continues to grow, we have
to balance improving the experience in edge scenarios against more common
scenarios. While I don’t mean to negate the times a reverse proxy is required,
it is not present in the majority of deployments, and the current model works
sufficiently in those deployments. We have to keep those deployments in mind as
well while we make these changes.
If you have an immediate need to deploy NiFi behind a reverse proxy and disable
the X.509 requests, my honest suggestion would be to fork the repository and
apply a patch to return false from that method just as you specified.
Unfortunately, that patch alone probably would not be accepted into the
upstream NiFi project at this time. It can certainly be documented as a
requirement for the rearchitected authentication mechanism moving forward.
Thanks for sharing your expectations and needs from the project, and hopefully
we can meet them soon.
Andy LoPresto
[email protected]
[email protected]
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> On Aug 9, 2018, at 11:28 AM, Curtis Ruck <[email protected]> wrote:
>
> FYSA,
>
> This is where X509 is "always-on".
>
> nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-jetty/src/main/java/org/apache/nifi/web/server/JettyServer.java#L781-L785
>
> if (props.isClientAuthRequiredForRestApi()) {
> contextFactory.setNeedClientAuth(true);
> } else {
> contextFactory.setWantClientAuth(true);
> }
>
> I believe in the short term, modifying this section to use nifi.properties to
> allow us to provide a false to wantClientAuth, would address our concerns.
>
> --
> Curtis Ruck
>
>
> On Thu, Aug 9, 2018 at 12:54 PM Curtis Ruck <[email protected]
> <mailto:[email protected]>> wrote:
> To support Shawn's statement even further. If my customer can't get NiFi to
> operate behind our reverse proxy, it won't be in our system. I'm trying to
> find the easiest approach, and NiFi's OIDC should be perfect, if X509 wasn't
> "wanted" up front.
>
> I'd argue that all of the AuthN/AuthZ code should be abstracted out
> significantly more than it currently is, with the ability to completely
> configure it via nifi.properties, and mix-in custom AuthN/AuthZ solutions.
> The ability to manage users/groups in NiFi's UI should be a toggle.
> There should be an easy higher level API to use for group/role provisioning.
> If a new user "bob" open's NiFi and they have a "read-only" role, then they
> shouldn't need to be manually provisioned in NiFi, and we my customer tries
> to minimize the number of unique applications reaching into LDAP. Every
> application that implements LDAP support implements it differently, and they
> don't always scale up appropriately.
>
> For example, i'm trying to get Apereo CAS 5.x working with Apache NiFi. With
> CAS, it can provide SAML 2.0, SAML 1.1, OpenID Connect, or CAS's custom
> protocols, which can support Yubikey, Google Authentication, ADFS, Azure AD,
> etc. Sadly, because of the wantClientAuth(true) I can't use any of it.
>
> I'm even willing to assist in providing some PRs to move NiFi in the right
> direction, I just think we should figure out the higher level
> architecture/design a little better; especially since NiFi's job is to help
> things integrate together, it's not being a good team player.
>
> As much as I hate to say it, if NiFi was a proper Java EE project, I could
> just use a war overlay to modify the AuthN/AuthZ to success; even if it was
> just a self-executing .war.
>
> --
> Curtis Ruck
>
>
> On Thu, Aug 9, 2018 at 12:14 PM Shawn Weeks <[email protected]
> <mailto:[email protected]>> wrote:
> I'll clarify my statement a little as well with a workflow.
>
> You open the NiFi UI Link
> Chrome sees NiFi Asking for SSL and Prompts You for Cert
> Then you get Prompts for Username and Password because of GSSAPI even though
> your not on that REALM.
> Then you get directed to the Identify Management Reverse Proxy URL for Knox
> SSO
> Then you get prompted for your Certificate which you should select.
> Then you might get prompted for Kerberos Again which you cancel
> Finally your in NiFi.
>
> Painful doesn't even begin to describe it lol.
>
>
> Thanks
> Shawn
> From: Kevin Doran <[email protected] <mailto:[email protected]>>
> Sent: Thursday, August 9, 2018 11:07:28 AM
> To: [email protected] <mailto:[email protected]>
> Subject: Re: Re:
>
> Explaining to your end users that you should skip the first Certificate
> Prompt but accept the second but only when you haven't logged in the current
> session is really painful
>
> Wow, that sounds terrible. Confusing, accident prone, and frustrating to
> correct mistakes (at least in my experience, forcing a browser to forget
> client certificate preferences is difficult).
>
> Thanks for sharing those details about your deployment scenario. This can
> definitely be improved and I have some ideas for how to do it. I've cloned
> the issue to NiFi to make sure we are tracking it for both projects [1][2]
>
> [1] https://issues.apache.org/jira/browse/NIFIREG-189
> <https://issues.apache.org/jira/browse/NIFIREG-189>
> [2] https://issues.apache.org/jira/browse/NIFI-5504
> <https://issues.apache.org/jira/browse/NIFI-5504>
>
> On Thu, Aug 9, 2018 at 11:54 AM, Shawn Weeks <[email protected]
> <mailto:[email protected]>> wrote:
> The project I'm on is running into this issue as well and it gets
> particularly painful when all of your server's are signed by the same root ca
> that signs your smart card logins and your using something like KnoxSSO.
> Explaining to your end users that you should skip the first Certificate
> Prompt but accept the second but only when you haven't logged in the current
> session is really painful and shows major shortcoming between the back end
> authentication between servers and front end ui authentication.
>
> We can't even considering putting it behind our identify reverse proxies
> because we can't turn off two way ssl.
>
> Thanks
> Shawnk
> From: Kevin Doran <[email protected] <mailto:[email protected]>>
> Sent: Thursday, August 9, 2018 10:47:56 AM
> To: [email protected] <mailto:[email protected]>
> Subject: Re:
>
> sorry forgot the link. here it is:
>
> [1] https://issues.apache.org/jira/projects/NIFIREG/issues/NIFIREG-189
> <https://issues.apache.org/jira/projects/NIFIREG/issues/NIFIREG-189>
>
> On Thu, Aug 9, 2018 at 11:47 AM, Kevin Doran <[email protected]
> <mailto:[email protected]>> wrote:
> Hi Curtis,
>
> This has come up a few times. Unfortunately I don’t think there is currently
> an easy way to disable X509-based identity extraction in NiFi today. There is
> an open JIRA for the same issue in NiFi Registry [1]. NiFi Registry follows
> the same AuthN/AuthZ design (and a fair amount of code) as NiFi, so this
> ticket should apply to NiFi as well.
>
> Perhaps you could share more about your needs and use case on that ticket so
> that when it gets implemented we could take that scenario with reverse
> proxies and OIDC into account?
>
> Thanks,
> Kevin
>
> On Mon, Aug 6, 2018 at 10:23 AM, Curtis Ruck <[email protected]
> <mailto:[email protected]>> wrote:
> I'm trying to setup OIDC authentication, but with Nifi service existing
> behind a reverse proxy, and for our other apps we use SSL Client
> Authentication between reverse proxy and application, Nifi is picking up the
> Reverse Proxy's SSL Certificate and falling into X509 Authentication instead
> of OIDC. Any idea how I can disable X509 authentication in Nifi?
>
> Connecting directly to nifi, it triggers the proper OIDC redirects.
>
> --
> Curtis Ruck
>
>
>
signature.asc
Description: Message signed with OpenPGP using GPGMail
