Windows-Client, Web-Anwendung und MCP im Zusammenspiel

Windows-Client, Web-Anwendung und MCP greifen über unterschiedliche Wege auf Zeta Test Management zu. Sie teilen fachliche Projekt- und Berechtigungsgrenzen, sind aber weder technisch noch funktional austauschbar. Planen Sie jeden Zugangsweg als eigene Vertrauens- und Netzwerkgrenze.

Aufgaben und Funktionsgrenzen

Der Windows-Client ist die primäre Oberfläche für Einrichtung, Administration und den umfassenden fachlichen Funktionsumfang. Die Web-Anwendung stellt die browserbasierten Kernbereiche Testläufe und Ergebnissuche bereit und kann zusätzlich einzeln freigeschaltete Vorabbereiche anzeigen. MCP ergänzt eine kleine, standardmäßig deaktivierte Automatisierungsschnittstelle; der aktuelle Umfang ist überwiegend informativ und schreibgeschützt.

Eine kompakte Gegenüberstellung einschließlich der aktuellen Vorabbereichsschlüssel und MCP-Werkzeuge finden Sie unter Funktionen in Windows, Web und MCP.

Architektur und Netzwerkgrenzen

  • Der Browser verbindet sich per HTTPS mit dem Host der Web-Anwendung. Er benötigt keinen direkten Zugriff auf Datenbank- oder Projektdateifreigaben.
  • Der Windows-Client wird je nach Betriebsmodell mit einem zentralen Backend verbunden oder verwendet eine unterstützte lokale Backend-Variante.
  • Anwendungs- und Serverkomponenten greifen innerhalb der vorgesehenen Server- und Berechtigungsgrenzen auf Projektdaten, Datenbank und Dateien zu.
  • MCP verwendet den Web-Host über POST /mcp und eine eigene API-Schlüsselprüfung. Der MCP-Schlüssel ist nicht mit dem Backend-Schlüssel des Windows-Clients gleichzusetzen.

Veröffentlichen Sie weder Datenbank noch Projektdateifreigaben direkt im Internet. Verwenden Sie für externe Zugriffe eine kontrollierte HTTPS-Veröffentlichung, Firewall-Regeln und gegebenenfalls VPN oder Reverse Proxy. Dokumentieren Sie Datenflüsse, Dienstkonten und Vertrauensgrenzen vor der Inbetriebnahme.

Gemeinsame Datenbasis und Berechtigungen

Windows- und Web-Anwendung arbeiten innerhalb der konfigurierten Projektgrenzen mit derselben fachlichen Datenbasis. Browser und MCP greifen jedoch nicht direkt auf Datenbank oder Projektdateien zu, sondern über die dafür vorgesehenen Serverkomponenten.

Trennen Sie Programmdateien, Projektdaten, Datenbank und Sicherungen. Vergeben Sie für Dienste und technische Konten nur die erforderlichen Datei-, Datenbank- und Projektrechte. Prüfen Sie Pfadzuordnungen, Sicherungs- und Wiederherstellungsverfahren sowie die Erreichbarkeit aus der jeweiligen Serverzone. Eine funktionierende Anmeldung ersetzt keine Projektberechtigung.

Active-Directory- und LDAP-Anmeldung

Je nach Projekt- und Serverkonfiguration können Benutzer über integrierte Projektkonten oder ein angebundenes LDAP-Verzeichnis authentifiziert werden. Der Web-Host beziehungsweise die zuständige Anwendungskomponente muss den Verzeichnisdienst aus seiner Netzwerkzone erreichen können; Rollen und Projektrechte werden weiterhin in Zeta Test Management ausgewertet.

Ein eigener IIS-Mechanismus für NTLM oder Kerberos ist dafür nicht grundsätzlich erforderlich, sofern die Anwendung die LDAP-Anmeldung übernimmt. Wenn Ihre Zielarchitektur Windows-Authentifizierung, Single Sign-on oder einen vorgeschalteten Identity-Proxy vorsieht, muss diese Variante separat geplant und abgenommen werden. Bevorzugen Sie verschlüsselte LDAP-Verbindungen und prüfen Sie Zertifikatsvertrauen, Gruppenauflösung und Ausfallverhalten.

Backend-Konnektivität des Windows-Clients

Der Windows-Client kann gegen eine zentrale Backend-URL mit zugehörigem Backend-API-Schlüssel konfiguriert werden. Hinterlegen Sie die Werte in den dafür vorgesehenen Programmoptionen oder einer verwalteten Konfiguration, verwenden Sie ausschließlich HTTPS und setzen Sie in Dokumentation nur Platzhalter wie https://backend.example.org/ und <backend-api-key> ein.

Bei unterstützten lokalen Betriebsarten kann der aktuelle Client ohne konfigurierte zentrale Backend-URL einen mitgelieferten lokalen Kestrel-Host für lokale Vorgänge starten. Diese lokale Variante ist keine Empfehlung, einen Dienst ungeprüft nach außen zu öffnen. Netzwerkzugriff, Bindung, Zertifikate und Lebenszyklus müssen zum gewählten Betriebsmodell passen.

Der Backend-API-Schlüssel des Windows-Clients und ein MCP-API-Schlüssel erfüllen unterschiedliche Aufgaben und dürfen nicht verwechselt oder wiederverwendet werden. Schützen und rotieren Sie beide Geheimnisse, protokollieren Sie keine vollständigen Werte und sperren Sie nicht mehr benötigte Schlüssel.