Identity für Menschen und Agenten
Ihr Produkt muss wissen, wer da anfragt und was er darf, egal ob Kunde, Dienst oder Agent. Wir bauen diese Schicht mit Ihnen und betreiben sie im laufenden Produkt.
Identity and Access sind zwei Fragen, in dieser Reihenfolge: Wer ist diese Person, und was darf sie? Die erste Antwort kaufen die meisten Unternehmen, die zweite bauen sie. Das Gekaufte hält die Konten und Passwörter. Es hält die Logins von Google oder aus dem Verzeichnis eines Kunden. Und es stellt die Tokens aus, die Ihren anderen Diensten sagen, wer da gerade anfragt. Keycloak und Auth0 sind die beiden, nach denen wir am häufigsten gefragt werden. Keycloak betreiben Sie selbst, Auth0 mieten Sie.
Das Gebaute ist das Zugriffsmodell: die Regeln, wer was sehen und ändern darf. Meist fängt es als Handvoll Rollen an, geschrieben, als das Unternehmen kleiner war. Wird das Geschäft komplizierter, passt es nicht mehr. Der Anbieter passt irgendwann auch nicht mehr, meist aus kaufmännischen Gründen, selten aus technischen. Beides lässt sich nicht schnell ändern, denn Ihre Nutzer können nicht so lange warten. Genau das ist unsere Arbeit: der Login und das Single Sign-on, das Zugriffsmodell darunter, und die Änderung, wenn eines davon nicht mehr passt.
Dieselben zwei Fragen stellen sich jetzt auch bei Agenten. Und bei jedem anderen Programm, das mit Ihren Daten arbeitet: ein MCP-Server, ein Dienst, der Ihre API aufruft. Wir geben jedem davon eine eigene Identität bei Ihrem Provider. Oder wir lassen es für einen Nutzer handeln, mit Rechten nur für diese Aufgabe. Sein Token nennt die Tools oder APIs, die es aufrufen darf, und sonst nichts. Wir protokollieren jeden Aufruf unter dieser Identität. So können Sie hinterher zeigen, was der Agent getan hat und was er durfte. Ohne das hat ein Agent am Ende mehr Rechte als die Person, die ihn beauftragt hat.
- Keycloak
- Auth0
- OIDC
- OAuth
- SAML
- JWT
- Kubernetes
- Docker
- AWS
- Terraform
- Pulumi
- Datadog
Ihre Situation, unsere Antwort
Sie bauen ein Produkt und wollen den Login von Anfang an richtig.
Wir richten den Identity Provider ein, selbst betrieben oder gemietet, und die Wege zum Login: Passwort, Google oder das Verzeichnis eines Kunden. Wir klären mit Ihnen, was Ihre anderen Dienste über einen Nutzer wissen müssen, und schreiben das in den Token. Und wir schreiben das erste Zugriffsmodell mit Ihnen, damit es zum Geschäft passt und nicht nur zum ersten Release.
Ein großer Kunde will sich mit seinen eigenen Konten anmelden.
Enterprise-Verträge bringen eine Anforderung an die Identität mit: SAML oder OIDC, das Verzeichnis des Kunden, seine Regeln. Wir richten Federation, Claim-Mapping und Account-Linking ein. Und zwar so, dass der zehnte Kunde nur noch eine Konfigurationsänderung ist.
Ihre Rollen sagen nicht mehr, wer was sehen darf.
Mehr Rollen lösen das nicht. Wir klären mit Ihnen, wovon der Zugriff abhängen soll: vom Nutzer, von der Ressource oder von der Beziehung zwischen beiden. Das schreiben wir an eine Stelle, die Ihre Anwendung lesen kann. Und wir tun es mit den Leuten, die es danach pflegen.
Sie brauchen von Keycloak etwas, das es von Haus aus nicht kann.
Fast jedes ernsthafte Keycloak-Setup ist am Ende erweitert: eigene Authenticators, Required Actions, Token Mapper, ein Storage Provider für das System, in dem Ihre Nutzer schon liegen. Wir haben all das geschrieben, und wir wissen, was davon ein Upgrade übersteht. Das ist wichtig. Eine Erweiterung, die tief in Keycloak hineingreift, nagelt Sie auf Ihre jetzige Version fest.
Sie ziehen von Keycloak weg, oder dorthin.
Wir haben beide Richtungen gemacht. Beide gehen an derselben Stelle schief: bei den Teilen Ihres alten Setups, die niemand aufgeschrieben hat. Bevor also irgendetwas umzieht, schreiben wir auf, was Ihr heutiger Anbieter alles tut. Welche Token-Claims andere Dienste lesen, welche eigenen Flows es gibt, welche Skripte beim Login laufen.
Sie wollen einem Agenten Zugriff auf Kundendaten geben, und Sie können nicht sagen, was er darf.
Wir geben dem Agenten eine eigene Identität. Oder wir lassen ihn für den Nutzer handeln, der ihn beauftragt hat, mit Rechten nur für diese Aufgabe. Sein Token nennt die Tools und APIs, die er aufrufen darf, und sonst nichts. Wir protokollieren jeden Aufruf unter dieser Identität. Fragt hinterher jemand, was der Agent getan hat und was er durfte, können Sie beides zeigen.
Erzählen Sie uns, was Sie bauen.
Unsere Kunden sitzen in der DACH-Region und in der EU. Mit allen arbeiten wir remote.