Oauth2 Authentification

[tchiotludo]

Since micronaut support oauth2, it will be fine to have this support on KafkaHQ

[suspistew]

I've got a question. Currently, to set the oauth2 config in micronaut, it's required to use

micronaut:
  security:
    oauth2:
      ...

To be more consistent, I thought we could set the oauth2 settings under

kafkahq:
  security:
    oauth2:
      ...

I've discussed a bit with the community about this. To do that, we just need to @Replace the oauth configuration bean, to make sure it take config from the key we want. Do you want to do this or to let the default micronaut key ?

[tchiotludo]

to be honest, I just can't think you could change the micronaut.securty.oauth by a custom one.

I imagine It can be done with an extends to the base config class, just change the configuration prefix, and add @Replaces. no ?

To be honest, I'm not really sur to change this one. (not really sure, just first impression). The advantage with keep micronaut one, just drop a link in kafkahq docs to micronaut docs and documentation is done and up to date. In the others case, you will need to keep sync the documentation, and since it not my preferred flavor :smile: , I'm not really sure to want that.

seems to be simpler like that, no ?

[suspistew]

Yes, exactly how you have to do it apparently, but I haven't tried it yet. I understand the sync documentation argument, and, I rather agree with that. It's not my preferred flavor either 😆.

However, this are the two points I had in mind when asking this :

• link to the micronaut documentation will lead for the user to think he has something to do with an implementation of OauthUserDetailsMapper, because it's one of the pre-requisites in the documentation. (Moreover, I'm not sure the oauth2 config will evolve so often, but it's just opinionated) However, to avoid the user to think he has something to implement, we could just add a little bit of informations in an oauth2 section in the readme, and link to micronaut doc yes.

• Speaking of OauthUserDetailsMapper impl, we will provide some, compatible with the different oauth2 providers (keycloak, google, amazon..). We'll have to create one per provider, or try to be generic, I guess, because the detail of the users can be different from provider to provider. (I am not 100% sure about this, I have to check the result of getUserDetail from at least 2 providers)

The workflow , as I understand it, is the following:

1. Redirect to provider login page
2. Login
3. Callback to kafkaHQ with an access token
4. Call the provider api to get user details using the access token.
5. Convert user details from the provider to UserDetails of micronaut.

4 and 5 are the userDetailsMapper's job.

The userDetailsMapper class used is dependent of the name set for the oauth2 client. (Ex: if the user sets the client name "toto", then the impl has to be called TotoUserDetailsMapper.) For this, I wanted to create a field, based on an enum that could control which mapper can be called. (the implemented ones).

[tchiotludo]

Oh my god ! You're right, micronaut don't provider standard (like google, ...) oauth flow ... I don't have think they will not provide it !

Also, seen the micronaut docs, really too complicated for a standard user, so we clearly need to add configuration on README in order to just extract relevant information. (you catch me, I don't read the doc for a long time :smile:)

Here is a complex challenge, defined if you want to be generic or not. As I know, all provider with give you at least a login (or email depending on provider). This can be sufficient to allow user to log and provide an internal mapping of user in KafkaHQ and login like that :

kafkahq:
  security:
    google:
      domain: # Allow domain
      - mycompany.com
      default-roles: # Default roles when log through oauth
      - topic/read
      users: 
        user: # Oauth Login Username
            roles: 
            - topic/read
            - topic/insert
            - topic/delete
            attributes:
              topics-filter-regexp: "test.*"

WIll work for basic usage, but people will want to have some king of group. But I think you can see this later for now. I don't think it will be easy to have group of users from oauth simply not on google for example.

So my opinion, If you can go generic and only extract login & potentially email (depending on providers), just go, I'll work for most use case and good first win. Just let the possibility later to have specific OauthUserDetailsMapper for later maybe ?

This example https://github.com/micronaut-guides/micronaut-oauth2-oidc-google don't seems to have a specific OauthUserDetailsMapper (but have a HostedDomainClaimValidator that seems to be specific for google for claims.get part).

Sorry to be very large on this response, but I never play with the micronaut implementation and my previous oauth2 flow provider implementation by providers.

To recap :

• if generic is possible
  • go for it
  • maybe later we will add specific call
• if generic is not possible
  • we need to start with a standard one (google I think)

Tell me if it make sense for you ?