[
https://issues.apache.org/jira/browse/NIFI-7744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233664#comment-17233664
]
ASF subversion and git services commented on NIFI-7744:
-------------------------------------------------------
Commit a0328ff8d1d00e7a540676530278839905168ab7 in nifi's branch
refs/heads/main from Kevin Doran
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=a0328ff ]
NIFI-7744 Add Support for Unicode in X-ProxiedEntitiesChain (#4664)
- Adds detection and encoding of non-ascii characters to creation of chain
- Adds unit tests that use proxied entities with Unicode
> 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
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> 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 RFC-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)
