In dieser Folge geht es um Authentifizierung,
Autorisierung, was da eigentlich der Unterschied,
berechtigungsmanagement und so weiter für Developer.
Das ist aber auch für mich persönlich eine besondere Folge.
Ich bin noch ein klein bisschen aufgeregt, denn diese Folge
stelle ich 1 meiner Nebenprojekte vor, endlich das
Licht der Welt erblickt und thematisch gut in diese Folge
passt. Viel Spaß mit dieser Folge.
Hallo und herzlich Willkommen zu einer neuen Folge des To do
Developer Podcasts mit Robin Manuel Thiel und mir.
Malte Lantine Robin Manuel, wie geht's dir heute?
Hi malte, ja mir geht's gut. Ich habe ein bisschen einen
Frosch im Hals, irgendwie durch das vermischte, regnerische und
mal sonnige Wetter. Ich hoffe, man hört es nicht so
sehr, mir geht es aber super, ich bin nämlich richtig
aufgeregt, wie gesagt kleiner so Mini Product Launch heute, bei
mir geht es aber würde ich aber sagen sprechen wir am Ende der
Folge nochmal kurz drüber. Wie geht's denn dir?
Ich bin ein bisschen allergiegeplagt, also ich weiß
nicht, ob man es so ein bisschen.
An der nasalen Stimme hört als nur ein bisschen anstrengend mit
den ganzen Gräserpollen. Aber ich hoffe, wir kommen gut
durch die Folge und lernen heute wieder was Neues.
Ich glaube, wir haben ein ganz spannendes Thema, was halt nicht
nur inhaltlich für eigentlich fast alle Developer relevant
ist, sondern auch etwas ist, mit dem du dich in den letzten
anderthalb Jahren bahnst 2 Jahre sehr intensiv beschäftigt hast.
Und da bin ich gespannt, wo ihr rausgekommen seid.
Ich meine, dein Projekt hat ja schon mal angesprochen.
Aber wir führen natürlich das Thema erstmal ein und schauen,
dass wir uns in dieser Komplexen zum einen Begriffswelt erstmal
zurechtfinden, aber natürlich auch grundsätzlich in der Art
und Weise, wie man so etwas. Aufsetzt.
Aber bevor wir ins Thema reingehen, natürlich erstmal
vielen Dank an diejenigen oder denjenigen, der uns diese Woche
Kaffee ausgegeben hat. Vielen Dank hier an der Stelle
an Jan für 3 Kaffee. Dankeschön.
Und dann können wir glaub ich auch schon direkt ins Thema
einsteigen. Und zwar sprechen wir heute über
Autorisierung, Authentifizierung,
Rechtemanagement und ich glaub wir fangen erst mal mit einer.
Begriffsdefinition an, damit wir einfach verstehen, was ist
eigentlich. Authentifizierung Was ist
Autorisierung und wie funktioniert Rechtemanagement?
Dann gehen wir jeden einzelnen Teil nochmal im Detail ein, Wer
da noch mehr erfahren will, insbesondere in den Bereich wie
ist das mit Pro Außen und Open IT connect implementiert, kann
auch noch mal in Folge 20 reinhören, gerade für
diejenigen, die noch nicht so lange dabei sind, da hatten wir
schon mal das Thema vor dem Hintergrund dieser spezifischen
Implementierung diskutiert, aber.
Erstmal allgemein die Einführung.
Was ist das eigentlich, was bedeuten diese Begriffe und wie
kann man das in seiner Anwendung einbauen?
Ja, es braucht ja eigentlich fast jede App, aber lange nicht
jeder Developer. Lange nicht alle.
Die Werber wissen eigentlich genau, wie das funktioniert und
was die Unterschiede sind und ich muss auch gestehen, so die
ersten Jahre meiner Karriere, da habe ich da immer so ein
bisschen versucht, so einen Bogen drum zu machen, weil du
hast ja gedacht, es gibt die deutschen Wörter,
Authentifizierung, Autorisierung, es gibt einen
englischen Aufenthalt, Authentication of Horizon.
Dann liest man manchmal so auf N und ORF sie also aus und dann
ein großes N oder aus und dann großes Z.
Geschrieben und ich hatte also ich hab immer, also man muss
sich ja immer irgendwie implementieren, weil in fast
alle Apps kann man sich ja irgendwie einloggen oder braucht
man den User Account, dann kommt man mit dem Thema in Berührung,
aber ich hab da am Anfang meiner Karriere immer nen sehr großen
Bogen drum gemacht und ich kann mir gut vorstellen, dass es
vielen auch so geht. Ja, zum einen ist es ja ein
komplexes Thema in der Art und Weise, wie man es implementiert,
weil es ein sicherheitskritisches Thema ist,
ist es natürlich umso wichtiger, dass man es korrekt und
fehlerfrei implementiert. Weil das natürlich ein
Einfallstor für alle möglichen Angriffe auf meine Applikation
sein können. Auch Missbrauch der Applikation
durch durch Fremde, durch andere User, die nicht entsprechende
Rechte oder gar keinen Zugriff auf die Applikation haben
sollen. Aber ich glaube auch und
zumindest bei mir war es lange so, dass einfach auch schon
diese Begriffsverwirrung so ein bisschen abschreckt, wenn man
dann überlegt, was ist eigentlich der Unterschied
zwischen Authentication und. Authorization im englischen und
ich glaube bei den deutschen Begriffen ist es vielleicht für
uns als Deutsch Muttersprachler ein bisschen einfacher zu
verstehen, wenn man sagt, Authentifikation und.
Autorisierung. Das heißt, ich kann zum einen.
Beweisen, dass ich eine bestimmte Person oder dass ich
eine bestimmte Identität habe. Und zum anderen kann nachgesehen
werden, welche Rechte ich habe, als diese Person und.
Da muss man glaub ich halt diese Zuordnung einfach einmal klar
kriegen und dann kann man sich es halt immer wieder herleiten.
Wie machst du das denn, wie hast du es geschafft da
durchzusteigen? Genau, also ich hab es, ich hab
gesagt halt Oh forization also auf n oder Authentifizierung.
Das beantwortet erstmal die Frage Wer bin ich und ich merk
mir das mit Authentifizierung authentisch.
Was ist authentisch wenn es von mir kommt oder wenn ich es bin,
so dass es so n bisschen meine Eselsbrücke, also
Authentifizierung oder auch Authentication ist erstmal die
Identifizierung meiner Person üblicherweise über sowas wie
Benutzername und Passwort, eventuell auch andere Methoden.
Es gibt ja auch mittlerweile sowas wie Parski oder sowas wie
Passwort less wo ich dann E-Mails zum Beispiel einfach nur
bekomme mit so einem einmal gültigen Link, das heißt als
developer Speicher ich mir gar nicht irgendwelche Username
Passwort Informationen ab oder nutze gar keinen Provider
sondern sag einfach ich vertraue mal, dass nur der User selber
Zugriff auf seine eigenen E-Mails hat und dem schicke ich
dann halt einfach jedes Mal einen Link, mit dem man sich
genau einmal einloggen kann, oft kommt er ja noch zu einem Thema
wie Multifaktor dazu, also weitere Faktoren wie ihn
einmalcode per SMS oder. Über so eine App, wo man Codes
generieren kann. Aber generell ist erstmal das
Konzept, ich tausche irgendwelche Sicherheitsfragen.
Kritischen Credentials, die nur ich kenne oder Daten, auf die
nur ich Zugriff habe bei. Einem vertrauenswürdigen Server
gegen einen ja so genannten Token aus.
Also irgendwas, was dann bei sich in die Hand kriege, wie
sowieso ein Einmalausweis oder wieso ein Laufzettel oder wieso
eine Wartemarke oder was auch immer, was dann nur ich bekomme
für den Austausch meiner persönlichen Informationen, die
nur ich kennen kann und dann sagt mir eben dieser
vertrauenswürdige Server okay, das ist tatsächlich der Robin
Manuel, oder er hat sich gerade wirklich der Malte angemeldet
und dann bekomme ich so einen Token und dieser Token ist oft
einfach ein json Dokument, zumindest bei diesem sehr weit
verbreiteten o ausstandard. Und heute ist es ja in der Regel
so, dass eine solche Authentication darauf aufsetzt,
dass du halt entweder 2 Dinge besitzen musst oder eine Sache
besitzen, eine Sache wissen musst ich meine klassische 2
Faktor Authentifizierung. Wir hatten halt in der
Vergangenheit einfach nur Usern im Passwort, wobei der User
nämlich geheim war und da war die.
Entsprechende Identifikation nur sehr schwach abgesichert.
Aber heutzutage ist ja häufig so, das heißt, ich muss ein
Gerät besitzen und dann bringe ich vielleicht einen
Fingerabdruck oder andere biometrische Informationen mit,
oder ich habe ein Token. Oder ich habe halt zusätzlich zu
dem Gerät, was ich als zweiten Faktor habe, habe ich vielleicht
noch ein Passwort, was nur ich kenne, das heißt, häufig
funktioniert es darüber, das heißt, ich habe einen
entsprechenden Server, der weiß was ich besitze oder welches
wissen ich mitbringe muss. Zu beweisen, wer bin ich.
Das ist also die Authentication. Genau.
Und dieser dieser Token oder dieser dieses Jason Dokument,
was ich ja vom Server bekomme. Da steht dann zum Beispiel meine
User ID drin, aber noch n paar andere Sachen.
Der hat in der Regel ne Lebensdauer, also der ist auch
gar nicht für immer gültig, sondern das kann nur wenn ich
mich anmelde krieg ich den und oft ist der so n und solchen ne
Stunde gültig oder so. Und ganz wichtig, der ist von
diesem Authentication Server, also der Server der weiß was was
mein richtiges Passwort ist. Von dem ist er signiert digital.
Das heißt, ich kann sicherstellen, dass dieses Json
Dokument auch wirklich von diesem Server und auch nur von
diesem Server ausgestellt wurde und das bietet mir den Vorteil,
dass ich jetzt mit diesem mit diesem Token in der Hand zu
meinem Backend, was ich als Developer geschrieben habe,
hingehen kann und sagen kann, hey, ich rufe jetzt hier die API
auf und schicke dir diesen Token mit, um zu beweisen, dass ich
darüber Manuel bin, der diese API aufruft, so dass du mir,
wenn ich solche sagen kann, gib mir alle Ordner auch nur meine
Ordner zurück gibst und was das Backend dann in der Regel macht.
Es geht auch noch mal. Also es nimmt sich diesen Token,
bevor das mir antwortet. Fragt das auch noch mal bei dem
gleichen Authentication Server nach.
Hey, hast du wirklich diesen Token ausgestellt und das fragt
eigentlich nicht nach, indem es ein Request schickt, sondern das
überprüft einfach diese Signatur, soll das sicherstellen
kann okay der Robin Manuel hat dieses Json Dokument jetzt nicht
einfach selber verfasst, sondern das ist signalisiert worden,
dass ist das Stand wirklich von dem Server, das kann der nur
haben weil er diesen Server einmal seine Crew Dienst zum
Beispiel User nehmen und Passwort präsentiert.
Hat. Und dann schau ich rein und wenn
das dann auch noch gültig ist, dann kann es eben weitermachen,
meine ID auslesen und alternativ bekomme ich eben sonst so n 401
un authorized Fehlercode zurück. Aber authentications erstmal nur
zu beweisen, wer bin ich. Und an sich sind diese Tokens
beziehungsweise der Inhalt dieses Dokumentes ja nicht
vertraulich. Das heißt, ich kann ja in der
Regel so ein Token, den ich irgendwie.
Bei mir vielleicht als Cookie gespeichert habe oder auf andere
Art und Weise in meinem Browser hinterlegt habe, kann ich dann
auch auslesen, kann ihn decrypten und sehe die
Informationen die da drin sind. Das heißt ich kann sehen welche
User ID welche entsprechenden. Ja, permissions sind dort auch
angefragt oder hinterlegt, aber was ich halt nicht tun kann ist
diesen Token komplett selber erstellen, weil ich halt den
Schlüssel nicht habe, den nur dieser Server hat, der
entsprechend dafür verwendet wird um diese Signatur dort
vorzunehmen. Genau, aber er ist schon
insofern vertraulich, dass ich diesen Token jemand anderem
geben darf, weil dann kann er ja in meinem Namen agieren.
Also ich sollte den schon vertraulich behandeln, aber du
hast recht, das ist aber der ist quasi transparent, ich kann da
reingucken, es gibt auch so Webseiten wie zum Beispiel J.
Io, also jwt Schiffe, json Web Token, so heißt dieser Token,
wenn es ein JSON Format hat. Da kann ich dir dann auch
einfach mal reinkopieren und dann wird er ausgelesen, dann
kann ich alle Informationen mir anschauen die da drin sind.
Genau. Und dann habe ich jetzt mein
Token. Ich gehe mit dem Token.
Zum Server hin geht zum Backend hin und Frage bestimmt die
Informationen an und dann kommen wir an den Punkt der.
Also was darf ich also mit meiner Identität?
Habe ich bestimmte Rechte, das heißt, ich darf auf bestimmte AP
is zugreifen und ich darf dort. Bestimmte Dinge mit diesem AP is
tun, basierend auf dem, was für meine Identität in diesem System
hinterlegt wurde, das heißt, ich kann nicht einfach bestimmte
Dinge. Behaupten, dass ich bestimmte
Rechte habe, sondern es wird halt immer abgeglichen, ob die
Dinge, die ich tun möchte, tatsächlich Dinge sind, die ich
auch tun darf. Genau, und das passiert
klassischerweise dann auch wieder über diesen Token.
Also deswegen ist das Thema auch so eng verheiratet auf
Storysation Authentication und bei Authorization, also auf sie
wird dann auch in diesen Token geschaut und dem steht dann
schon auch drin, also in diesem O aus Standard, wie gesagt Folge
20 haben wir das noch mal genauer aufgedröselt, aber da
steht zum Beispiel eine Audience drin, eine Audienz ist in der
Regel. Das einfach ur LS, das heißt ich
darf da steht erstmal drin gegen welche APIS, gegen welche
Backends darf ich denn mit diesem Token überhaupt hingehen?
Und da stehen auch sogenannte Scopes drin, das ist sowas wie
ja ob das grob gruppiert man im Prinzip so n bisschen die
Operation die man dann. Mit diesem taugen aufrufen darf
also als Beispiel, wenn der wenn der Scope Read Doppelpunkt
secrets ist, dann werden Developer in der Regel ihre APIS
so implementiert haben, dass ich, wenn ich diesen Read secret
scope habe, ich zum Beispiel keine Post Operations auf den
Secrets Endpunkt machen kann, sondern nur Get S und diese
Scopes, das kennt man auch so ein bisschen, wenn man sich
irgendwie mit Social Login, also mit einem Facebook oder mit
einem Google Account oder sowas irgendwo anmeldet, dann muss man
ja auch bestätigen, ob die App in dem eigenen Namen posten
darf, auf welche auf. Welche Bereiche meines Accounts
diese App mit der, an der ich mich gerade anmelde, Zugriff
hat, und das ist genau dieses technische, diese Technologie,
das sind genau diese scopes, da sage ich quasi, ja, du darfst in
meinem Namen also die App, an der ich mich gerade anmelde, die
darf in meinem Namen mit der Facebook API reden zum Beispiel,
oder mit der Google API oder womit auch immer ich mich
anmelde, aber da halt eben nur bestimmte Operationen machen und
so kann ich eben sicherstellen, dass mit diesem Token zum
Beispiel nur lesender Zugriff stattfindet und kein
schreibender Zugriff oder sowas. Es im Wesentlichen das Gleiche,
was man vielleicht auch kennt, wenn man irgendwie nen API
secret generiert oder nen Personal Access Token wo man
auch festlegt welche Operationen genau sind erlaubt.
Wenn ich dieses Secret mitbringe und vorweise und wenn ich nicht
die Rechte habe als User, dann bekomme ich halt von Backend,
wenn wir jetzt hier in http sprechen, bekomme ich ein 403
zurück, das heißt es ist verboten, ich darf bestimmte
Operationen nicht durchführen, basierend.
Auf den Rechten, die ich mit meiner Identität dort habe.
Genau und oft. Wenn ich jetzt also immer in
modernen Technologien, wenn ich so eine API programmiere, dann
kann ich da oft als Developer einfach auch schon mit so
annotations über meinen Methoden, über meine Funktionen
einfach sagen, Hey, dieses Stückchen Code oder diese
Funktion, diese Methode, die darf gar nicht aufgerufen
werden, wenn man nicht mindestens die und die
Eigenschaften im Token mit sich bringt im Authorization Bereich
und das Web Framework unten drunter, also irgendwie ASP.
Net zum Beispiel. Sorgt dann dafür, dass das eben
entsprechend richtig konfiguriert wird.
Das heißt, ich kann mir das als Developer mit modernen
Frameworks relativ simpel machen, ich muss halt einmal
aktivieren, dass ich diese Tokens nutzen möchte, muss
einmal sagen, OK, da und da findest du das Zertifikat von
dem Server, der das signiert hat und dann kann ich das, also ich
muss ja nicht jedes mal if ls statements in meinem Code
schreiben, nur wenn ich sicherstellen will, dass jemand,
der mit einem bestimmten Token kann, kommt auch nur ganz
bestimmte Operationen meiner API aufrufen kann und das muss ja
auch sehr, sehr schnell gehen, weil ich jetzt nicht jedes Mal
vom Backend abfragen kann oder abfragen will, darf der Malte
wirklich Secrets lesen, weil das ändert sich ja eigentlich nicht,
wenn du diesen Token halt einmal hast.
Und meistens ändert sich das auch über die Laufzeit dieses
Tokens ja eben nicht, deswegen kann ich dir mal einmal dann
vertrauen und muss nicht jedes Mal nachfragen, welche Rechte
hat denn der malte um zu wissen ob du überhaupt wie in unserem
Beispiel jetzt hier Secrets auslesen kannst?
Das heißt, ich habe dann entsprechend auf einen eine API
oder eine bestimmte Funktion. Habe ich entsprechende Rechte
zum Beispiel. Ich darf bestimmte Dokumente
nicht nur lesen. Abrufen.
Was machen wir denn jetzt, wenn du 2 Dokumente lesend abrufen
darfst? Aber halt nur deine Dokumente
und nicht alle Dokumente von allen Usern?
Das können wir ja dann auf diese Art und Weise noch nicht korrekt
hinterlegen. Genau da wird es dann knackig.
Also wenn man ne wenn du sagst, ich kann gar nicht generell
sagen ob du schreiben oder lesen darfst, sondern vielleicht hast
du auf manchen Dokumenten ja leserechte, auf anderen
Dokumenten schreib und Leserechte und auf wieder andere
Dokumenten gar keine Rechte, weil vielleicht, und das ist so
der das klassische. Beispiel weil du ja vielleicht
weißt, vielleicht gar nicht nur um deine Dokumente geht, sondern
vielleicht hab ich da ja auch n Dokument geteilt oder ich hab
dir was freigegeben, aber nur lesen und sowas heißt ich kann
das gar nicht nur über die User ID mappen oder sowas und da
haben wir eigentlich dann auch schon die Grenze erreicht von
Authentication und Authentization, vor allem von
Authorisation Mal mit Authentication hat es eigentlich
nichts mehr zu tun und da kommt dann eigentlich sowas wie wenn
das Fine Grained Access Control Fga oder halt nicht, das hat man
vielleicht öfter schon mal gehört so role Based Access
Control Areback ins Spiel. Denn damit bestimme ich dann
jetzt wirklich. Je nachdem, welche Rolle du hast
oder welche rechte du auf irgendwelche ganz bestimmten
Ressourcen bekommen hast, kann ich noch mal überprüfen.
Das heißt, ich überprüfe gar nicht mehr oder ich prüfe das
vielleicht zusätzlich noch, aber nicht hauptsächlich nur noch auf
welche API Endpunkte darfst du zugreifen, da stelle ich einmal
sicher, darfst du überhaupt Dokumente bearbeiten und dann
muss ich aber nochmal prüfen, darfst du denn dieses eine
Dokument was du jetzt gerade in der Hand hast bearbeiten?
Und da wie gesagt, das das kann ich auch gar nicht mehr alles in
den Token reinschreiben, weil nehmen wir jetzt mal irgendwie
Beispiel Dropbox, wenn ich jetzt alle Ressourcen in diesen Token
schreibe, auf die ich theoretisch Zugriff hab, das
können ja tausende sein, es würde diesen Token wahnsinnig
aufblähen und ich schicke den ja bei jedem Request mit, das würde
da gar keinen Sinn ergeben. Und deswegen kommt man dann,
wenn man diese Anforderungen hat, in dem Bereich Fine Grant,
Access Control oder Role Based Access Control rein.
Ich meine role based Access Control hat den großen Vorteil,
dass ja bestimmte Dinge über verschiedene User hinweg
basierend auf der Rolle als Role, die sehen.
Rahmen dieser Applikation haben, identisch sind.
Das heißt, ich kann dann einmal für diese Rolle bestimmte Rechte
vergeben und kann dann diese Rolle.
Vielen Usern zuweisen wir kennen es zum Beispiel auch aus
irgendwelchen Cloud Plattformen, wo man einzelnen Usern
bestimmte. Rechte Level zuweisen möchte, um
zu sagen, OK, bestimmte User dürfen nur Ressourcen einsehen,
andere User dürfen Ressourcen auch verwalten, andere dürfen
wiederum im vollen Zuge auch Ressourcen löschen und das ist
ja etwas, was ich dann immer auf eine größere Gruppe anwende.
Das heißt, immer wenn es diese Gemeinsamkeiten gibt, bieten
natürlich Rollen einen großen Vorteil, um das zu vereinfachen,
wenn es natürlich für jeden User individuell ist, dann muss ich
natürlich für jeden User individuell diese Rollen
vergeben und dann? Macht es gar nicht mehr so viel
Sinn, irgendwie erstmal standardrollen zu definieren,
sondern tatsächlich diesen Access an jeden User
entsprechend anzuhängen. Und auch die Rollen kann ich
auch vor verschiedenen Leveln zuweisen.
Ich kann ja die Rolle geben, wenn man mit diesem Cloud
ressourcenkontext bleiben kann, kannst du ja die Rolle haben,
ich darf ein kobanites Cluster updaten, das heißt ja, aber das
heißt, du kriegst die Kubanitus maintenor Rolle, die unter
anderem das Recht ein Cluster zu updaten beinhaltet, aber die
kriegst du ja auch Gescope zu zugewiesen, das heißt du kannst
ja nicht alle kommunistischen Cluster in der gesamten Cloud
updaten, sondern du kriegst dann diese Rolle, die.
Einfach ja eigentlich nur so Rechte bündelt und
zusammenfasst, weil sie einfach was als einfach ein
wiederkehrender Use Case ist. Jemandem diese Rechte zu geben,
die kriegst du ja auch zugewiesen auf entweder ein
bestimmtes Cluster oder auf eine bestimmte Gruppe.
Von Ressourcen, in denen dann vielleicht sogar mehrere Cluster
sind. Das heißt, da kommt man dann in
das Thema rein, dass sich die Rechte eventuell auch vererben
können. Ne, wenn man bei diesem Dropbox
Beispiel bleibt, kann ich ja sagen, du hast gar nicht, ich
hab dir gar nicht explizit leserechte auf dieses eine
Dokument gegeben. Also sonst würde ich ja
vielleicht sogar meiner Datenbank auch mit jedem
Dokument einfach abspeichern. Wer darf da lesen und wer darf
da schreiben, sondern vielleicht hast du ja auch einfach.
Ein Leserecht auf den Überordner bekommen und in meinem System,
was ich jetzt als developer baue, impliziert das ja
vielleicht, dass du natürlich dadurch auch Leserechte für alle
Dokumente, die in die sich in diesem Ordner befinden,
bekommst. Und vielleicht will ich ja nur
auf ein ganz bestimmtes Dokument in dem Ordner dann auch
Schreibrechte geben oder so. Also du merkst schon, das kann,
das, kann auch schnell sehr hierarchisch werden.
Und das kann auch schnell sehr komplex werden, weil es wie
gesagt noch nicht immer explizit ist.
Und das kann es ja sein, dass ich jetzt einen Ordner nehme, wo
Dokumente drin sind und den verschiebe ich jetzt in den
anderen Ordner, wo noch jemand anderes auf diesen Ordner, auf
diesen anderen Ordner Zugriff hat.
Also kann das relativ komplex werden und das braucht auch gar
nicht jede App. Also wenn ich jetzt irgendwas
baue, wo ich systemweit entweder normaler User oder Admin bin,
dann reicht mir klassischer Autorisierung völlig aus.
Also ich will es auch keinem Angst machen, das braucht man
halt nur sobald man. Rechte abhängig von der
Ressource, vergibt also quasi nicht mehr beantwortet.
Was darf ich, sondern auf welchen Ressourcen in meinem
System hat der User denn welche Rechte?
Und. Wenn ich dann auf ne Ressource
zugreife, dann wird halt geprüft, welche Rechte habe ich
da drauf, entweder über die Rollen die ich habe oder welche
Rollen oder welche Rechte mir als User zustehen und dann
bekomme ich entweder den Zugriff oder bekomme halt entsprechend
auch wieder Forbitten zurück, aber das ist jetzt nicht mehr
davon abhängig welche Operation ich durchführe, sondern ob ich
spezifisch auf einer bestimmten Ressource die Rechte, die ich
dort wahrnehmen möchte, auch bekommen.
Das heißt, wir gehen hier wirklich noch mal ein Level
tiefer. Ich persönlich habe noch nicht
an einer Applikation gearbeitet, wo man das zwingend brauchte,
weil bisher die Szenarien, an denen ich gearbeitet hatte,
durch. Wie du gerade gesagt hast, es
gab bestimmte. Privilegierte User, die hatten
halt Zugriff auf alles und es gab andere User, die hatten halt
als. Anwender bestimmte
Möglichkeiten, aber die waren halt entsprechend für alle
gleich. Aber sobald ich halt.
Zum Beispiel Nutzergenerierten Content habe, wenn ich Leuten
erlaube, bestimmte Ressourcen hinzuzufügen.
Wir kennen es halt aus dem Filesharing Beispiel, aber halt.
Auf jeder Social Media Plattform kann ich Inhalte teilen.
Ich kann auch Inhalte mit bestimmten Personen teilen, dann
kommt halt wieder das gleiche Thema zum Tragen, insbesondere
wenn ich dort über Gruppen das Ganze aufbauen kann.
Also durchaus viele Szenarien wo ich das brauche und da ist es
natürlich immer wieder. Die Frage, wie implementier ich
das, gehe ich jetzt selber hin und bau das oder kann ich das
ganze auch? Ja, out of the Box verwenden und
da gibt es natürlich wieder diverse Lösungen.
Kommen wir gleich noch mal drauf, aber vielleicht sagst du
noch mal ganz kurz, wie bist du halt zu diesem Punkt gekommen,
wo du gesagt hast, wir müssen das jetzt selber implementieren,
was für eine Art von Anwendung war das?
Genau. Also ich glaube, du hast gerade
das Bericht gesagt. Oft habe ich diese globalen
Rollen, aber sobald ich zum Beispiel in das Thema Multi
tendency komme oder sobald ich in das Thema komme, dass User
voreinander oder sich gegenseitig Dinge freigeben,
dann brauche ich das. Ich habe, ich habe für einen
Kunden eine Digital Asset Management Lösung mit einem Team
zusammen implementiert oder habe da unterstützt und beraten.
Und da also das ist ein Produkt was ich an professionelle
Fotografen richtet, wo man also Snatch heißt, das kann man mit
seiner Kamera dann auch irgendwie bei FTP verbinden und
live auf Events zum Beispiel Fotos machen und die Teilen und
dann an Presse weiterschicken und so und die brauchten das,
die hatten natürlich verschiedene Tendenz und die
wussten, die müssten ganz fein definiert.
Was gibt es denn eigentlich für Rechte?
Was darf ich denn mit so einem Bild machen, darf ich das nur
sehen, darf ich das bearbeiten, darf ich da vielleicht nur die
Metadaten bearbeiten, darf ich das löschen, darf ich das
runterladen und so weiter. Und dafür brauchten brauchten
wir ein solches System und kamen dann auch irgendwann durch diese
Erfahrung, dass wir sowas dann schon mal gebaut haben.
Und vor allem auch multit Anwendung bauen konnten.
Immer wieder, gerade so im SARS Context an diesen Punkt wo ich
sagte, ich möchte eigentlich viel feiner wissen, was der User
für Rechte hat und ich möchte in meinem Backend als Developer
dann indem wo ich die Operation über Authorization zugelassen
habe, dann da drin noch mal fragen darf, denn dieser also
hat denn dieser User auch auf dieser Ressource das Recht und
als Developer interessiert mich da auch gar nicht mehr wie der
an das Recht gekommen ist durch eine Rollenzuweisung oder wie
auch immer, sondern ich kann als Developer, das ist für mich das
relativ simpel als Developer, wenn das einmal implementiert
ist, dann sage ich nämlich Pass auf.
Liebesberechtigungs oder liebes Fine Grained Access Control
System, sag mir doch einfach mal Bescheid.
Hat der User da gerade angemeldet, ist auf dem Ordner
bla bla bla das recht editieren und wenn ja dann geht es weiter
wenn nein Fehlermeldung. Aber wenn du das so beschreibst,
würde ich erwarten, dass es da genauso wie es zum Thema
Identity Management und Logins diverse Lösungen am Markt gibt,
weil ich würde ja heutzutage. Außer ich bin vielleicht in
einem sehr spezifischen Kundenszenario unterwegs, würd
ich ja das ganze, gerade was halt Applikationen für
Endanwender betrifft, das ganze Thema Identity Management kaum
komplett selber implementieren. Ich würde einen der großen
Identity Provider entweder aus dem B 2 B Bereich oder aus dem B
2 C Bereich verwenden, es wird irgendwie ein Social Login
verwenden oder ich würde irgendwie ein Login per Google
oder Microsoft Account oder so ähnliche Szenarien verwenden um
das ganze Thema. Authentifizierung und
Autorisierung auf Basis dieser Identity Provider umzusetzen.
Und genauso würde ich erwarten, dass es das gleiche halt auch
für das Thema Permission Management gibt und das nicht
jeder immer wieder neu erfinden muss.
Ja, aber deutlich weniger also. Genau wie bei so einem.
Genau wie man Login nicht selber baut.
Ich glaube das weiß mittlerweile jeder, dass man so mit
Passwörtern und so, wenn man eh nicht so viel am Hut haben und
es ist einfach schneller aus sich diese das fertige Lösung
einzukaufen, sondern bei Login nimmt man ja auch einfach sowas
wie du hast ja gerade schon gesagt, kann man auch Zero zum
Beispiel Octa und sowas, das sind da glaube ich sehr populäre
Vertreter. Aber wir haben ja gerade eben
auch schon gehört, dieses ganze Thema Fine Green Access Control,
das Decken die oft nicht ab, sondern die machen oft dieses
klassische Authentication und Authentization und für Fine
Graine Access Control gibt es auf dem Markt gar nicht so viel.
Ich sage, es gibt nicht nichts, aber es gibt da gar nicht so
wahnsinnig viel und das Thema ist auch so komplex, dass ich
zumindest nicht empfehlen würde, das selber zu bauen, wir haben
das selber gebaut und da haben wir das nochmal selber gebaut
und wir haben das insgesamt fünfmal gebaut bis wir und
darauf von viermal falsch gemacht, bis wir an einem Punkt
haben, wo wir sagen okay, jetzt funktioniert es, glaube ich,
weil es gibt immer irgendwas, was man nicht beachtet, oder es
ist super in performant, weil man bei jeder Änderung diesen
kompletten Permissionsbaum. Neu berechnet und es ist sogar
so komplex, dass Google ein ein Research Paper dazu geschrieben
hat. Das nennt sich das Google
Sansibar Paper Werder mal zu suchen will wo sie gesagt haben
wie sie das also was auf was für Herausforderungen sie dabei
gestoßen sind, ein globales Berechtigungssystem für für
Youtube, für Google Fotos, für Google Drive und so weiter zu
bauen. Sie verraten leider nicht wie
sie es gemacht haben, aber Sie sagen diesem Research paypal was
die was das so komplex macht und was die Dinge sind auf die man
alle achten muss und das ist wieder mehrere Seiten lang.
Und führt einen noch mal so n bisschen dadurch und hat uns
dann auch letztendlich geholfen, als wir zum fünften Mal
implementiert haben, das Ding richtig zu bauen.
Und deswegen Trommelwirbel. Haben wir einen genau solchen
Permissions as a Service Provider gebaut und der launcht
heute auf Product Hand und der nennt sich Spaceblocks und das
ist quasi eine, das ist eigentlich mein allererstes
richtiges kommerzielles Sideprojekt, also ein Tool für
Developer, was jetzt das Licht der Welt heute erblickt hat.
Zumindest das heute aus dieser Preview Phase und sowas
rausgegangen ist mit einem offiziellen Lounge auf Product
Hand. Und genau das haben wir gebaut,
eben quasi ein Permissions as a Service, ein Cloud Modell was?
Finegraint Access Control oder Roll based access Control macht.
Heißt, ich brauch jetzt viele Dinge nicht mehr selber machen.
Ich bekomm von euch nen SDK, ich bekomm von euch ne Cloudservice
der die ganzen Checks im Hintergrund vornimmt und kann
dann das in meine Anwendung implementieren.
Wie funktioniert es? Ich hab selber noch nicht in
einer Anwendung eingebaut, ganz kurz auf dem hohen
Abstraktionsniveau erklären, wie ich vorgehe, wenn ich spacebox
einsetzen möchte. Also erstmal, das müssen wir
nach der Podcast Folge mal ändern.
Das also ich würd da super gern dein Feedback haben, dass du da
deine Finger mal dran kriegst und mir mal sagst generell wie
du die Developer Experience. Grob gesagt funktioniert das so.
Wir haben so einen Low Coat Designer, einen Editor in
unserem Cloud Portal, da definiert man einmal die
Ressourcenstruktur, also wenn sie vorhanden sind und die
Relationen zueinander, das muss nicht in jeder App sein.
Wie gesagt, wir können auch Apps machen, die einfach eine flache
Hierarchie haben, aber manchmal hat man ja so Dateien in Ordnern
und Ordnern, Unterordner und so weiter.
Und dann definiert man einmal in diesem, in diesem Designer dann,
welche Rechte gibt es denn, auf welche Typen von Ressource?
Also vielleicht habe ich ja auf einem Ordner das Recht,
vielleicht habe ich auf einer Datei das Recht downloaden, aber
auf einem Ordner gibt es das gar nicht.
Also ich muss schon für jeden, für jede Ressourcen type
festlegen, was gibt es denn da eigentlich für Rechte und?
Ich kann auch schon vordefinierte Rollen wie zum
Beispiel die Administratorrolle oder sowas, die es immer geben
soll, in diesem Editor anlegen und das mache ich in der Regel
aber einmal oder nur wenn ich irgendwie neue Ressourcentypen
einfüge, dann ändere ich das. Und was dann fortlaufend
eigentlich passiert ist. Man registriert bei uns über ne
API. Wir haben natürlich auch
Esticase für die gängigen Sprachen, dann einfach die
Ressourcen, die man selber im System hat und teilt uns
Änderungen mit, wenn es wenn es euch jemand ne Rolle zugewiesen
oder aberkannt bekommen hat und aufgrund dieser Änderungen
können wir dann im Hintergrund die Auswirkungen von diesen
Changes berechnen und wie gesagt, das ist relativ komplex
und man muss das ja auch sehr performant machen, weil ich das
ja quasi bei jedem oder bei jedem wichtigeren Request ja
einmal abfragen muss. Das heißt, das muss auch
irgendwie schnell sein und dann als Developer, wenn man einmal
eingebaut hat, sobald User eine Datei hochlädt, registriert man
das einmal ganz kurz bei uns sagt Hey, es gibt jetzt die
Datei mit der id 15 ba, ba, BA muss man einmal nur ganz kurz
registrieren und dann redet das Backend was uns verwendet, also
was hier diese Permission Checks macht über unsere API, über
unsere St KS mit einer einzigen Zeile Code eigentlich in diesen
API Calls mit uns, das heißt wir haben verschiedene Operationen,
zum Beispiel checke ob der User. Malte auf dem Ordner Podcast,
dass die Berechtigung lesen hat. Das ist ja ne einfach ein ein
Aufruf. Du kriegst zurück bei uns n true
oder n false. Du kannst aber auch sagen, gib
mir alle Rechte, die der Malte auf dem Ordner Podcast hat, weil
vielleicht will ich dir ja die Rechte irgendwo anzeigen oder
ich kann sagen gib mir alle User die 1 oder mehrere der folgenden
Rechte auf dem Honor Podcast haben.
Das kann spannend sein, wenn ich zum Beispiel in der Ui so kleine
Gesichter so Bubbles anzeigen möchte, wer da alles Zugriff
darauf hat oder mit wem ich irgendwas teile, das kennt man
ja auch so ein bisschen irgendwie aus Anwendungen wie
Dropbox oder onedrive oder irgendwelchen live Anwendungen
und ich kann sagen gib mir alle Ordner egal.
Von egal wo im System, auf die der Malte mindestens lesezugriff
hat. Also ich kann mir auch einfach
nur die Ressourcen aufrichten und auflisten lassen und nicht
die Rechte, das brauche ich zum Beispiel für einen Suchfilter.
Also wenn ich jetzt eine Suche betätige und du suchst über alle
Dateien, dann will ich dir natürlich nur Ergebnisse
anzeigen von Dateien auf die du auch Rechte hast bzw nur die bei
der Suche berücksichtigen oder wenn man das Thema RAG hatten
wir auch ein paar folgen mal wenn wir mit AI sprechen und
eigene Daten in die AI Reihe füttern wollen, da wollen wir
natürlich live wissen. K ich kann welche.
Welche Dokumente hat der malte denn überhaupt Zugriff drauf,
damit ich doch nur die natürlich in den prompt mit Reinfütter und
das haben wir hier gebaut und das kannst du und das könnt ihr
euch alle auch super gern mal anschauen auf www.spaceblogs
Cloud wir haben einen kostenlosen developer Tier, der
ist auch für immer kostenlos, also nicht so 30 Tage
Testversion sondern wenn man das einfach mal einbauen will kann
ich das gerne mal anschauen und. Also dir würde ich super gerne
mal die Tage zeigen und dein Feedback einholen und natürlich
auch der Aufruf an euch alle, wenn ihr für euch das Thema
generell spannend ist, schaut. Es euch natürlich gerne an AB.
Schreibt mir auch gerne mal eine E-Mail einfach unten an die to
do cast Adresse unten und wenn ihr möchtet können wir da auch
gern mal irgendwie so einen kleinen 15 Minuten democall
machen und Podcast Hörerinnen und Hörer bekommen natürlich
auch einen fetten Voucher für unsere produktiv subscription
dann später, also wenn da vielleicht durch den Podcast
jetzt tatsächlich irgendjemand jemand Kunde werden möchte, dann
lasst uns da gerne nochmal quatschen da.
Da überlege ich mir was. Wenn das mal nicht ein Deal ist,
hab das ja jetzt über die letzten, ja ich sag mal 1218
Monate so n bisschen am Rande verfolgt.
Ihr habt n bisschen gesehen welchen Fortschritt ihr da macht
mit der Website und jetzt tatsächlich den Launch zu sehen
sehr aufregend. Ich bin gespannt wie das Ganze
jetzt wirklich in Produktion live aussieht, da freue ich mich
darauf die Demo und die ersten Hands on Erfahrungen damit und
ja wenn ihr Feedback habt, nicht nur zu dieser Folge, sondern
speziell auch zu spaceblogs schreibt gerne eine Mail.
Einfach an die übliche Podcast E-Mail Adresse, die in den
Shownotes findet. Oder ihr findet natürlich auch
die Kontaktadresse speziell zu Spaceblogs auf der Webseite.
Magst du nochmal die URL durchgeben, die habe ich gerade.
Jawohl, das sind www.spaceblogs zusammengeschrieben.
Cloud ist aber wie gesagt auch noch mal in der Beschreibung vom
Podcast und eine Sache noch ganz wichtig letzte Sache.
Aber war das mir viel bedeuten wurde?
Ich hab es letzte Folge ja schon angekündigt, heute launchen wir
auf Product Hand, das ist ne Plattform wo sich Leute
gegenseitig coole Tools zeigen und da geht quasi 24 Stunden
lang so n counter hoch wieviel wieviel upvotes und wieviel
Likes ein Produkt bekommen hat und es würde mir die Welt
bedeuten, wenn ihr euch die Zeit nehmen würdet, heute vielleicht
kurz auf Product Hand zu gehen, auch da ist der Link natürlich
unten in den in den Notes von dieser Podcast Folge und uns da
vielleicht kurz ein upvoten Like einen kleinen Kommentar
irgendwas dazulassen kann man sich natürlich auch so ein
bisschen nochmal genauer ins Produkt.
Reinfuchsen. Wir haben auch eine 5 Minuten
Demo Video aufgezeichnet, aber wieder da ist heute dieser
Lounge, da zählen jetzt einfach die ersten 24 Stunden.
Also bitte bitte voten kommentieren und ich verspreche
auch, dass wir nicht jede jede Podcast Folge ist eine
Werbefolge machen, aber heute würde wir das einfach wahnsinnig
viel bedeuten. Und wenn euch diese
Dauerwerbesendung gefallen hat, dann lasst uns gerne auf den
üblichen Podcast Plattformen eine positive Bewertung da und.
Wir freuen uns natürlich auch immer wieder, wenn uns jemand
von euch einen Kaffee ausgibt. Das bedeutet uns extrem viel.
Alle Details zu dem Thema Authentifizierung, Autorisierung
findet ihr auch entsprechend über die Links in den Shownotes
dieser Episode und natürlich die Hinweise, wie ihr Spaceblogs
findet, wie ihr beim Product Launch Hand unterstützen könnt.
Ich hoffe, das war jetzt wirklich nicht nur Werbung für
euch, sondern ihr habt mir war wichtig, dass wir heute das
ganze Thema einmal beleuchten. Deswegen hoffe ich.
Alle ein bisschen was mitnehmen oder lernen können und wie
gesagt, versprochen, wir machen jetzt hier keinen Werbe Podcast
draus, aber das war jetzt ein privates Anliegen.
Vielen Lieben Dank fürs Zuhören. Danke dir und ich würde sagen,
dann hören wir uns hoffentlich in 2 Wochen wieder.
Der to do Libet Oper Podcast erscheint alle 2 Wochen am
Montag. Wir freuen uns auf alle, die
regelmäßig dabei sind. Bis dahin habt eine gute Zeit
und schreibt ganz viel Code. Bis dann.