Skip to content

Cannot change external auth provider type in management UI #23602

@MajorDallas

Description

@MajorDallas

Changing the external authentication provider type in the management UI, eg. between 'oidc' and 'saml', does not enable the Save button and the change cannot be committed. When changing other options simultaneously, the Save button will be enabled and the request will succeed, but the provider type is not updated and there is no indication of this failure.

This is on Radjabov, deployed via OVA on vSphere.

Upon clicking the radio button for any of the provider types, Firefox makes a POST request. The back-end logs this request:

Sep 26 19:15:48 host production[547983]:  INFO -- production: Started POST "/ops/settings_form_field_changed/authentication" for 10.189.60.120 at 2025-09-26 19:15
:48 -0400
Sep 26 19:15:48 host production[547983]:  INFO -- production: Processing by OpsController#settings_form_field_changed as JS
Sep 26 19:15:48 host production[547983]:  INFO -- production:   Parameters: {"provider_type_oidc"=>"oidc", "id"=>"authentication"}

then responds with a 200 OK with content:

throw "error";
$('#verify_button_on').hide();
$('#verify_button_off').show();
miqButtons('hide');

The Save button remains greyed out and unclickable.

If I also toggle "Enable SSO," 'hide' becomes 'show' and the Save button can be used. With both settings modified and clicking Save, the logged result is:

Sep 26 19:15:52 host audit[547983]:  INFO -- audit: <AuditSuccess> Username [admin], from: [Common.settings_update_save], VMDB config updated (authentication/sso_enabled:[true] to [false])

No change to the provider_type setting is included in this log. There is no separate log for it, either. In fact, the value in the db table settings_changes remains unchanged.

I suspect the root bug is in the front-end: provider_type_oidc => 'oidc' seems like it should be provider_type => 'oidc' to me, since the corresponding key in the database is /authentication/provider_type. The front-end will also send provider_type_none => 'none' and provider_type_saml => 'saml'.

However, that the back-end may be allowing an invalid configuration key to pass without so much as a warning to the administrator should also be considered a bug, imo. The request to change the provider type should result in some indication that the key is invalid, or the request to commit the change (via the Save button) should give some feedback about what changes were requested and which were actually applied, or anything to alert the user that something didn't work as expected.

Metadata

Metadata

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions