Errata Tool added a comment - 2025/03/20 8:18 AM Since the problem described in this issue should be resolved in a recent advisory, it has been closed. For information on the advisory (Control plane Operators for RHOSO 18.0.6 (Feature Release 2)), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2025:3032

Mauricio Harley added a comment - 2025/01/09 1:37 PM Taking a look at the functional tests.

Dave Wilde added a comment - 2025/01/07 3:05 PM I'm still troubleshooting the tests, I'm not able to get a public end point created in the function testing.

Ade Lee added a comment - 2024/02/12 10:05 PM Federation is a little more complicated because there are a number of things that need to be set up. We should focus on OIDC because that's what we decided that we would support in 17.  At the same time, it would be helpful to implement changes in such a way as to allow folks to configure SAML if they wanted to. Lets start by considering what configuration needs to be done to support OIDC. keystone.conf changes.  For OIDC, this is relatively straightforward.  Basically, it consists of auth/methods and openid/remote_id_attribute. puppet .  As mentioned before, this can be easily done with CustomServiceConfig with no further code changes needed in the keystone operator. apache config changes.  These might be able to be added simply as extra files in the apache config directories.  The assumption here is that the keystone image includes all the required module rpms already installed.  There is a mechanism in the keystone-operator called DefaultConfigOverwrite which we might be able to use - although the comment says that this functionality still needs to be implemented.  The apache changes can be seen in puppet , although we may not need all the things in that template file.  There is also a redirect file that needs to be added -  [file| https://github.com/openstack/keystone/blob/master/etc/sso_callback_template.html ] The CA file for the IdP needs to be added to the keystone container trusted CA bundle.  There already exists a mechanism to add CAs to the keystone CA bundle. Once we have the ability to add these configs, we need to set some things up in order to test everything in CI.  Fortunately, we've already figured out all the steps to do this when we added testing for OIDC upstream.  Essentially, we set up keycloak as an OIDC provider (no need to add IdM), which runs as a container on the test VM.  We then configure a keycloak client.   We then configure and run the tempest tests - which set up the keycloak test users, configure the required mappings and protocols on the keystone side - and attempts to issue scoped and unscoped tokens.  The steps we need to follow to obtain a successful test are in https://github.com/openstack/keystone/blob/7dc175a41f92e3f01cf26912431d0f2c98a03b32/devstack/lib/oidc.sh   and the keystone federation tests are in the keystone-tempest-plugin   So, a suggested set of tasks would be: Implement DefaultConfigOverwrite to allow cnfiguration of apache options Figure out how to run a script like oidc.sh in a CI job to set up keycloak etc,. Run the keystone federation tests in a job that configures OIDC, mounts the right CA bundle, runs the setup  script and executes the OIDC tempest tests. Document the new way of setting up federation with OIDC. dwilde@redhat.com ggrasza@redhat.com dmendiza pweeks@redhat.com rheslop@redhat.com jagee@redhat.com rh-ee-millevy   jjung@redhat.com   – what do you guys think?