calmcp 0.9.1 bis 0.9.3: Sicherheit und Betrieb auf SAP BTP

Neben neuen Funktionen haben die Versionen 0.9.1 bis 0.9.3 von calmcp vor allem eines gebracht: einen sichereren und besser nachvollziehbaren Betrieb auf SAP BTP. Dieser Beitrag fasst zusammen, was sich für Betreiber geändert hat und was beim Update zu tun ist.

Login nur mit Freigabe des Clients

Im Team-Betrieb melden sich Benutzer über XSUAA an, ihr KI-Client registriert sich dafür automatisch per Dynamic Client Registration. In der gemeinsam genutzten Anmeldebibliothek gab es eine Lücke: Ein von beliebiger Seite registrierter Client konnte über eine bestehende SSO-Sitzung eine Anmeldung abschließen, ohne dass der Benutzer zugestimmt hatte, und dann mit dessen calmcp-Berechtigungen arbeiten.

Seit 0.9.3 zeigt calmcp vor jeder Anmeldung eine Freigabeseite mit dem Namen und der Rücksprungadresse des Clients. Mit Ablehnen endet die Anmeldung ohne Zugriff. Zusätzlich leitet XSUAA Anmeldungen nur noch an die exakte Callback-Adresse von calmcp zurück statt an jede Adresse unter *.hana.ondemand.com.

Rollen: Lesen und Schreiben getrennt

Bisher reichte auf BTP die Rollensammlung CALMCP_Viewer für alles, was der Server anbot. Jetzt gibt es zusätzlich CALMCP_Editor: Nur Benutzer mit dieser Rolle sehen die Tools zum Anlegen und Ändern, auch wenn der Schreibzugriff für den Server eingeschaltet ist. Leser und Aufrufer mit API-Key sehen sie nicht.

Sicher voreingestellt

• Kein offener Endpunkt: Ist weder XSUAA noch ein API-Key konfiguriert, startet der HTTP-Transport nicht. Für die lokale Entwicklung gibt es einen ausdrücklichen Schalter, der nur auf 127.0.0.1 lauscht und auf Cloud Foundry ignoriert wird.
• CORS nur auf Ansage: Ohne CALM_CORS_ORIGINS sendet calmcp keine CORS-Header, ein Wildcard * wird beim Start abgelehnt. Sonst könnte jede Website über den Browser eines Entwicklers Cloud ALM Daten lesen.
• Strenge Eingaben: Unbekannte Parameter, etwa projectId statt project_id, führen zu einem Fehler statt stillschweigend ignoriert zu werden. Eine ungefilterte Antwort auf eine gefilterte Frage wirkt verlässlich und ist trotzdem falsch.

Fehler, mit denen man etwas anfangen kann

Schlägt ein Aufruf fehl, liefert calmcp ein JSON-Objekt mit festem Fehlercode (NOT_FOUND, FORBIDDEN, RATE_LIMITED, TIMEOUT …), der Angabe, ob ein erneuter Versuch sinnvoll ist, und einem Hinweis. Bei FORBIDDEN nennt der Hinweis den Scope, der der Cloud ALM API Service-Instanz fehlt, zum Beispiel calm-api.tasks.read. Lesende Aufrufe, die Cloud ALM mit 429 oder 503 beantwortet, wiederholt calmcp einmal, wenn die geforderte Wartezeit höchstens fünf Sekunden beträgt. Anlegen und Ändern werden nie wiederholt.

Die richtigen Cloud ALM Scopes

Was calmcp lesen darf, bestimmen die Scopes der Cloud ALM API Service-Instanz hinter der Destination, nicht die Rolle des einzelnen Benutzers. Zwei Gruppen werden leicht vergessen, und ihr Fehlen fällt nicht unbedingt als Fehler auf:

• Private und geschützte Projekte brauchen calm-api.projects.private.read und calm-api.projects.protected.read. Ohne sie fallen Summen niedriger aus als in der Cloud ALM Oberfläche.
• Personenbezogene Felder wie Bearbeiter oder Verantwortlicher in Analytics brauchen je Provider einen eigenen *.personal.read-Scope.

Die README enthält jetzt eine vollständige Übersicht, welcher Scope wofür nötig ist. Vergeben Sie nur, was die Installation zeigen soll: Jeder Aufrufer von calmcp sieht, was diese Scopes erlauben.

Checkliste für das Update

• Ein vollständiges cf deploy des neuen mtar ausführen. Wer nur die App neu pusht, behält die alte Callback-Freigabe in der XSUAA-Instanz.
• Benutzern, die anlegen oder ändern dürfen, die Rollensammlung CALMCP_Editor zuweisen.
• Einen Reverse Proxy vor calmcp so konfigurieren, dass er Cookie, Set-Cookie und Origin durchreicht. Bei eigener Domain CALM_PUBLIC_URL setzen.
• Die Scopes der Cloud ALM API Service-Instanz mit der Übersicht in der README abgleichen.

Details stehen im OAuth Upgrade Guide. Alles zur Installation finden Sie auf der Produktseite calmcp – der CALM MCP Server.