[jira] [Commented] (NIFIREG-74) Change the REST API login endpoint to use HTTP Basic Auth

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/NIFIREG-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16299077#comment-16299077 ] 

ASF GitHub Bot commented on NIFIREG-74:
---------------------------------------

GitHub user kevdoran opened a pull request:

    https://github.com/apache/nifi-registry/pull/63

    NIFIREG-74 Change login to use HTTP Basic Auth

    Changes the REST API /access/token/login endpoint to use HTTP Basic Auth for reading username and password.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/kevdoran/nifi-registry NIFIREG-74

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/nifi-registry/pull/63.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #63
    
----
commit 5ea5f70427d256a4e571cc3e3ec4904472f57ec5
Author: Kevin Doran <kd...@...>
Date:   2017-12-20T20:20:18Z

    NIFIREG-74 Change login to use HTTP Basic Auth
    
    Changes the REST API /access/token/login endpoint to use HTTP Basic
    Auth for reading username and password.

----


> 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)