[
https://issues.apache.org/jira/browse/NIFI-7744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Doran updated NIFI-7744:
------------------------------
Description:
NiFi and NiFi Registry both support the concept of an authorized proxy making a
web request on behalf of another authenticated user.
This is implemented as follows:
* The proxy authenticates using two-way TLS (metal auth) with a client
certificate. The DN of the client certificate is authenticated as a user,
whereas the actual end user performing the action is passed in the
X-ProxiedEntitiesChain custom header in the form <userId1><userId2><userId3>...
* The client certificate DN must be authorized (by the access policy provider)
to act as a trusted poxy
* The proxied identity must be authorized to perform the desired action
There is a shortcoming with this approach, which is that user identities can
use a larger character set (Unicode / UTF-8) than HTTP Headers (US ASCII).
This ticket proposes adding a backward-compatible extension to the
X-ProxiedEntitiesChain header value syntax such that languages and character
sets other than US-ASCII can be encoded into the value.
The exact encoding mechanism is secondary to the goal of this ticket. However,
there are two relevant draft Internet Standards that are worth considering:
[RFC-2231|https://tools.ietf.org/html/rfc2231] and
[RFC-8187|https://tools.ietf.org/html/rfc8187] which is a more prescriptive
simplification of RFC-2231.
Following the method outlined in RFX-8187, the new header syntax would look
something like this, in which utf-8 characters outside the ascii attire-char
set are octet encoded and then percent encoded:
Given the raw entity chain string of <Алйс><Боб>:
{noformat}
X-ProxiedEntitesChain: encoded;
value*=utf-8''%3C%D0%90%D0%BB%D0%B9%D1%81%3E%3C%D0%91%D0%BE%D0%B1%3E{noformat}
Alternatively, we could disregard RFCs 2231 and 8187, and use our own encoding
scheme such as base64:
{noformat}
X-ProxiedEntitiesChain: base64; value=PNCQ0LvQudGBPjzQkdC+0LE+{noformat}
In either case, the raw header value would first be read and parsed (matched
against a magic string or regex) to see if it is an encoded value or legacy,
raw ascii value. If encoded, nifi and nifi registry would first decode the
value before proceeding with the normal logic. If not encoded, the behavior
would be unchanged from how it currently works, and the raw string would be
interpreted as a proxied entity chain.
was:
NiFi and NiFi Registry both support the concept of an authorized proxy making a
web request on behalf of another authenticated user.
This is implemented as follows:
* The proxy authenticates using two-way TLS (metal auth) with a client
certificate. The DN of the client certificate is authenticated as a user,
whereas the actual end user performing the action is passed in the
X-ProxiedEntitiesChain custom header in the form <userId1><userId2><userId3>...
* The client certificate DN must be authorized (by the access policy provider)
to act as a trusted poxy
* The proxied identity must be authorized to perform the desired action
There is a shortcoming with this approach, which is that user identities can
use a larger character set (Unicode / UTF-8) than HTTP Headers (US ASCII).
This ticket proposes adding a backward-compatible extension to the
X-ProxiedEntitiesChain header value syntax such that languages and character
sets other than US-ASCII can be encoded into the value.
The exact encoding mechanism is secondary to the goal of this ticket. However,
there are two relevant draft Internet Standards that are worth considering:
[RFC-2231|https://tools.ietf.org/html/rfc2231] and
[RFC-8187|https://tools.ietf.org/html/rfc8187] which is a more prescriptive
simplification of RFC-2231.
Following the method outlined in RFX-8187, the new header syntax would look
something like this, in which utf-8 characters outside the ascii attire-char
set are octet encoded and then percent encoded:
Given the raw entity chain string of <Алйс><Боб>:
{noformat}
X-ProxiedEntitesChain: encoded;
value*=utf-8''%3C%D0%90%D0%BB%D0%B9%D1%81%3E%3C%D0%91%D0%BE%D0%B1%3E{noformat}
Alternatively, we could disregard RFCs 2231 and 8187, and use our own encoding
scheme such as base64:
{noformat}
X-ProxiedEntitiesChain: base64; value=PNCQ0LvQudGBPjzQkdC+0LE+{noformat}
In either case, the header value would first be decoded and matched against a
magic string or regex to see if it is an encoded value or legacy, raw ascii
value. If encoded, nifi and nifi registry would first decode the value before
proceeding with the normal logic. If not encoded, the behavior would be
unchanged from how it currently works, and the raw string would be interpreted
as a proxied entity chain.
> Add support for character sets other than US-ASCII in X-ProxiedEntitiesChain
> Header
> -----------------------------------------------------------------------------------
>
> Key: NIFI-7744
> URL: https://issues.apache.org/jira/browse/NIFI-7744
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
> Reporter: Kevin Doran
> Assignee: Kevin Doran
> Priority: Major
>
> NiFi and NiFi Registry both support the concept of an authorized proxy making
> a web request on behalf of another authenticated user.
> This is implemented as follows:
> * The proxy authenticates using two-way TLS (metal auth) with a client
> certificate. The DN of the client certificate is authenticated as a user,
> whereas the actual end user performing the action is passed in the
> X-ProxiedEntitiesChain custom header in the form
> <userId1><userId2><userId3>...
> * The client certificate DN must be authorized (by the access policy
> provider) to act as a trusted poxy
> * The proxied identity must be authorized to perform the desired action
> There is a shortcoming with this approach, which is that user identities can
> use a larger character set (Unicode / UTF-8) than HTTP Headers (US ASCII).
> This ticket proposes adding a backward-compatible extension to the
> X-ProxiedEntitiesChain header value syntax such that languages and character
> sets other than US-ASCII can be encoded into the value.
> The exact encoding mechanism is secondary to the goal of this ticket.
> However, there are two relevant draft Internet Standards that are worth
> considering: [RFC-2231|https://tools.ietf.org/html/rfc2231] and
> [RFC-8187|https://tools.ietf.org/html/rfc8187] which is a more prescriptive
> simplification of RFC-2231.
> Following the method outlined in RFX-8187, the new header syntax would look
> something like this, in which utf-8 characters outside the ascii attire-char
> set are octet encoded and then percent encoded:
> Given the raw entity chain string of <Алйс><Боб>:
> {noformat}
> X-ProxiedEntitesChain: encoded;
> value*=utf-8''%3C%D0%90%D0%BB%D0%B9%D1%81%3E%3C%D0%91%D0%BE%D0%B1%3E{noformat}
> Alternatively, we could disregard RFCs 2231 and 8187, and use our own
> encoding scheme such as base64:
> {noformat}
> X-ProxiedEntitiesChain: base64; value=PNCQ0LvQudGBPjzQkdC+0LE+{noformat}
>
> In either case, the raw header value would first be read and parsed (matched
> against a magic string or regex) to see if it is an encoded value or legacy,
> raw ascii value. If encoded, nifi and nifi registry would first decode the
> value before proceeding with the normal logic. If not encoded, the behavior
> would be unchanged from how it currently works, and the raw string would be
> interpreted as a proxied entity chain.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
