You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "Andy LoPresto (Jira)" <ji...@apache.org> on 2020/04/01 19:57:00 UTC
[jira] [Updated] (NIFI-7310) Improve experience configuring
Authorization header for HTTP processors
[ https://issues.apache.org/jira/browse/NIFI-7310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andy LoPresto updated NIFI-7310:
--------------------------------
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 <pre>"Bearer: #{jwtSensitiveParam}"</pre> as one could with <pre>"Other-prefix: #{nonSensitiveParam}"</pre>).
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
was:
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
> 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 <pre>"Bearer: #{jwtSensitiveParam}"</pre> as one could with <pre>"Other-prefix: #{nonSensitiveParam}"</pre>).
> 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)