Kevin Doran created NIFIREG-74:
----------------------------------
Summary: Change the REST API login endpoint to use HTTP Basic Auth
Key: NIFIREG-74
URL: https://issues.apache.org/jira/browse/NIFIREG-74
Project: NiFi Registry
Issue Type: Improvement
Reporter: Kevin Doran
Assignee: Kevin Doran
Fix For: 0.0.1
Currently, the REST API endpoint for logging in using a username & password
(with a configured identity provider) is a POST that accepts Content-Type
application/x-www-form-urlencoded, with form parameters in the body.
Specifically, requests should be formed as:
{noformat}
POST /nifi-registry-api/access/token/login HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 32
username=nobel&password=password
{noformat}
However, the Jersey resource we are using for the REST API in the server will
also respond to username and password passed in URL parameters, eg:
{noformat}
POST /nifi-registry-api/access/token/login?username=nobel&password=password
HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 0
{noformat}
This is incorrect, but it will work (actually, the current implementation of
the javascript client is logging in this way). As there does not appear to be
an easy way to prevent the server from mapping url parameters to form
parameters, a client could mistakenly send url parameters to the server and get
a token back. The issue is that the URL is not generally considered a protected
element of the request, even when using a secure connection, so libraries might
log the full URL with parameters, thus leaking client credentials. For example:
{noformat}
DEBUG o.s.security.web.FilterChainProxy
/access/token/login?username=nobel&password=password has an empty filter list
WARN o.glassfish.jersey.servlet.WebComponent A servlet request to the URI
https://localhost:8443/nifi-registry-api/access/token/login?username=nobel&password=password
contains form parameters in the request body but the request body has been
consumed by the servlet or a servlet filter accessing the request parameters.
Only resource methods using @FormParam will work as expected. Resource methods
consuming the request body by other means will not work as expected.
{noformat}
After looking into options, the best approach for now seems to be to migrate
the login endpoint and the JS client to use HTTP Basic Auth instead of form
encoded parameters. This will prevent a client from inadvertently sending form
params in the URL to the server in the HTTP POST.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
