Zum Hauptinhalt springen

Delegation — im Namen des aufrufenden Benutzers ausführen

Manche Pipelines existieren, um im Moment einer bestimmten Person zu dienen: das klarste Beispiel ist der KI-Chat einer Anwendung, in dem ein Benutzer eine Frage eintippt und eine Pipeline sie durch Nachschlagen von Daten beantwortet. Für Abläufe wie diesen wäre es falsch, wenn die Pipeline ihr eigenes, breit angelegtes Service Account verwendete — der Benutzer darf nur seine eigenen Daten sehen, genau wie überall sonst in der Anwendung.

Delegation löst dies. Im Delegations-Modus führt eine Pipeline ihre Arbeit unter der Identität des aufrufenden Benutzers aus, statt unter der ihres Service Accounts. Der Benutzer sieht genau die Daten, die er sehen darf — und dies wird auf dem Server durch Datenberechtigungen durchgesetzt, nicht durch das Verbergen von Dingen in der Benutzeroberfläche.

Die effektiven Rollen sind die Schnittmenge​

Ein delegierter Lauf ist bewusst auf das beschränkt, was beide Seiten dürfen. Die effektiven Rollen sind die Schnittmenge aus den Rollen des Service Accounts und den Rollen des Benutzers:

effective roles = service-account roles  ∩  user roles

Das hat zwei Konsequenzen, die man sich merken sollte:

  • Ein mächtiges Service Account kann einem Benutzer niemals mehr gewähren, als der Benutzer bereits hat. Handelt man für einen Benutzer mit geringen Rechten, erhält man den Satz mit geringen Rechten.
  • Wenn sich die beiden Rollensätze überhaupt nicht überschneiden, hat die delegierte Identität keine Rollen — ein gültiges Ergebnis, das schlicht nichts sieht. Das ist kein Fehler; es ist die sichere Standardeinstellung. (Eine häufige Ursache dafür, dass „der Chat nichts zurückgibt", ist ein Service Account, dem die Rolle fehlt, die die Funktion benötigt — siehe unten.)

Der zugrunde liegende OAuth-Mechanismus (ein On-Behalf-Of-Grant, nur innerhalb desselben Tenants, keine Refresh-Tokens) ist beschrieben unter Authentifizierung → Delegation / On-Behalf-Of.

Wie Sie es aktivieren​

Delegation wird pro Ablauf mit zwei kleinen Bausteinen eingeschaltet.

1. Ein tokentragender HTTP-Trigger — FromHttpRequest@2​

Die Pipeline muss auf eine Weise ausgelöst werden, die die Identität des Aufrufers trägt. Der FromHttpRequest@2-Trigger tut genau dies: Er verlangt ein gültiges Access-Token an der eingehenden Anfrage und stellt die Identität des Aufrufers dem Rest der Pipeline zur Verfügung. Seine requiredRoles-Liste steuert, wer den Endpunkt überhaupt aufrufen darf — eine beliebige der aufgeführten Rollen genügt, und eine leere Liste akzeptiert jeden Aufrufer mit einem gültigen Token.

triggers:
  - type: FromHttpRequest@2
    path: /aiPrompt
    method: POST
    requiredRoles:
      - AccountingManagement
      - AccountingEmployee

2. Delegation am KI-Node — mcpDelegateToCaller​

Setzen Sie am KI-Node (AnthropicAiQuery@1) mcpDelegateToCaller: true. Die MCP-Tool-Aufrufe des Nodes (die Nachschlagevorgänge, die die KI durchführt, um die Frage zu beantworten) laufen dann unter der delegierten Identität des Aufrufers statt unter der des Service Accounts.

transformations:
  - type: AnthropicAiQuery@1
    path: $.question
    targetPath: $.answer
    apiKeyConfigurationName: AnthropicAiConfig
    mcpServiceAccountConfigName: PipelineServiceAccount
    mcpDelegateToCaller: true          # run the MCP lookups as the calling user
    mcpToolNames:
      - query_entities_simple
    question: "Answer the user's question using the available data."
info

Delegation ist fail-closed. Wenn mcpDelegateToCaller gesetzt ist, aber kein Aufrufer-Token vorhanden ist (zum Beispiel weil die Pipeline von einem Scheduler oder über die Ausführen-Schaltfläche des Editors gestartet wurde, die kein Benutzer-Token tragen), verweigert der Node den Dienst, statt stillschweigend auf das Service Account zurückzufallen. Testen Sie delegierte Abläufe über HTTP mit einem echten Bearer-Token.

Was das Service Account weiterhin benötigt​

Auch im Delegations-Modus ist das Service Account von Bedeutung, denn die effektiven Rollen sind eine Schnittmenge mit ihm. Das Service Account muss selbst die Rollen tragen, auf die sich die Funktion stützt — andernfalls ist die Schnittmenge leer und der Benutzer sieht nichts, unabhängig von seinen eigenen Rollen.

Eine praktische Regel: Geben Sie dem delegierenden Service Account dieselben funktionalen Rollen, die die Benutzer der Funktion haben (im Beispiel des KI-Chats die Buchhaltungsrollen). Die Schnittmenge grenzt dann jeden Benutzer auf seine eigene Teilmenge ein, was genau das Ziel ist.

Ein durchgearbeitetes Beispiel: der KI-Chat der Anwendung​

Der „eine Frage zu meinen Dokumenten stellen"-Chat der Buchhaltungsanwendung ist durchgängig auf diese Weise aufgebaut:

  1. Die App ruft die aiPrompt-Pipeline über HTTP auf und leitet das Token des angemeldeten Benutzers weiter.
  2. FromHttpRequest@2 verlangt dieses Token und steuert den Aufruf über die Buchhaltungsrollen.
  3. Der AnthropicAiQuery@1-Node läuft mit mcpDelegateToCaller: true, sodass seine Daten-Nachschlagevorgänge als der Benutzer laufen.
  4. Zwei verschiedene Benutzer, die „wie viele Dokumente kann ich sehen?" fragen, erhalten unterschiedliche, korrekte Antworten — ein Manager sieht alle Dokumente, ein Mitarbeiter sieht nur diejenigen, die ihm gehören — ganz ohne benutzerspezifische Konfiguration in der Pipeline. Der Unterschied ergibt sich vollständig aus ihren Rollen und den Datenberechtigungen des Tenants.

Verwandte Themen​