[
https://issues.apache.org/jira/browse/KAFKA-1683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14184682#comment-14184682
]
Arvind Mani commented on KAFKA-1683:
------------------------------------
Hi [~joestein],
Regarding revocation - are you talking about revoking access of individual
client (kafka consumer, client, or mirror maker), revoking server (kafka
broker) identity, or revoking the issuer of client/server identities (KDC or
CA).
Revoking client access is not hard provided ACL list maintained by authz is
fresh and ACLs are checked per request. If we revoke server identity, then
considering the circumstances this calls for taking the compromised server
offline and pointing clients at another server.
Revocation of issuer is tricky and the implementation may be dependent on
authentication mechanism (e.g., PKI vs kerberos).
Broadly there are several options:
1) Periodically disconnect forcing re-authentication
2) Periodically check revocation - e.g., OCSP for certs but note that this is
typically done just at time of full TLS handshake.
3) Renegotiation within existing session - this is tricky to implement
correctly. TLS supports renegotiation but is often subject to bugs.
In addition there will be changes to configuration on client and server - e.g.,
new trust store or KDC.
If you are talking about dealing with issuer revocation then it might be worth
opening a separate tickets for PKI and for Kerberos.
- Arvind
> Implement a "session" concept in the socket server
> --------------------------------------------------
>
> Key: KAFKA-1683
> URL: https://issues.apache.org/jira/browse/KAFKA-1683
> Project: Kafka
> Issue Type: Sub-task
> Components: security
> Affects Versions: 0.9.0
> Reporter: Jay Kreps
> Assignee: Gwen Shapira
> Attachments: KAFKA-1683.patch, KAFKA-1683.patch
>
>
> To implement authentication we need a way to keep track of some things
> between requests. The initial use for this would be remembering the
> authenticated user/principle info, but likely more uses would come up (for
> example we will also need to remember whether and which encryption or
> integrity measures are in place on the socket so we can wrap and unwrap
> writes and reads).
> I was thinking we could just add a Session object that might have a user
> field. The session object would need to get added to RequestChannel.Request
> so it is passed down to the API layer with each request.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
