nifi-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curtis Ruck <curtis.r...@gmail.com>
Subject Re: Re:
Date Thu, 09 Aug 2018 16:54:13 GMT
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 <sweeks@weeksconsulting.us>
wrote:

> I'll clarify my statement a little as well with a workflow.
>
>
>
>    1. You open the NiFi UI Link
>    2. Chrome sees NiFi Asking for SSL and Prompts You for Cert
>    3. Then you get Prompts for Username and Password because of GSSAPI
>    even though your not on that REALM.
>    4. Then you get directed to the Identify Management Reverse Proxy URL
>    for Knox SSO
>    5. Then you get prompted for your Certificate which you should select.
>    6. Then you might get prompted for Kerberos Again which you cancel
>    7. Finally your in NiFi.
>
>
> Painful doesn't even begin to describe it lol.
>
>
> Thanks
>
> Shawn
> ------------------------------
> *From:* Kevin Doran <kdoran@apache.org>
> *Sent:* Thursday, August 9, 2018 11:07:28 AM
> *To:* users@nifi.apache.org
> *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
> [2] https://issues.apache.org/jira/browse/NIFI-5504
>
> On Thu, Aug 9, 2018 at 11:54 AM, Shawn Weeks <sweeks@weeksconsulting.us>
> 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 <kdoran@apache.org>
> *Sent:* Thursday, August 9, 2018 10:47:56 AM
> *To:* users@nifi.apache.org
> *Subject:* Re:
>
> sorry forgot the link. here it is:
>
> [1] https://issues.apache.org/jira/projects/NIFIREG/issues/NIFIREG-189
>
> On Thu, Aug 9, 2018 at 11:47 AM, Kevin Doran <kdoran@apache.org> 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 <curtis.ruck@gmail.com>
> 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
>
>
>
>
>

Mime
View raw message