Authentication/Authorization requirements

[carlesarnal]

We need to define some defaults/minimal requirements for the authentication/authorization feature. This includes, but is not limited to:

• Define the tech stack (e.g. Keycloak vs generic OIDC).
• Roles, and which roles are allowed to perform what actions.
• How the operator will be affected (new environment variables).

You can see some details of the PoC here.

cc: @jsenko, @EricWittmann

[antonmry]

IMHO one important requirement is the type of Authorization. APIcurio has compatibility with the Confluent API which it's great, because it's used for several frameworks (Spark Structured Streaming, Kafka Connect, etc). This API supports two different types of Auth: Basic and SAML. If one of those types of authorization isn't supported, the usage of the compatible API is restricted to unauthorizated access or authorization based in a proxy layer which it isn't ideal.

Also, from the same perspective, being able to use users provisioned in Kafka in the registry (Kafka as source of truth) would be very interesting for event streaming architectures, so we don't have to manage independlty both users.

Finally, in the authorization level, for CDC use cases we should have the option to use users which are allowed to evolve some schemas but not to do other operations.

[forsberg]

I think it makes sense to support authentication where the username comes in via a header, i.e. trust a proxy to do the authentication. This will cover numerous special use cases such as CI/CD access to the registry.

Agree that being able to authenticate using the same authentication that a client use to talk to Kafka would be useful. In my use cases this includes either SCRAM-SHA-256 or Client certificates.

Another idea that popped up in my head would be to support authentication by use of Kubernetes Service Account Tokens. That's basically a JWT token signed by a CA. This would be useful for applications running in Kubernetes, as they can very easily be configured with a service account, and will then automatically have access to a Service Account Token inside the pod.

[EricWittmann]

Thank you for the feedback. I'll add some additional basics we've started thinking about (for authorization specifically).

1. Role based authorization : define a set of roles that users can have which then control what the user can specifically do (permissions). For example (not final):

• registry-user : grants read-only access to the registry
• registry-admin : grants full read and write access to everything in the registry, including all artifacts (regardless of who created them) and all global settings (e.g. Global Rules)
• registry-manager : grants the ability to create/manage artifacts - but only those artifacts the user has been granted access to (in whatever way we decide that will work). Cannot change global settings.

2. Per-Artifact authorization : we need to define the behavior around managing artifacts. Naively users should only be able to manage the artifacts they created. However, some ability to share management of an artifact by multiple users is necessary. I think the "Artifact Groupings" feature eventually impacts this. But either way, do we need "user groups" so we can grant management access to multiple users easily?

[akoserwal]

Do we keep the default auth mechanism using keycloak? and allow keycloak as a broker. Where we configure any app or service we want to integrate with the service registry for authorization?
or
we use the oidc client adapter(https://github.com/openid/AppAuth-JS) to make it generic to integrate with any auth/authorization provider?

[EricWittmann]

That's a good question. The implementation currently uses the Keycloak adapter with the assumption that KC can be used to broker to other auth solutions.

I'm not against an option to use the more generic oidc adapter if there is no loss of functionality. I haven't looked enough at both to understand the pros and cons. I do know that we must support Keycloak to log into the UI and then have the UI make authenticated calls to the API backend, in addition to supporting direct API calls from other clients (curl, Java client, postman, etc).

[iceman91176]

Might be a little late to jump on board here, but here is some feedback

We are using apicurio for kafka-schemes. We are running Strimzi which has OAuth2 support,so all our clients/user are already defined in a keycloak instance. So it has to be possible to us an existing authorization-server (keycloak) instance

For securing the access to the confluent-compatible API using basic-auth is a requirement, when using clients that don't support oauth2. Username/password should be client-id/client-secret of a keycloak (oidc) client in that case.

Regarding auhorization - both role-based and resource-based (per artifact) make sense. Keycloak-Authorization-Services are well suited for the latter - managing the permissions is the challenge.

Currently we are using a proxy-based solution that offers role-based api-access to the API. It uses keycloak,too and allows basic-auth for confluent-compatible clients.

Grouping artifacts makes sense. Think of a single client (e.g. kafka-producer) that uses different schema. Grouping clients also has its use-cases. Both requirements can be solved with Authorization-Services

[carlesarnal]

This was implemented a while ago, closing it.