[NIFI-7310] Improve experience configuring Authorization header for HTTP processors

• Type: Improvement
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.11.4
• Fix Version/s: 1.17.0
• Component/s: Extensions
• Labels: authorization header http parameter security
• Assignee: David Handermann
• Reporter: Andy LoPresto
• Created: 01/Apr/20 19:54
• Updated: 01/Jun/22 18:10
• Resolved: 01/Jun/22 18:10

Description

As discussed in the Apache NiFi slack room (see transcript below), the InvokeHTTP processor (among others) often requires an Authorization HTTP header [1] to successfully make a request to an external service. This header includes an authorization type (e.g. Basic, Bearer, Digest, Negotiate, OAuth, etc.) [2] and the credentials (e.g. the plaintext or Base64-encoded username & password, a JWT token, etc.) [3].

While the JWT value (for example) can be supplied with a parameter, the limitations on sensitive parameters make this process more difficult – non-sensitive parameters are stored in plaintext and synced with flow versioning to an unsecured persistence layer, while sensitive parameters are prohibited from any modification in property descriptor fields (i.e. one cannot prepend "Bearer: #{jwtSensitiveParam}" as one could with "Other-prefix: #{nonSensitiveParam}").

One option is to make the Authorization header a permanent, non-required property descriptor in the component rather than being added only via a dynamic property. The value (credentials) could be a sensitive parameter and the type could be determined dynamically by evaluating the value, or a sibling property of Authorization Type could be selected from a drop-down of AllowableType entries to improve user experience and validation.

Martin Ebert 12:34
I have a problem. I can synchronize the registry nicely automated with Github. So far so good. But now I need certain keys e.g. Bearer Token. I store them in the parameter Context. To use them in Invoke HTTP I must not declare the token as a sensitive value. But now I have a problem: The token is also displayed in Github. No-Go. How can I fix this?
12:35
I assumed that the values from the Context parameter are not synchronized with Github at all.

Bryan Bende Today at 12:36
why would it not be stored as a sensitive parameter?

Andy LoPresto 15 minutes ago
Because to craft the fully-formed header you need to prepend it with `Bearer: `.

Andy LoPresto 15 minutes ago
This is a unique edge case.

Andy LoPresto 14 minutes ago
It might make sense to add a static "Authorization" header property descriptor to this component because it's often required.

Pierre Villard:nifi: 14 minutes ago
this can be part of the parameter value, no?

Andy LoPresto 14 minutes ago
And a separate PD which determines the kind of token (JWT, cookie, etc.).

Bryan Bende 14 minutes ago
so the issue is its being used in a dynamic prop on InvokeHttp and those are not sensitive props?

Andy LoPresto 14 minutes ago
Yes, Pierre, it can be. Just makes it harder to generate dynamically and populate it.

Pierre Villard:nifi: 14 minutes ago
I see

Andy LoPresto 14 minutes ago
Bryan, it's that we restrict sensitive parameters and prohibit them from concatenation.

Andy LoPresto 13 minutes ago
You can do Bearer: #{nonSensitiveParameter} just fine.

Andy LoPresto 13 minutes ago
You can't do Bearer: #{sensitiveParameter}.

Bryan Bende 13 minutes ago
i see, well +1 to the new properties you suggested

Andy LoPresto 12 minutes ago
I'll create a ticket.

Andy LoPresto 11 minutes ago
It could use more thought so I won't prescribe that's the only way to move forward, but just to improve this experience in general.

Andy LoPresto 11 minutes ago
For today, Pierre's suggestion is probably the easiest to implement.

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization
[2] https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml
[3] https://tools.ietf.org/html/rfc4559#page-2

Issue Links

• is fixed by: NIFI-9961 Update InvokeHTTP to Support Sensitive Dynamic Properties