Autorisierung und Authentifizierung

Datenbanktools verwenden OAuth 2.0 für sichere Authentifizierung und Autorisierung.
  • SSO-basierte Anmeldung: Benutzer authentifizieren sich über IAM oder Single Sign-On (SSO) mit OAuth 2.0.
  • Autorisierung pro Benutzer: Der Zugriff wird basierend auf den Gruppenmitgliedschaften des Benutzers und den zugewiesenen Anwendungsrollen erzwungen.
  • Kurzlebiges Token: Der MCP-Client ruft den MCP-Server mit einem kurzlebigen Zugriffstoken auf.
  • Keine Kennwortfreigabe: Der MCP-Server führt einen sicheren Backend-Tokenaustausch durch, um die Token abzurufen, die erforderlich sind, um im Benutzerkontext zu handeln und den Downstream-Zugriff anzufordern, ohne dass Zugangsdaten für den Benutzer oder Client verfügbar gemacht werden.
  • Geltungsgebundener, kurzlebiger Datenbankzugriff: Der MCP-Server ruft ein Geltungsbereichs-Token speziell für die erforderlichen Datenbankvorgänge und -ressourcen ab. Es ist zeitgebunden und in Berechtigungen begrenzt.
  • Vertrauensgrenzen und Validierung: Token werden von den entsprechenden Identitätsservices validiert.
  • Auditierbarkeit: Authentifizierungs- und Autorisierungsereignisse werden protokolliert, um Sicherheitsmonitoring und Compliance zu unterstützen.
  • Häufige Fehlerresultate: Wenn dem Benutzer keine Anwendungsrolle zugewiesen ist oder das Token ungültig oder abgelaufen ist, wird die Anforderung mit einem Autorisierungsfehler abgelehnt, und der Benutzer muss sich möglicherweise erneut authentifizieren oder den Zugriff anfordern.

Das folgende Diagramm zeigt einen End-to-End-Ablauf, bei dem ein Benutzer mit IAM-Anwendungsrollen den MCP-Server für Datenbanktools aufruft, der über eine Verbindung zu Datenbanktools, die für die tokenbasierte IAM-Datenbankauthentifizierung konfiguriert ist, eine Verbindung zu Oracle Database Cloud Service herstellt.

Das Diagramm zeigt auch, wie die IAM-Identität des Benutzers an die Datenbank propagiert wird. Außerdem wird das datenbankseitige Setup für IAM-Benutzer hervorgehoben, d.h. es wird ein Datenbankbenutzer erstellt, der global durch einen IAM-Principal-Namen identifiziert wird.

Diese Abbildung zeigt einen End-to-End-Ablauf, bei dem ein Benutzer mit IAM-Anwendungsrollen einen MCP-Client zum Aufrufen des MCP-Servers für Datenbanktools verwendet.

In den folgenden Schritten wird beschrieben, wie eine Benutzeranforderung vom MCP-Client zur Datenbank über den MCP-Server authentifiziert, autorisiert und ausgeführt wird.

  1. Der Benutzer meldet sich mit IAM SSO an, und der MCP-Client ruft ein Zugriffstoken ab.
  2. Der Client ruft den MCP-Server mit Authorization: Bearer <token> auf.
  3. Der MCP-Server validiert das Token und die Rollen des Benutzers.
  4. Der MCP-Server ruft die erforderliche zeitgebundene Datenbankautorisierung ab.
  5. Der MCP-Server führt die Anforderung aus und gibt Ergebnisse zurück.

Ablauf der OAuth 2.0-Clientzugangsdaten

Bei Service-to-Service-Szenarios, in denen Anwendungen ohne Benutzerinteraktion kommunizieren, kann der Ablauf "OAuth 2.0-Clientzugangsdaten" verwendet werden. In diesem Ablauf fordert ein vertraulicher Client, der in der Identitätsdomain konfiguriert ist, ein Zugriffstoken vom Autorisierungsserver an, der den Tokenendpunkt verwendet. Dem Client müssen die entsprechenden Geltungsbereiche und Rollen zugewiesen sein, damit er auf den MCP-Server zugreifen kann.

Nachdem das Zugriffstoken abgerufen wurde, wird es mit dem Authorization: Bearer <access_token>-Header in API-Anforderungen aufgenommen.
  • Wenn das Token ungültig oder abgelaufen ist, gibt die Anforderung eine 401 Unauthorized-Antwort zurück.

  • Wenn das Token gültig ist, aber nicht über ausreichende Berechtigungen verfügt, wird eine 403 Forbidden-Antwort zurückgegeben.

Die gesamte Kommunikation zwischen MCP-Clients und dem MCP-Server erfolgt über HTTPS, um die Verschlüsselung während der Übertragung und den Schutz von Authentifizierungstoken sicherzustellen.