OpenIDConnect Provider for Rados Gateway IAM/STS

[median topaz]

I'm attempting configure radosgw to use Authentik as an OpenIDConnect provider for AssumeRoleWithWebIdentity STS authentication. I'll admit this appears to be a bug with radosgw and I'm in the process of reporting but I'm curious what the maintainers think about the behavior of Authentik vs. the way Keycloak handles this.

The OpenIDConnect client is configured to use the issuer endpoint https://login.lab/application/o/d7d64496e26c156ca9ea0802c5d7ed1c/ but when it attempts to reach the /.well-known/openid-configuration endpoint radosgw improperly concatenates the URL path to the issuer like this.

Improper path, note the //:

https://login.lab/application/o/d7d64496e26c156ca9ea0802c5d7ed1c//.well-known/openid-configuration

Authentik response with a 301 redirect to the correct path but radosgw doesn't follow redirects. Also KeyCloak doesn't care about the // path and just returns the normal configuration response.

Example using KeyCloak: https://docs.ceph.com/en/quincy/radosgw/keycloak/ my openid/boto3 client code is similar to this example.
RadosGW code with the bug: https://github.com/ceph/ceph/blob/cca84e653dd5ea686884cb85fdd8e20703678274/src/rgw/rgw_rest_sts.cc#L312

So Keycloak accepts the paths with // and Authentik redirects to the correct path. Is this intentional or just the behavior of whatever web-framework Authentik is built on?

[median topaz]

https://tracker.ceph.com/issues/58890

[mystic sparrow]

the redirect is caused indirectly by django which authentik is built on, and this is also not the first time that an OpenID client creates that well-known URL incorrectly

I haven't used the rados gateway, but if you can configure all the JWKS and other URLs manually, you can configure the provider to use the global issuer mode where it'll use the authentik domain as issuer

[median topaz]

Is there a way to make Authentik return an ISS without the slash? maybe something in a property mapping?