[
https://issues.apache.org/jira/browse/NIFI-5504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16575071#comment-16575071
]
Kevin Doran commented on NIFI-5504:
-----------------------------------
Related mailing list thread:
https://lists.apache.org/thread.html/4d8b1ebd4320ad615a5f81a7c5ad3bd881e184dd0c502d57e2ab0558@%3Cusers.nifi.apache.org%3E
> 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 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).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
