[
https://issues.apache.org/jira/browse/NIFI-5504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto reassigned NIFI-5504:
-----------------------------------
Assignee: Andy LoPresto
> 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
> Assignee: Andy LoPresto
> Priority: Minor
>
> 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)
