[
https://issues.apache.org/jira/browse/NIFI-7310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17379588#comment-17379588
]
Sean Xu commented on NIFI-7310:
-------------------------------
any eta for this issue to be fixed. It is a blocker for us to deploy nifi flow
into production as Authorization header display access token.
> Improve experience configuring Authorization header for HTTP processors
> -----------------------------------------------------------------------
>
> Key: NIFI-7310
> URL: https://issues.apache.org/jira/browse/NIFI-7310
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
> Affects Versions: 1.11.4
> Reporter: Andy LoPresto
> Priority: Major
> Labels: authorization, header, http, parameter, security
>
> 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.
> {quote}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.
> {quote}
> [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]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
