004-terminology-for-authentication #72
Conversation
Signed-off-by: Tom Bentley <tbentley@redhat.com>
Signed-off-by: Tom Bentley <tbentley@redhat.com>
|
@robobario fixed, if you wanted to take another pass. |
SamBarker
left a comment
SamBarker
left a comment
There was a problem hiding this comment.
LGTM
I think starting with terms is a great place to begin.
| |---------------------|---------------------|--------------------------| | ||
| | Mechanism | Definition | Kafka implementation KIP | | ||
| |---------------------|---------------------|--------------------------| | ||
| | PLAIN | [RFC 4616][RFC4616] | [KIP-43][KIP43] | | ||
| | GSSAPI (Kerberos v5)| [RFC 4752][RFC4752] | [KIP-12][KIP12] | | ||
| | SCRAM | [RFC 5802][RFC5802] | [KIP-84][KIP84] | | ||
| | OAUTHBEARER | [RFC 6750][RFC6750] | [KIP-255][KIP255] | | ||
| |---------------------|---------------------|--------------------------| |
There was a problem hiding this comment.
The github renderer (at least) does not treat the first & last lines as part table
| |---------------------|---------------------|--------------------------| | |
| | Mechanism | Definition | Kafka implementation KIP | | |
| |---------------------|---------------------|--------------------------| | |
| | PLAIN | [RFC 4616][RFC4616] | [KIP-43][KIP43] | | |
| | GSSAPI (Kerberos v5)| [RFC 4752][RFC4752] | [KIP-12][KIP12] | | |
| | SCRAM | [RFC 5802][RFC5802] | [KIP-84][KIP84] | | |
| | OAUTHBEARER | [RFC 6750][RFC6750] | [KIP-255][KIP255] | | |
| |---------------------|---------------------|--------------------------| | |
| | Mechanism | Definition | Kafka implementation KIP | | |
| |---------------------|---------------------|--------------------------| | |
| | PLAIN | [RFC 4616][RFC4616] | [KIP-43][KIP43] | | |
| | GSSAPI (Kerberos v5)| [RFC 4752][RFC4752] | [KIP-12][KIP12] | | |
| | SCRAM | [RFC 5802][RFC5802] | [KIP-84][KIP84] | | |
| | OAUTHBEARER | [RFC 6750][RFC6750] | [KIP-255][KIP255] | |
From the PR review:
|
|
||
| ### Identity preserving | ||
|
|
||
| SASL Passthrough is one way to for a proxy to be **identity preserving**, which means that, for all client identities in the virtual cluster, each of those identities will have the same name as the corresponding client identity in the broker. |
There was a problem hiding this comment.
Is it worth defining what we/Kafka mean by identity?
We can't actually ensure that we offer this definition. In the face of opaque tokens we have no way of knowing what the identity in the proxy is or if is the same as the broker holds. So is there a practical difference between SASL Passthrough and Identity Preserving?
There was a problem hiding this comment.
I dropped "identity preserving" from the doc. I don't think we really use this term in any of the other documents, so there's no benefit from trying to define it.
FTR I guess there are two orthogonal ideas going on. The definition I wrote required the proxy to have inferred some kind of identity (i.e. assumed passthrough inspection). But the wider idea is that when we're passing through the proxy is not substituting any credentials of its own. I.e. there is only one "domain of users".
There was a problem hiding this comment.
I think that's probably an important thought to draw out in the docs, probably not in this proposal
| A **TLS client certificate** is a TLS certificate for the client-side of a TLS Handshake. | ||
| For a given client and server pairing, a proxy might have _two_ of these: the Kafka client's TLS client certificate, and the proxy's own TLS client certificate for its connection to the server. | ||
|
|
||
| ### Client mutual TLS authentication |
There was a problem hiding this comment.
Non blocking. I think Downstream mutual TLS authentication and Upstream mutual authentication are clearer.
Signed-off-by: Tom Bentley <tbentley@redhat.com>
4 participants
It's been suggested to break #71 into separate proposals to simplify review etc. This PR adds a "proposal" which is really just defining some common terminology for the project. Other proposals will refer to this one, so the terms are all defined in one place.