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 18:28:27 GMT
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 <curtis.ruck@gmail.com> 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 <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