Tags: keycloak/keycloak
Tags
Migrate basic broker login tests to new testsuite Add shared test infrastructure (BrokerConfigSupport, KcOidcBrokerConfigSupport, SamlBrokerConfigSupport, BrokerLoginTest) and migrate KcOidcBrokerTest, KcOidcBrokerClientSecretBasicAuthTest, and KcSamlBrokerTest. The shared OIDC config brokers through the Keycloak-specific "keycloak-oidc" identity provider, matching the legacy KcOidcBrokerConfiguration baseline (with prompt=login and loginHint forwarding); a generic-provider variant can be added where a test actually needs it. The provider user is created without a first/last name, as the legacy suite did, so the imported consumer user is incomplete and the consumer's first-broker-login review-profile page is shown. The default helper asserts that page appears before updating it (mirroring the legacy assertCurrent()), and VERIFY_PROFILE is disabled on the provider realm since the new testsuite enables it by default and would otherwise stop the incomplete user at the provider. A tolerant updateAccountInformationIfPresent() variant remains for flows that intentionally skip profile review. The login flows run against the migrated broker-app client (via BrokerAppClientConfig) rather than the framework default test-app, and the OIDC provider-side client carries the legacy broker callback configuration (redirect/admin/backchannel-logout URLs, post-logout redirect URIs) rewritten from the consumer base URL, mirroring the SAML base. The legacy test classes are retained since they carry additional test methods not yet covered by this migration. Per Copilot review: the protocol bases (AbstractKcOidcBrokerTest / AbstractKcSamlBrokerTest) now inject the default provider/consumer realms and implement getProviderRealm()/getConsumerRealm() once, instead of leaving them abstract for every concrete test to implement. A concrete test using the default config needs no realm fields or getters at all; a test that needs a different config for one side shadows just that field (same name/type, different @InjectRealm#config) - the framework resolves the shadowed and inherited field to the same deployed realm, so no getter override is needed either way (same pattern already used by AccountRestServiceLightweightTokenTest#managedRealm). Closes #51954 Signed-off-by: Stefan Guilhen <sguilhen@redhat.com> Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
PreviousNext