Indeed
On Mon, Sep 5, 2016 at 5:43 PM, Ismael Juma wrote:
> On Mon, Sep 5, 2016 at 3:48 PM, Mickael Maison
> wrote:
>
>> Yes in our case, I can see how we would add the functionality, but I
>> was wondering if people might be interested to directly
On Mon, Sep 5, 2016 at 3:48 PM, Mickael Maison
wrote:
> Yes in our case, I can see how we would add the functionality, but I
> was wondering if people might be interested to directly have such a
> feature in Kafka. At the moment, the authorization logic is only
>
Hi Rajini,
Yes in our case, I can see how we would add the functionality, but I
was wondering if people might be interested to directly have such a
feature in Kafka. At the moment, the authorization logic is only
invoked for new SASL (and apparently Kerberos) connections. I feel
like having the
Hi Rajini,
It's a good question and it depends on a number of details. For example,
for short-lived certificates with long-lived connections, it would seem
that one would have to duplicate some logic performed by the TLS stack on
the Authorizer, which is not ideal. For the case where the
Mickael,
I imagine it is fairly easy in MessageHub to deal with expired SASL/PLAIN
credentials since checks can be added to the interceptor in the broker.
Ismael,
Is it really feasible in general to deal with expired credentials in
Authorizers? It sort of expects tight coupling between
Hi Mickael,
The Kerberos ticket refresh mechanism is there for new connections, not
existing connections. Currently, the suggested approach is to rely on the
authorizer to deal with expired credentials. Would this work for you?
Ismael
On Mon, Sep 5, 2016 at 11:13 AM, Mickael Maison
Hi,
While Kerberos has a mechanism to refresh its tickets, SASL PLAIN has
no such feature. This means if a client is connected, as far as I can
tell, we have currently no way of disconnecting him, revoking his
credentials won't help.
I think it would be useful to have a way to force clients to