Can't login to AKHQ with too many groups/patterns

[haraldott]

Hi,
we have a case of an OIDC user who has too many patterns in his groups assigned.
You probably know about this issue, the jwt token for login will be composed of all the groups + patterns, thus resulting in a jwt token which is too big for the browser -> login not possible.

Is there any way around this? AKHQ already compresses all groups + patterns + roles of a user, so we don't see any room for optimisation on our side.

The last time this issue was addressed was with this PR: #1630, but it somehow just defers the problem.

Regards

[AlexisSouquiere]

When I had this issue (before the token compression), the workaround that I put in place was (for my setup in K8S)

• Switch micronaut.security.authentication to bearer
• Increase micronaut.server.netty.max-header-size (like 100000)
• Increase the K8S nginx header max header size by adding this in the annotations

    nginx.ingress.kubernetes.io/server-snippet: |
      client_header_buffer_size 100k;
      large_client_header_buffers 4 100k;

Did you already try something like this ?

[haraldott]

With basic-auth, this seems to be working even with quite big amounts of groups/patterns.
We seem to be having trouble with the bearer token when trying to login through SSO though. We're seeing the following error:

{ "message":"Page Not Found", "_links":{ "self":{ "href":"/oauth/login/sso", "templated":false } } }

This is our configuration:

ingress:
  enabled: true
  ingressClassName: ""
  annotations:
    cert-manager.io/cluster-issuer: #censored#
    nginx.ingress.kubernetes.io/proxy-buffer-size: "256"
    nginx.ingress.kubernetes.io/proxy-buffers-number: "16"
    nginx.ingress.kubernetes.io/large-client-header-buffers: "4 256K"
    nginx.ingress.kubernetes.io/client-header-buffer-size: "256K"
    nginx.ingress.kubernetes.io/client-body-buffer-size: "256k"
  paths:
    - /
  hosts:
    - #censored#
  tls: 
   - secretName: akhq-tls-cert
     hosts:
       - #censored#

configuration:
  akhq:
    ui-options:
      topic-data:
        sort: NEWEST
    security:
      default-group: no-roles
    server:
      access-log:
        enabled: true
        name: org.akhq.log.access

secrets:
  akhq:
    connections:
      event-hub-kafka:
        properties:
          bootstrap.servers: "#censored#"
          security.protocol: SSL
          ssl.key.password: <path:kafka/mgmt#admin-user.pw>
          ssl.keystore.password: <path:kafka/mgmt#admin-user.pw>
          ssl.truststore.password: <path:kafka/mgmt#cluster-ca.pw>
          ssl.truststore.location: /app/ca.p12
          ssl.keystore.type: "PKCS12"
          ssl.keystore.location: /app/user.p12
  micronaut:
    server:
      netty:
        max-header-size: 100000
    security:
      authentication: bearer
      enabled: true
      oauth2:
        enabled: true
        clients:
          sso:
            client-id: <path:dev/sso/akhq#ClientID>
            client-secret: <path:dev/sso/akhq#ClientSecret>
            openid:
              issuer: "#censored#"
              authorization:
                acr-values:
                  - "gas:strong"
              configuration-path: ".well-known/openid-configuration"
      token:
        jwt:
          signatures:
            secret:
              generator:
                secret: <path:akhq-jwt/mgmt#akhq-jwt.pw>

[dominicooox]

We had the same issue that the cookie size became too big and therefore for basic-auth we could use token-based authentication to avoid cookie limits but for OAuth2 this wasn't the case and from my understanding is not possible.