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 have such a
>> feature in Kafka. At the moment,
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
> invoked for new SASL (and apparen
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 op
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 Authorize
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 authentic
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
wrote:
> Hi
