[
https://issues.apache.org/jira/browse/NIFI-5504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-5504:
--------------------------------
Description:
Currently, in NiFi (and NiFi Registry), the client/user identity for any
request to the REST API comes from a Spring Security filter chain during
request processing that handles authentication and sets the current user for
the request context.
The X509 identity extraction is always first in the chain, meaning that if a
client certificate is present in the TLS handshake (even if not required), it
will be used as the client identity. This can be problematic when multiple
forms of authentication are desired (eg, certificate based for servers,
username/password for end users)
This presents challenges for users that cannot easily change client
certificates managed by their host OS, browser, proxy, or third-party
authentication tool. Or when an end user simply accidentally selects a client
certificate when prompted.
Today, if you want to force username/password login, you have to ensure that
the client/browser does not pass certificate or SPNEGO credentials so that you
fall through to the login screen. It would make for easier deployments for
administrators if they could configure the order of looking for credentials
(for example, use a JWT if present, and if not present use a certificate
identity if present).
was:
Currently, in NiFi (and NiFi Registry), the client/user identity for any
request to the REST API comes from a Spring Security filter chain during
request processing that handles authentication and sets the current user for
the request context.
The X509 identity extraction is always first in the chain, meaning that if a
client certificate is present in the TLS handshake (even if not required), it
will be used as the client identity. This can be problematic when multiple
forms of authentication can desired (eg, certificate based for servers,
username/password for end users)
This presents challenges for users that cannot easily change client
certificates managed by their host OS, browser, proxy, or third-party
authentication tool. Or when an end user simply accidentally selects a client
certificate when prompted.
Today, if you want to force username/password login, you have to ensure that
the client/browser does not pass certificate or SNEGO credentials so that you
fall through to the login screen. It would make for easier deployments for
administrators if they could configure the order of looking for credentials
(for example, use a JWT if present, and if not present use a certificate
identity if present).
> Improved Login Identity Provider Configurability
> ------------------------------------------------
>
> Key: NIFI-5504
> URL: https://issues.apache.org/jira/browse/NIFI-5504
> Project: Apache NiFi
> Issue Type: New Feature
> Components: Security
> Affects Versions: 1.5.0, 1.6.0, 1.7.0, 1.7.1
> Reporter: Kevin Doran
> Priority: Major
>
> Currently, in NiFi (and NiFi Registry), the client/user identity for any
> request to the REST API comes from a Spring Security filter chain during
> request processing that handles authentication and sets the current user for
> the request context.
> The X509 identity extraction is always first in the chain, meaning that if a
> client certificate is present in the TLS handshake (even if not required), it
> will be used as the client identity. This can be problematic when multiple
> forms of authentication are desired (eg, certificate based for servers,
> username/password for end users)
> This presents challenges for users that cannot easily change client
> certificates managed by their host OS, browser, proxy, or third-party
> authentication tool. Or when an end user simply accidentally selects a client
> certificate when prompted.
> Today, if you want to force username/password login, you have to ensure that
> the client/browser does not pass certificate or SPNEGO credentials so that
> you fall through to the login screen. It would make for easier deployments
> for administrators if they could configure the order of looking for
> credentials (for example, use a JWT if present, and if not present use a
> certificate identity if present).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
