Cannot configure portal_auth_conf when using openid-connect for portal_auth

[moconno]

Looking at the values.yaml for enterprise portal, there isn't a way to configure portal_auth_conf when portal _auth: openid-connect. The only option, which is also required, is to provide a session_conf_secret. According to the docs here: https://docs.konghq.com/enterprise/1.3-x/developer-portal/configuration/authentication/sessions/, session_conf cannot be applied to openid-connect.

[hbagdi]

cc @rainest

[rainest]

At present I can think of two options:

• Simply remove portal_session_conf and portal_auth from values.yaml altogether. This somewhat breaks compatibility with 0.35, but it's possible to work around that. We'll want to continue support for the existing settings for a while, but will no longer require them.
• Instruct OIDC users to create a dummy session configuration.

@hbagdi I'm in favor of the first option, as I don't think we have that many 0.35 users still. Assuming I don't find other complications when testing this, do you think the workaround for 0.35 users below is reasonable?

Strictly speaking, the session plugin should at worst conflict with OIDC if they try to use the same cookie, which can only occur for Manager. The Portal code explicitly disables the session plugin configuration when using OIDC.

When 0.35 originally introduced session-based authentication, it only allowed a single portal_session_conf for all workspaces. This is broken for a variety of reasons, but most importantly for this means that 0.35 cannot use basic-auth or key-auth for the Portal without configuring portal_session_conf in kong.conf or equivalents. If we remove the dedicated values.yaml setting and associated secret check, 0.35 users will need to add it under env.

0.36 fixed this and allowed per-workspace Portal session configuration. If we remove the dedicated setting, users enabling a Portal with basic-auth will need to manually add a custom session configuration in Manager, though they should arguably do this anyway. Ideally, we should add quality of life improvements that handle this automatically for users, but that's outside of the chart.

At least as of 1.3, Kong will not start if portal_auth is explicitly set to basic-auth and portal_session_conf is not set, but if portal_auth isn't set, it bypasses this check while still using "Basic Authentication" as the default auth setting in per-workspace configuration. I'm not sure if there are versions that default to disabling authentication; will have to check.

[hbagdi]

Simply remove portal_session_conf and portal_auth from values.yaml altogether. This somewhat breaks compatibility with 0.35, but it's possible to work around that. We'll want to continue support for the existing settings for a while, but will no longer require them.

As long as we can work around the breaking change and provide compatibility, we can put in this change.

It is unfortunate that that there is so much change that happens at this layer in the configuration. Whatever solution you end up picking, keep your assumptions about behaviors of how various settings interact with each other to minimum, those details change frequently enough to correctly assume anything.

[rainest]

Version 1.3.0 of the Kong chart is now released, resolving this issue.