Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
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 and RFC-8187 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 <Алйс><Боб>:
X-ProxiedEntitesChain: encoded; value*=utf-8''%3C%D0%90%D0%BB%D0%B9%D1%81%3E%3C%D0%91%D0%BE%D0%B1%3E
Alternatively, we could disregard RFCs 2231 and 8187, and use our own encoding scheme such as base64:
X-ProxiedEntitiesChain: base64; value=PNCQ0LvQudGBPjzQkdC+0LE+
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.
Attachments
Issue Links
- is related to
-
-
- Resolved
-
- links to
