Identity and Access
Wer eine Person aus Sicht Ihres Systems ist, und was sie erreichen darf. Wir ziehen Sie zwischen Anbietern um, erweitern Keycloak und bauen das Zugriffsmodell darunter.
Identity and Access sind zwei Fragen, in dieser Reihenfolge: Wer ist diese Person, und was darf sie? Die meisten Unternehmen kaufen die erste Antwort und bauen die zweite. Was Sie kaufen, hält die Konten, die Passwörter, die Logins von Google oder aus dem Verzeichnis eines Kunden, und die Tokens, die Ihren anderen Diensten sagen, wer am anderen Ende einer Anfrage sitzt. Keycloak und Auth0 sind die beiden, nach denen wir am häufigsten gefragt werden. Keycloak betreiben Sie selbst; Auth0 mieten Sie.
Was Sie bauen, ist das Zugriffsmodell: die Regeln, wer was sehen und ändern darf. Es fängt meist als Handvoll Rollen an, geschrieben, als das Unternehmen kleiner war, und passt nicht mehr, sobald das Geschäft komplizierter wird. Der Anbieter passt irgendwann auch nicht mehr, meist aus kaufmännischen Gründen, nicht aus technischen. Beides lässt sich nicht schnell ändern, weil Sie eine laufende Nutzerbasis nicht bitten können zu warten. Das ist die Arbeit, die wir machen: der Umzug, die Erweiterung und das Zugriffsmodell darunter.
- Keycloak
- Auth0
- OIDC
- SAML
- Kubernetes
- Terraform
- Pulumi
- Datadog
Was wir machen.
Sie ziehen von Keycloak weg, oder dorthin.
Wir haben beide Richtungen gemacht, und beide gehen an derselben Stelle schief: bei den Teilen Ihres alten Setups, die niemand aufgeschrieben hat. Bevor also irgendetwas umzieht, erfassen wir, was Ihr aktueller Anbieter heute tut. Welche Token-Claims andere Dienste lesen, die eigenen Flows, die Skripte, die beim Login laufen.
Sie brauchen von Keycloak etwas, das es von Haus aus nicht kann.
Die meisten ernsthaften Keycloak-Setups sind am Ende erweitert: eigene Authenticators, Required Actions, Token Mapper, ein Storage Provider, der das System liest, in dem Ihre Nutzer schon liegen. Wir haben all das geschrieben, und wir wissen, welche davon ein Upgrade überstehen. Das zählt, denn eine Erweiterung, die in Keycloaks Innereien greift, nagelt Sie auf die Version fest, auf der Sie sind.
Ein großer Kunde will sich mit seinen eigenen Konten anmelden.
An Enterprise-Verträgen hängt eine Identitätsanforderung: SAML oder OIDC, ihr Verzeichnis, ihre Regeln. Wir richten die Föderation, das Claim-Mapping und die Kontoverknüpfung ein, und zwar so, dass es beim zehnten Kunden nur noch eine Konfigurationsänderung ist.
Ihre Rollen beschreiben nicht mehr, wer was sehen sollte.
Mehr Rollen lösen das nicht. Wir arbeiten mit Ihnen heraus, ob der Zugriff vom Nutzer abhängen sollte, von der Ressource oder von der Beziehung zwischen beiden, und schreiben das an einer Stelle auf, die Ihre Anwendung lesen kann. Wir tun das mit den Leuten, die es danach pflegen.
Wir haben die Nutzer eines Optik-Händlers von Keycloak zu Auth0 umgezogen.
Wir haben Seite an Seite mit den Entwicklern des Kunden gearbeitet. Keycloak hat auf dem Weg neun Hauptversionen durchlaufen, v15 bis v24.
- Kunde
- Optik-Einzelhandel und Omnichannel-Commerce, Deutschland
- Umfang
- Keycloak zu Auth0, 3M+ Nutzer, 30+ Microservices
- Plattform
- Keycloak auf Kubernetes, v15 bis v24
- Events
- Auth0 zu AWS EventBridge, über Lambda
- Werkzeuge
- Datadog, Pulumi, Terraform
Erzählen Sie uns, was Sie bauen.
Schreiben Sie uns oder buchen Sie ein Gespräch, wie Sie möchten. Sie hören innerhalb von zwei Werktagen von uns. Unsere Kunden sitzen in der DACH-Region und in der ganzen EU, und wir arbeiten mit allen remote.