[
https://issues.apache.org/jira/browse/NIFIREG-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16575047#comment-16575047
]
Shawn Weeks commented on NIFIREG-189:
-------------------------------------
This is an absolute must for NiFi as well. This prevents implementation of a
number of Identity Management Solutions as they will always present an x509
certificate if requested.
> Improved Identity Provider Configurability
> ------------------------------------------
>
> Key: NIFIREG-189
> URL: https://issues.apache.org/jira/browse/NIFIREG-189
> Project: NiFi Registry
> Issue Type: Improvement
> Reporter: Kevin Doran
> Assignee: Kevin Doran
> Priority: Minor
>
> Currently, in NiFi Registry (and NiFi), 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 X509IdentityFilter 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 or browser (for example, in corporate
> environments), or who simply accidentally select 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)
