In the certains situation customers using tools like Authentik or
Zitadel may encounter issue with using id_token as in that case it may
also return access_token despite not set deliberately
The `code` flow is now the preffered approach for OIDC hence
the ability for setting that options gives more flexibility.
Implements: oidc-response-type option
Closes-Bug: #2084184
Change-Id: I251dffbdf97998998066d5efd2d8d9386ecd19e5
The values of the protocol ID and identity provider ID are
reversed in the charm's code. This causes the mod_auth_openidc
config to render incorrectly in the Apache template. This change
fixes the reversed values and adds a config option for
defining the identity provider ID. This change also adds new
config options for enabling using mod_auth_openidc with
multiple Keystone units and with proxies.
Closes-Bug: #2065590
Func-Test-Pr: https://github.com/openstack-charmers/zaza-openstack-tests/pull/1235
Change-Id: Ie7da5f9a85027a287aad9958c54848a948f8495c
The property oauth_introspection_endpoint reads from the metadata url to
determine the introspection endpoint when not passed explicitly in the
configuration.
This patch includes various fixes to make the hooks execution more
robust.
This change introduces the configuration of OAuth to enable auth-openidc
which is browser-less.
When enable-oauth is set to true (the default) and
oidc-auth-verify-jwks-uri is empty, the charm will try use
oidc-oauth-introspection-endpoint if set, otherwise the charm will fetch
the content at oidc-provider-metadata-url and use the value available at
the key introspection_endpoint.
This configuration option allows the operator to override what claim
must be set in the REMOTE_USER environment variable which it's used by
Keystone to determine the username unless the mapping rules use a
different field.
The protocol-id is how the charm will present itself to keystone and
make it include a section in keystone.conf with its name.
The template is updated to make the URLs include this information in
their path.
The crypto passphrase is stored in the application data bag, when not
found the leader will generate it and store it, this will allow the
followers to read it on the relation changed.
