Auth-Service produktive Einrichtung vereinfachen

[MrSebastian]

Damit der Auth-Service seine Arbeit erfolgreich vollziehen kann müssen die Rollen, Rechte, Clients und Signierung konfiguriert werden. Diese Konfigurationen werden aktuell zum Teil über Dummydaten vorgenommen. Die Dummydaten dienen zur Unterstützung der Entwicklung und sind nicht auf den produktiven Einsatz abgestimmt.

Im Rahmen dieses Issues sollen die vorhandenen Mängel und notwendigen Schritte für einen effektiven produktiven Einsatz des Auth-Service ermittelt und deren Lösung erarbeitet werden.

References:

Feedback aus PR:

          _:bulb: Codebase verification_

⚠️ Potential issue

Based on the gathered information, I can now provide the final response:

Redirect URIs need environment-specific configuration and security improvements

The current implementation has several issues:

• Redirect URIs are hardcoded in database migration scripts (V2_1__insertDummyWlsClient.sql) for both H2 and Oracle
• Production-ready configurations are missing, as evidenced by the lack of HTTPS URLs in the migration scripts
• While there are multiple environment-specific configurations (dev, prod, kon), the redirect URIs are not parameterized

Required changes:

• Move redirect URI configuration to environment-specific YAML files (application-{env}.yml)
• Use environment variables or configuration server for dynamic URI management
• Enforce HTTPS for all non-localhost redirect URIs
• Consider using a more restrictive URI pattern than the current wildcard in stack/keycloak/migration/02_add-client-wls.yml

🔗 Analysis chain

Review redirect URI configuration

The redirect URIs are currently set to development URLs:

• http://127.0.0.1:8080/oauth2/authorized
• http://localhost:8083/login/oauth2/code/sso

This needs to be parameterized for different environments. Also, consider:

• Using HTTPS for all redirect URIs in production
• Implementing strict URI validation

---

The previous search might have been too specific. Let's broaden our search to find any OAuth2 or redirect related configurations and also list all configuration files to better understand the project structure.

---

The initial search revealed that redirect URIs are stored in the database and there are multiple environment configurations. Let's check if there are environment-specific OAuth configurations and compare the dummy data scripts to see if there are differences in how redirect URIs are handled across environments.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check for environment-specific configurations
rg -g '**/*.properties' -g '**/*.yml' 'oauth2.*redirect'

Length of output: 58

---

Script:

#!/bin/bash
# Let's check for any OAuth2/redirect related configuration files and environment specific settings
rg -g '**/*' -i 'redirect.*uri|oauth.*redirect|callback.*url'

# Also check for any application configuration files
fd -e yml -e yaml -e properties -e conf -e config -e xml

Length of output: 12433

---

Script:

#!/bin/bash
# Let's check the application configuration files for environment-specific OAuth settings
rg -g '**/*.yml' -g '**/*.properties' 'oauth|security|ssl|https'

# Also check the content of the Oracle dummy data script to compare with H2
cat wls-auth-service/src/main/resources/db/dummydata/oracle/V2_1__insertDummyWlsClient.sql

Length of output: 7024

Originally posted by @coderabbitai[bot] in #603 (comment)