Die architektonische Trennung, die zählt
Der externe Agent kann überall leben: in Ihrer Cloud, im Kundennetz oder in einer Partner-Laufzeit. ADI muss ihn nicht selbst ausführen, um ihn zu regieren.
Das Zielsystem hat zwei getrennte Aufgaben. Erstens muss es den Aufrufer technisch authentisieren. Zweitens muss es ADI fragen, ob dieser authentisierte Agent für diesen Eigentümer, in diesem Scope und auf diesem Trust-Level handeln darf.
Authentisierung beantwortet: Ist diese Anfrage technisch echt?
ADI-Trust beantwortet: Wer ist dieser Agent, für wen darf er handeln und was ist derzeit erlaubt?
Modus 1: Agent-Token oder API-Key plus Trust-Lookup
Das ist das direkteste Muster für interne Systeme oder schnelle Enterprise-Integrationen. Der externe Agent authentisiert sich mit Agent-Token oder API-Key, und das Zielsystem fragt unmittelbar ADI nach dem Live-Trust-Zustand, bevor die Aktion ausgeführt wird.
Geeignet für interne Eigentümer-Systeme und private Tools
Keine OIDC-Föderation erforderlich
ADI bleibt die Quelle für Berechtigungen, Limits und Widerruf
Ablauf im Standardmodus
Das Zielsystem vertraut der eigenen Laufzeitauthentisierung und fragt dann ADI nach Bindung, Policy und Zertifikatszustand.
sequenceDiagram
participant A as Externer Agent
participant S as Internes Zielsystem
participant T as ADI Trust Layer
A->>S: Anfrage + Agent-Token oder API-Key
S->>T: Trust-Profil und Verifikationsstatus lesen
T-->>S: Identität, Ownership, Delegation, Zertifikatsstatus
alt Policy erlaubt Aktion
S-->>A: Zugriff gewährt
else Policy blockiert Aktion
S-->>A: Zugriff verweigert
end Modus 2: OIDC plus Trust-Lookup
Einige Enterprise-Systeme verlangen bereits OIDC am Gateway oder an der Applikationsgrenze. In diesem Fall kann ADI einen normalen Keycloak Confidential Client für den Agenten bereitstellen, der Agent holt sich ein client_credentials-Token und die Gegenstelle validiert es über Discovery und JWKS.
OIDC ersetzt ADI trotzdem nicht. Es deckt die Transportauthentisierung ab, während ADI weiterhin Delegation, Ownership, Zertifikatszustand und Widerruf liefert.
Geeignet für Enterprise-IAM-Landschaften
Nutzen von OIDC-Discovery, JWKS und OAuth2 client_credentials
ADI bleibt Pflicht für Delegations- und Autoritätsprüfungen
Ablauf im Enterprise-Modus
OIDC validiert das Access-Token, aber die finale Autorisierungsentscheidung hängt weiterhin vom ADI-Trust-Lookup ab.
sequenceDiagram
participant A as Externer Agent
participant I as ADI Keycloak oder Enterprise-Gateway
participant S as Enterprise-System
participant T as ADI Trust Layer
A->>I: client_credentials-Token anfordern
I-->>A: Access Token
A->>S: Anfrage + OIDC-Token
S->>S: Token lokal oder am Gateway validieren
S->>T: Agenten-Trust und Delegation auflösen
T-->>S: Trust-Entscheidung
S-->>A: Zugriff gewährt oder verweigert Modus 3: Signiertes Delegations-Credential plus Trust-Lookup
Für besonders sensible Aktionen wie wertige Käufe, Zahlungsfreigaben oder regulierte Delegationen kann der Agent ein signiertes Delegations-Credential oder ein signiertes Request-Envelope vorlegen. Die Gegenstelle validiert die Signatur und prüft danach Bindung, Zertifikatszustand und Delegation bei ADI.
Geeignet für regulierte oder hochpreisige Aktionen
Braucht Signaturvalidierung auf Seiten der Gegenstelle
Wird besonders stark mit Human-Identifizierung und AdES/QES
Ablauf im High-Trust-Modus
Der kryptografische Nachweis stärkt die Anfrage, aber ADI liefert weiterhin Live-Status, Widerruf und Delegationswahrheit.
sequenceDiagram
participant A as Externer Agent
participant S as Zielsystem
participant T as ADI Trust Layer
A->>S: Signierte Anfrage + Delegations-Credential
S->>S: Signatur oder Credential-Envelope prüfen
S->>T: Zertifikatsbindung, Delegation und Widerruf prüfen
T-->>S: Trust-Ergebnis
alt Trust und Policy gültig
S-->>A: Aktion ausgeführt
else Trust ungültig oder widerrufen
S-->>A: Aktion verweigert
end Wie man auswählt, ohne zu überengineeren
Die meisten Teams sollten mit dem Standardmodus beginnen und nur dann nach oben gehen, wenn die Gegenstelle oder der Compliance-Kontext es wirklich verlangen. Der Fehler ist nicht, einfach zu starten. Der Fehler ist, Authentisierung und Trust in einen unscharfen Mechanismus zu pressen.
Standard zuerst für Tempo und Kontrolle
OIDC, wenn die Enterprise-Infrastruktur es ohnehin erwartet
Signierte Delegation, wenn die Aktion selbst stärkere Beweise braucht
Entscheidungslandkarte
Beginnen Sie mit dem einfachsten Modus, der Zielsystem und Haftungsniveau der Aktion abdeckt.
flowchart TD
start["Externer Agent will handeln"] --> q1["Verlangt das Zielsystem bereits OIDC?"]
q1 -->|Nein| standard["Agent-Token oder API-Key + ADI-Trust-Lookup"]
q1 -->|Ja| oidc["OIDC + ADI-Trust-Lookup"]
standard --> q2["Ist kryptografische Nichtabstreitbarkeit nötig?"]
oidc --> q2
q2 -->|Nein| done["Live-Trust-Entscheidung von ADI reicht"]
q2 -->|Ja| signed["Signiertes Delegations-Credential + ADI-Trust-Lookup"]