Add a "Test" Button for OIDC Configuration Validation on the Admin Page

[mastercactapus]

What problem would you like to solve? Please describe:
Currently, when setting up OIDC integration for the first time, the only way to validate the configuration is to set it, log out (or open a new browser) and then test the login flow. This could be a tedious process especially when the configuration does not work as expected.

Describe the solution you'd like:
A "Test" button should be added next to the OIDC issuer URL input field on the admin config page. This button would promptly validate the entered URL, running basic checks (for example, verifying the payload of .well-known/openid-configuration). This feature should:

• Be as helpful as possible
• Limited to admin users (permission wise)
• Setup as a mutation (1 test per click)

Describe alternatives you've considered:
An alternative could be building an automatic configuration checker that runs these checks in the background every time a change is made, although this could potentially lead to unnecessary processing if the user is not ready for the check to occur.

Additional context:
Additional enhancements to consider to further improve the user experience:

• On failure (e.g. 404), the system could attempt to search up the tree (up to x-number of parent paths) for a valid one and suggest it to the user.
• Look into the possibility of validating credentials as well.

[Root-acess]

Problem Description

When configuring OIDC (OpenID Connect) for the first time in GoAlert, validating the configuration is currently a manual and time-consuming process. Users must set up the configuration, log out, and attempt to log in to see if it works. This can be tedious, especially when troubleshooting issues with the OIDC issuer URL or other setup details.

Solution Proposal

Add a "Test" button next to the OIDC issuer URL input field on the admin configuration page. This button would allow administrators to quickly validate their OIDC settings, making the process more efficient and user-friendly. This button should perform basic checks, such as verifying the .well-known/openid-configuration endpoint to confirm connectivity and validity of the URL and initial payload data.

Key Features

1. Basic Connectivity Check:

   • Verify that the provided OIDC Issuer URL is reachable.
   • Fetch the .well-known/openid-configuration JSON document and check its basic structure (e.g., required fields such as authorization_endpoint, token_endpoint, etc.).

2. Credential Validation (Optional, if credentials are part of the setup):

   • If the admin has entered credentials, test them by requesting a basic authentication token.
   • This check would help in validating both the URL and credential correctness.

3. Helpful Feedback on Failure:

   • If the test fails (e.g., 404 error, invalid URL), return helpful feedback to the admin.
   • Optionally, the system could attempt to "walk up" the directory tree of the URL to check if a higher-level path has the necessary configuration, then suggest this path if found valid.

4. Admin-Only Access:

   • Limit the test button functionality to admin users, ensuring that only authorized personnel can validate the OIDC configuration.

5. One Test per Click:

   • Implement this as a mutation so the test runs once per button click. Avoid automatic checks on every keystroke or setting change to prevent unnecessary processing.

Technical Implementation Steps

1. Frontend:

   • Add a "Test" button next to the OIDC issuer URL input field in the admin config UI.
   • Display a loading spinner while the test is running.
   • Display feedback messages after the test completes (success or specific error details).

2. Backend:

   • Create a GraphQL mutation, testOIDCConfiguration, which:
     • Accepts the OIDC issuer URL (and possibly credentials).
     • Performs a GET request to the .well-known/openid-configuration endpoint.
     • Validates that the response contains required fields.
     • If credentials are provided, performs a minimal authentication check to verify they work.

3. Error Handling:

   • Return clear error messages that indicate what went wrong (e.g., URL not reachable, required fields missing).
   • On a 404 or invalid URL error, attempt to check higher-level paths for a valid .well-known/openid-configuration.

4. Testing:

   • Add unit and integration tests to simulate various configurations and validate expected outcomes.
   • Test cases should include valid and invalid OIDC URLs, credential checks, and feedback message accuracy.

Possible Extensions

• Automated Suggestions:

  • On a failed validation, GoAlert could suggest corrective actions or alternative paths, such as likely correct paths in the directory tree.

• Real-time Background Validation:

  • Instead of a manual "Test" button, an optional background validation process could check configuration settings every time they are updated. This would provide admins with real-time feedback but would require optimization to avoid excessive processing.

Benefits of the Solution

• Improved User Experience: Admins can validate their OIDC setup quickly, making troubleshooting much easier and faster.
• Reduced Configuration Errors: By catching issues early, this feature can reduce the time admins spend fixing OIDC setup problems.
• Minimal Disruption: Since this solution requires no logout or login during testing, admins can troubleshoot without leaving the config page.

This "Test" button would streamline OIDC configuration, enhance usability, and make the integration setup much more efficient.