On Tue, Oct 30, 2018 at 7:02 AM Ivan Kelly <iv...@apache.org> wrote:
> Looks like a great scheme, but I'd like some more concrete details
> about how you see this interacting with Pulsar.
>
Replies inline and then I'll add to the wiki as well.
>
> A couple of questions:
>
> How will the token be passed in HTTP? As a header?
>
Yes, the client will pass the token in a header, such as `X-Pulsar-Auth` or
`Authorization`. Still to be determined the header name.
> What does the concrete payload look like?
>
The token will look like :
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJKb2UifQ.ipevRNuRP6HflG8cFKnmUPtypruRC4fb1DWtoLL62SY
This string is composed of 3 parts, separated by '.' and each separately
encoded in Base64 (url compatible).
The 3 parts are:
* Header
* Payload
* Signature
Header and payload are actually JSON string. Examples:
Decoded Header: {"alg":"RS256"}
Decoded Payload: {"sub":"my-test-subject"}
> How is the server configured to accept this? Is there a public/private
>
There are 2 options:
1. Use a single "secret key" for generating and validating tokens
2. Use public/private keys:
* Private key is used to generate tokens
* Public key is used to validate tokens.
Pulsar broker would only need to have the public key in this case
> key? Where should the private key be stored? Is it PSK?
>
I would leave that outside the scope of this plugin. The private key is
only needed by
the system admin to generate new tokens (perhaps through some automated
service, which again
is not in the scope of this proposal).
bin/pulsar tokens create-secret-key
Will write the new generated key on stdout. User can store the key where
deemed appropriate.
When creating a new token, there are several ways to pass the secret key to
the tool. eg:
1. Read from a file: `bin/pulsar tokens create -f /path/to/secret.key
--subject my-subject`
2. Read from stdin: `bin/pulsar tokens create-secret-key --stdin --subject
my-subject`
3. Read from env: `export SECRET_KEY=$(read my key)`; bin/pulsar tokens
create-secret-key --stdin --subject my-subject`
> How do we block compromised tokens?
>
I think the easiest approach is to keep 1 principal per each token. With
this, to block a compromised token, we
would just have to remove ACLs given to the principal associated with the
token.
Downside of this approach is that if that principal was granted permissions
on multiple namespaces/topics, we'd have
to remove from each of them.
The other approach, which we should consider in future, is to add support
of a revocation list.
The implementation would be essentially a hash-set with notifications to
all brokers. Each broker will be notified when a
new principal is revoked and will force disconnection of any connected
producer/consumer using that token.
--
Matteo Merli
<mme...@apache.org>
