Moin liebe Zuhörerinnen und Hallo und herzlich willkommen zu
Folge 64 von Einfachkomplex heute wieder in der gewohnten
Konstellation. Ich lass mir ein bisschen die
Welt erklären der Software und Burkhard wird seinem Ruf als
Experte gerecht. Schauen wir mal.
Moin, hier aus Hamburg. Schauen wir mal.
Und es ist ja noch immer Sommerpause und wir haben uns
jetzt trotzdem ein Thema rausgesucht, was gar nicht so
super einfach ist, aber extrem spannend und für viele aus
Entwicklerperspektive wie auch aus Nutzerperspektive ein Thema
ist, mit dem man oft in Kontakt kommt und dass das User
Management, da gibt es ja auch viel zu wahrscheinlich viel
falsch zu machen, viel was man beachten muss, wenn man das mal
selber implementiert und wenn man von außen drauf guckt, ist
mein Gefühl, dass das ist eigentlich.
Je besser es läuft, desto weniger denkt man drüber nach.
Das ist total richtig. Weil es einfach so diese ganzen
Flows sind da. Ich stelle mir ein Passwort, ich
erstelle einen Account mit Google, den ganzen Kram, was
alles dazu gehört und dem Thema wollen wir heute auf den Grund
gehen, ein bisschen aufräumen, was da alles gibt und dass es
euch näher bringen. Hast das, so Burkhardt.
Passt ja genau, ist also quasi ne Software architekturthema
User Management. Und, Na ja, so wie du sagst
Gerrit ne man. Man denkt immer so es fällt wo
kommt das vor? Ja also ich mach irgendwie mal
so n sign in oder sign oder irgendwie und dann war es das ja
Pustekuchen ne hast du mich wenn man es bald tatsächlich umsetzen
muss doch ziemlich gewaltig und ziemlich groß ja wir versuchen
es aber trotzdem in der Kürze der Zeit irgendwie zu verhandeln
ich sag auch noch was vorweg ums Einzunorden Wir bleiben im Fokus
wieder. Mal Webtechnologie und wir
bleiben auch so ein bisschen im Fokus.
Spa, also Single Page Applications, die moderne Art
und Weise, wie ich halt heute Frontend mache, das ist ein
bisschen, das hat einen Einfluss darauf, wie ich das Management
nachher kommt nachher noch raus und noch ein Disclaimer vorweg,
ich möchte es so ein bisschen so machen, dass wir ja uns die
Software Architektur angucken sowie so ein bisschen in der
Brille, wie wenn ich jetzt quasi das umzusetzen hätte mit meinem
eigenen Produkt wäre ich quasi Software Architekt oder
Entwickler oder irgend sowas ja also.
Das wäre auch mal so ein bisschen, wie wir es ja immer
machen wollen. So ein bisschen unter die
technische. Gucken und mal schauen, was da
drunter so für n Staub ist. Ja, ist doch super.
Du musst ja nicht nur so tun, als würdest du es machen, du
hast es ja schon gemacht, richtig, in verschiedenen
Ausprägungen und deswegen. Genau, ich kann da n bisschen
aus dem Nähkästchen erzählen, deswegen machen wir auch die
Folge. Ich bin gerade frisch
aufgegleist, was das alles angeht, vielleicht ist das ganz
hilfreich für die Frisörende. Gut, dann trink du nen Schluck
Kaffee. Wir haben genug der Anleitung
jetzt gemacht worden, rein starten ins Thema und als erstes
Mal klären was ist so ein User eigentlich, was bedeutet das
wenn man über User Management redet?
Ja, ganz genau. Also wenn man es naiv denkt,
dann gibt es eigentlich nur die User, die man halt sehr user,
der halt quasi in die Applikation rein möchte.
Also, wovon sprechen wir denn überhaupt?
Wir wollen ja erstmal user Management, heißt ich muss
erstmal überhaupt wissen, was bei User ja und wenn ich
überhaupt user haben will, muss ich erstmal eine Applikation
haben, das setzen wir jetzt mal kurz voraus.
Also ich habe irgendwie eine App.
Was auch immer, ist ja auch Wurst da und jemand klickt
dahin, der das benutzen möchte und der kann das aber nicht
einfach nur benutzen, das gibt es auch, das ist halt public
public und ich weiß nicht wer es geklickt hat, nein, wir sprechen
heute darüber, dass jemand sich da anmelden muss, also ein
Mensch, ein User, so wie du Garrett ja oder wie ich und wir
machen das, indem wir entweder unter unsere E-Mail eintippen
und unten ein Passwort oder aber vielleicht noch cooler irgendwie
über Google Login und so weiter kommen wir später zu, aber das
ist quasi die eine Kategorie User das versteht.
Jeder. Es gibt aber noch und ja, ich
hab ja gesagt, technisch, es gibt noch viele andere User,
mindestens eine Gruppe von Usern will ich jetzt noch mal ganz
kurz erwähnen, denn wir haben ja, wenn wir ne Anwendung haben,
gibt es ja Business Logik in der Anwendung, das ist ja irgendwo
implementiert, also wenn wir nicht gerade nur eine statische
Webseite anzeigen, unsere Anwendung haben wir noch ein
bisschen mehr zu tun und wir haben ja auch schon mal bei
Docker zum Beispiel gesprochen über Microservices und so weiter
dass ich würde jetzt einfach mal voraussetzen, dass wenn wir
jetzt hier über eine moderne Anwendung sprechen, dass wir
modernes Backend auch haben und dann haben.
Wirklich irgendwie sowas wie Docker Container und die haben
ihre verschiedenen Aufgaben und die lesen dann aus einer
Datenbank und so weiter und sofort diese Docker Container,
wenn die miteinander sprechen oder wenn die ne Datenbank
aufrufen wollen ne die Datenbank selber ist auch n
dockercontainer das hab ich n anderen Docker Container der wir
mit der Datenbank sprechen, der muss sich auch authentifizieren,
der muss ja die Datenbank hat verdammt noch mal auch einen
Usernamen und ein Passwort und sollte sie ja das sag ich jetzt
mal ganz ganz klar es. Ja, es gibt ja auch Leute, die
haben im Backend ist alles wurscht und alles offen, ist
aber gefährlich. Ja, also die Datenbank muss
auch, dagegen muss ich auch authentifiziert werden und so
weiter das heißt, ich habe sowas wie Klienten, technische User,
die tauchen nie auf außen, aber die gibt es sehr wohl und je
komplexer mein System ist je mehr microservice ich habe und
je mehr Kommunikationskanäle ich zum Beispiel habe, weil ich
vielleicht noch mit Maschinen kommuniziere oder mit.
Mit der Blockchain, die irgendwie noch geschützt ist,
oder oder, oder, oder ja, desto mehr user kriege ich da noch
rein, die, die sich an bestimmten anderen Dingen
authentifizieren müssen. Ja, und die muss ich auch alle
managen, ja und das muss auch in das System mit rein gedacht
werden, im besten falle ja und wenn ich das als Ganzes
einheitlich System haben. Will ja, und diese 2 Parteien
jetzt sagst du also klar der menschliche Nutzer plus diese
Klienten die sich irgendwie authentifizieren sollen.
Die Erschlage ich im besten Fall mit einem
Authentifizierungssystem, ja. Genau, ist natürlich
Geschmackssache, so aber also genau, wir haben es halt hinter
uns. Tatsächlich war die High Sinware
mit mehreren Authentifizierungssystemen
unterwegs für verschiedene Sachen, das geht, das ist aber
irgendwie. Also wenn ich schon sage, es ist
nicht schön, also es ist immer immer wenn du wenn du den Kuchen
zerstreuselst für die für das Gleiche, für die gleiche Logik.
Dann macht es eigentlich keinen Sinn, also in der idealen Welt
hast du ein System, was alles kann und da da speist du alle
deine User ein und kannst nach den einen Suchen und Filtern und
Anzeigen und so weiter. Egal.
Willst du die jetzt nach außen in die App, willst du jetzt
nicht diese Klienten nach vorne bringen.
Das soll ja keiner sehen. Ja musst du ja aber auch nicht,
das kann ja dein System leisten, ne?
Ähm, ich finde es einfacher, wenn man alles an einer Stelle
hat und es ist sauber und es ist glasklar.
Und ja, du hast da weniger, auch managementschmerzen weniger am
Ende weniger Code, das ist das Wichtigste.
Ja, also als softwarearchitekt, wir wollen dazu hin, dass wir
große Systeme haben mit ganz wenig eigengeschriebenen
zeilencode, ansonsten können wir es nicht verwalten.
Prima, das setzt uns schon die Brücke.
Dann jetzt zum zweiten Thema, was du vorbereitet hast.
Also wie kann ich das realisieren und du hast es schon
gesagt, wir hatten es in der Vergangenheit mit 2
verschiedenen Systemen realisiert, jetzt ist es unter
einem Dach, also bei der heißen wir jetzt wieder gesprochen, ich
würde es mal ein Beispiel, ich glaube das ist auch okay, aber
was kann ich denn grundsätzlich machen, was für Möglichkeiten
gibt es so eine Authentifizierungssystem oder
user Management eigentlich umzusetzen?
Also ich glaube, jeder Softwareentwickler hat es einmal
selbst programmiert und wenn er es nicht hatte, sollte.
Er es einmal tun, vielleicht dann nicht für die komplette
Produktivität produktionslösung, aber es hilft total.
Ist einmal ein bisschen gemacht zu haben.
Früher war das der Klassiker. Also als wir noch hier Lamp
hatten, also Linux, Apache My SQLPHP und so weiter diese
klassischen Dinger mein Gott, da hab ich halt ne Datenbank gehabt
ne ich war User gehabt, das ist auch kein Raketenwissenschaft,
da hab ich mir halt selber ne Datenbank geschrieben und so
weiter kurzum ich hab es selbst programmiert, ja.
War damals auch noch völlig möglich und easy heutzutage,
wenn wir drüber nachdenken, was wir in einem saßen, da sprechen
wir im nächsten Ordnungspunkt drüber, was wir alles so für
Anforderungen haben an das User Management, dann sind die krass
gestiegen und ich rate jetzt nur noch jedem davon ab selbst zu
tun. Ich habe tatsächlich das auch
noch mal selber implementiert, aber auch nicht alles nur ein
Teil von unserem User Management.
Und ich habe alles, sag ich jetzt einfach mal.
Ich hab es alles einfach platt gemacht, weggeschmissen,
ausgetauscht. Ja, und wenn man, und das ist
gut, ja, es fühlt sich also am ersten Moment, denkt man so
verflixt, ja, die schlaflosen Nächte und die ganzen Code, und
was habe ich alles geschrieben. Ungebremst in die Tonne
geschmissen und danach mit dem Juchi irgendwie aufgestanden.
Gesagt. Ja, das war alles richtig so,
ja, aber das ist glaube ich auch was, das wird jeder, der ein
bisschen länger in der Software ist, irgendwie auch schon mal
erlebt haben, das das ist halt so.
Ja und noch mal je weniger selbstgemachter Code, desto
weniger. Probleme habe ich weniger
Maintenance ja, es gibt so viele tolle Produkte außen, ja und die
kann ich entweder einkaufen oder sogar open Source.
Ja, und da gibt es Teams, die testen das alles und so weiter
die machen das für mich, also muss ich mir das nicht selber an
die Jacke schmieren. Wo ich auch gleich zum nächsten
Punkt komme. Was kann man denn dann machen,
wenn man es nicht selbst macht? Und da gibt es, bin ich jetzt
hier im Saas und Web Business spreche, Gerrit gibt es nämlich
2 Möglichkeiten, es gibt das komplett als Service wie es so
alles Mögliche als Service gibt. Ja SL Service sag ich mal und
hier würde man sagen können Authentication und Authorization
SA Service das kann man los googeln, da gibt es zig Firmen
und die unterscheiden sich mit minimalen Ausprägungen.
Und die haben aber auch Pricing Modelle unterschiedlich und so
weiter ich nenne mal 1 mit dem wir nämlich auch unterwegs
waren. Ist so ein Dinosaurier von
früher ist ein großes System, funktioniert einfach Zero.
Das ist aber nen Service n Dienst.
Ja was heißt das was ich quasi ich lagere mein gesamtes User
Management aus von meiner App, das heißt die ganzen
Datenbanken, alles das was ich tatsächlich die ganzen das ganze
die ganze userverwaltung ist halt nicht mehr in meiner
Hemisphäre in meiner App sondern.
Unter der unter den Servern verwaltet von diesen
Dienstleistern, in diesem Fall in Ost Zero ja, wo immer die
auch stehen, da muss ich natürlich auch aufpassen,
DSGDSGVO konform, wenn wir in Deutschland sind und so weiter
darf ich das alles? Passt das alles ne mit den Usern
und so weiter Datenschutz ist da ja ne wenn wir user Management
sprechen, dann sprechen wir hier immer ganz ganz ganz wichtig
über Datenschutz und so weiter das muss natürlich garantiert
sein. Das ist eine völlig.
Es ist völlig okay, das auszulagern.
In meinem Kopf wird das schon ein bisschen schwieriger, wenn
ich da meine Klienten mit auslager, also weißt du die die
inneren User, die da machen, die würde ich dann glaube ich schon
fast wieder trennen, wenn ich so als Service mache, das fühlt
sich jetzt in meinem Bauch erst mal komisch an.
Würde ja bedeuten, wenn ich jetzt so einen Klienten, so eine
Datenbank zum Beispiel, die sich irgendwo authentifizieren muss,
dann über einen externen Service nochmal gehen muss, um sich
intern in der Software. Zu authentifizieren oder so
merkst. Du auch schon.
Das klingt komisch und vor allem das hat auch was mit Performance
zu tun und so weiter extern heißt ja auch immer.
Ich hab halt nen HTTP request. Ja und vielleicht nicht nur
einen, sondern viele. Ja, das und und dieser Dienst
muss ja auch erstmal available sein, vielleicht haben die mal n
schluckauf und so weiter. Also ihr merkt schon, hat
Vorteile. Also der Vorteil ist ganz klar,
ich bin sofort fertig. Ja ich hab quasi nen Service,
ich hab ne API ich bin ich schreib das ziemlich schnell
hin, ich Krieg auch typischerweise, das machen wir
auch noch mal im im später im Nachgang, ich krieg
typischerweise auch so diese E-Mails und diese ganzen Login
forms und so weiter auch alle geschenkt weil es halt weil ich
gar nicht mehr auf meinem Server das mache, ich mache das quasi
in dem in den Servern dieses Dienstleisters und wenn die gut
sind, dann kann ich sogar meine forms customizen gerät du hast
das auch ein paar Mal gemacht. Slowcoat dann am Ende.
Das ist auch cool und das sieht auch super aus.
Da gibt es überhaupt gar keine Frage.
Also und wenn das einem reicht, dann ist das die richtige Wahl,
vielleicht schon hier kommt der Disclaimer, warum ist das
vielleicht nicht die richtige Wahl und für uns war es auf
jeden Fall nicht die richtige Wahl, weil.
Oder ich hab jetzt halt nen Internetdienstleister.
Ja und wenn ich aber meinen wenn ich nen SARS Produkt habe, was
ich aber auch jetzt kurz kurz kompliziert das aber auch um
Premis mal installieren möchte. Was heißt denn jetzt hier on
premise, also in einem privaten, in einer privaten Cloud oder
sowas im privaten Netzwerk, wo der Kunde, bei dem ich das
installiere, keinen Bock drauf hat, dass sie irgendwie noch
Ports und irgendwelche Services angefragt werden, dann kann ich
das schon nicht mehr machen. Weil es halt einfach nicht in in
meiner Software mit drin ist. So.
Ja, das ist zum Beispiel ein, das war für uns n nasser Grund
ist nicht ist nicht zu tun. Wir haben lange überlegt, wie
machen wir es hin und her, machen wir einen externen
Dienstleister oder so. Wir haben jetzt, und jetzt kommt
ich, komm ich zur dritten Variante, also erster Punkt.
Wir selbst machen. Klar müssen wir mal gemacht
haben, aus Spaß kannst du mal n Projekt machen, so sag ich immer
ja dann wegschmeißen und nimm wie es wie es die Experten
machen, also zweitens einfach als Service voll aus voll
auslagern die dritte Variante ist und die finde ich die
allercoolste ich möchte auch ein bisschen hier heute ein bisschen
Werbung machen dafür für vielleicht Start ups die auch
User Management machen wollen ich sage euch nehmt sowas und
jetzt sage ich auch einfach den Begriff Fusion Alls nehmt sowas
wie Fusion aus, da gibt es noch andere.
Aber das ist quasi so eine Art ja Open Source Bibliothek.
Aber aber auf einem Viertel höheren Level.
Also es ist quasi auf Docker Container gelöst.
Ich habe quasi auch den gesamten Service, aber den kann ich quasi
und auch ein Frontend und so weiter das ist alles vorbereitet
und auch E-Mail Management und Fonds und alles und auch
Datenbank Integration, aber die Datenbank die Managed selber.
Ich habe meine eigene Datenbank in meinem eigenen Container und
dann habe ich dieses Fusion, das kann ich installieren als Docker
Container. Und auf einmal habe ich von
beiden das Beste. Ich habe nämlich.
Sehr vieles vorbereitetes Krams, diese ganze Datenbanklogik wie
ich das aufbauen, alles fertig, muss ich mir keine Gedanken
machen, hab ne API, aber die lebt quasi in innerhalb meiner
microservice Architektur. Weiß nicht, ob das jetzt so
schnell verständlich ist, aber ich hab im Prinzip diesen
Service genommen, der Webservice, aber ich zieh den
quasi in mein eigenes SARS Produkt mit rein, ist halt ultra
Ultra cool. Ja, also du hast.
Quasi Code eingekauft oder bis zu einem gewissen Punkt ist es
jetzt bei Fusion auch so, dass man sogar den gar nicht
einkaufen muss, sondern gratis erhält.
Ja. Genau, weil es auch ne relativ
hohe, also es sind auch nicht ganz trivial.
Man muss komplett dieses System inhalieren bis man versteht wie
man es integriert in sich selbst.
So aber genau. Ich denke mal, dass da Fusion
jetzt zum Beispiel Fusion aus oder andere Anbieter
wahrscheinlich auch Geld über Support nehmen.
Auf jeden Fall verdienen würden, wenn jetzt.
Wir haben uns da jetzt tief rein gefuchst, insbesondere das ging
ja auch ein bisschen länger das Projekt, aber wenn man das
jetzt, man kann natürlich auch als Firma Support dann Anfragen,
denke ich mal, und dann kriegt man Hilfe bei der Integration
eines solchen, ja. Auf jeden Fall.
Und die haben auch noch so pro Features, wenn es an Two Factor
geht und hier mit Mobiltelefonen und so weiter und sofort dann
okay. Also noch mal ganz kurz, erste
Option selber machen, allen Codes selber schreiben, hast
aber festgestellt ja kann man, also sollen wir mal gemacht
haben, man kennt sich dann besser aus, aber dann auch den
den Darlehen killen. Darlings und dann zweite
Variante. Ich mache es über wenn ich wenn
ich wenn ich rein im Web unterwegs bin und wirklich
schnell sein will, mache ich es über eine API über einen anderes
SARS Tool letzten Endes auch. Was auch cool sein kann, hat
aber seine Einschränkung. Wenn ich on premise gehen möchte
und wenn ich vielleicht dann doch noch mehr customizen will
oder so gerade noch so diese diese Clients, also Datenbanken
et cetera mit authentifizieren lassen möchte, dann gehe ich auf
die dritte Option. Ich nehme also ein fertiges,
mehr oder weniger fertiges Produkt, was ich noch customizen
kann, was ich aber als so als Container in meine ganze
Applikation mit rein bauen kann. Richtig.
Und ich saß auch immer ganz klar.
Also erstens, dass du es halt mit One Premise nimmst und
zweitens wenn du also wir haben sind ja im Io t Business
unterwegs. Ja also für alle, für alle
Startups oder für alle Leute die jetzt hier Plattformen denken
und so weiter die auch mit Io t und den Dingen zu tun haben, da
habe ich auch Nummer 3 empfehlen, weil du dann halt
noch eine Sorte mehr User hast. Diese ganze Connectivity zu den
ganzen Io t Geräten dieses ganze Fleet Management und Gedöns also
das das wird komplex wenn du das voll auslagerst in den Service
und es wird wahrscheinlich auch ziemlich teuer man muss.
Nämlich auch mal sagen, dass die einfach, die nehmen es auch
gerne von den lebendigen, vor allem wenn du komplexe.
Komplexe Anforderungen hast, dann ist User Management mit mit
Hierarchien und Rollen und so weiter und sofort ja.
Alles klar, OK, cool, dann haben wir die Möglichkeiten
verstanden, dann wolltest du wahrscheinlich über die
Komponenten sprechen, die zu so einem.
Dazu gehören, ich versuche es wie immer, so ein bisschen von
wir, wir kommen von der höchsten flugl Ebene und kommen ein
bisschen tiefer. Jetzt haben wir quasi uns
vorgearbeitet und sich jetzt eigentlich auch wurscht, wie wir
es gemacht haben, aber ich habe erkannt, muss ich auch sagen,
ich habe es ja selber implementiert.
Habe eine neue Erkenntnis gewonnen, auch durch die Art und
Weise, wie aufgeräumt Fusion ist und wie die denke ist und auch
der Rest der Erfolge ist so ein bisschen angelehnt an deren
technische Architektur, wie man sowas zu verstehen hat.
Ich finde die ist aber allgemeingültig und einfach und
richtig würde in Zukunft immer nur noch user Management so
denken wollen und das wollte ich teilen hier und es gibt nämlich
logische Komponenten wenn ich jetzt über das User Management
nachdenke und. Die allerwichtigste Komponente
ist der sogenannte Tenant der Tendenz.
Das ist, das ist ein besonderes Wort, was immer vorkommt, vor
allem, wenn wir mit dem User Management sprechen, heißt es
immer tennent anders. Leute würden sagen, Account ja,
Intendant ist meistens ne Firma oder Irgendsowas ja dein Kunde
ja irgendwie was weiß ich Siemens oder oder ich mir fällt
immer Siemens an, ich weiß gar nicht warum.
Es gibt so viele andere Firmen ja Bäckerei backt das Brötchen
irgendwas ja das ist ein Tenant ja und als SARS Provider sage
ich mal hast du ja verschiedene Kunden das sind alles deine
tendencer und was jetzt wichtig ist innerhalb eines also die
Tendenz müssen halt alle isoliert voneinander.
Verhandelt werden, was das User Management ausgeht, denn dass
ihr jetzt sag ich mal was, wenn du nämlich wenn du den Account
oder den Tenant als Firma Wahrnimmst, dann hast du ja im
Notfallgerät mehrere Leute die in dieser Firma sind.
Die User sind ja nicht, also das ist wichtig.
Es gibt nicht den User, der der Tenant ist, der Tennant
identifiziert die Bäckerei und und die User sind die Leute, die
in der Bäckerei arbeiten und davon gibt es ein oder viele,
ja, und die können zum Beispiel einer davon oder mehrere
gleichzeitig oder sowas, sind vielleicht Kunden in Deinem in
deiner Anwendung, ja weil du irgendwie eine Bäckerei
geschrieben hast oder irgendwas. So, und die wechseln sich ja
auch. Das heißt aber, was ich sagen
will ist, dass und wenn der nächste Kunde halt dein dein
Handwerkerbetrieb ist, ja dann haben die halt genau nichts mit
dem mit der Bäckerei zu tun. Ja und da soll sich nichts
mischen, das heißt, die Tendenz sind die Oberste.
Hierarchiestufe und Gliederungsebene ja, deshalb.
Deswegen denkt man intenance ja, also jeder Kunde ist in Tenant
und da drunter, es kommt jetzt, was ich jetzt sage, Dadrunter
haben wir dann als nächstes Mal ganz wichtig die Applications.
Also die Anwendung im ganz einfachen Fall hast du genau
eine Anwendung. Ja was weiß ich.
Die smarte, die smarte Brötchen Ofenstoppuhr im Internet oder
was ja keine Ahnung ist, halt eine Anwendung.
Aber wenn wir, wenn wir im Saal im Business denken, haben wir
vielleicht auch mehrere. Anwendungen, dass wir vielleicht
noch eine Sache zum Tennis sagen.
Ich glaube, das deutsche Wort dafür ist letzten Endes Mandant,
Mandant, ja genau, wir haben hier tatsächlich einfach
Mandanten, und wenn du das so aufteilt, bist du dann auch
wieder mandantenfähig und kannst teilen trennen zwischen
Mandanten. Was mir bald wichtig war, ist,
dass der Mandant halt keine Person ist.
Mandant ist halt eine Firma oder ein Kunde oder irgend sowas,
aber keine kein human being sage ich mal.
Das ist dann später der User. Naja gut, aber wenn du jetzt ein
Softwareprodukt hättest, was nur für Einzelpersonen da ist, dann
würdest. Du die Internet weglassen, dann
hast du den Default tenant und würdest auf die Users gehen.
Das ist ganz wichtig. Ja das darf man nicht
verwechseln, deswegen mache ich diesen Punkt der Tendenz ist nie
ein eine Nase, der hat keine Nase, das ist irgendwie eine
Institution Institution. Irgendsowas ja, und wenn du,
wenn du nicht mal die Talentfähig bist, weil du das
nicht brauchst, ja dann hast du, dann nennst du den irgendwie so
wie deine Firma, dann bist du halt, der kommt dann nicht vor.
Ja dann managst du halt da drin die Applications und die Users
da drinne managst du da drinne, da haben wir nämlich die Users
und das sind die normalen Users wie du und ich ja und die
Clients auch, die heißen alle User, also die ganzen alles was
irgendwie eine Authentifizierung und eine Autorisierung braucht
ist ein User und dann haben wir die Applications.
Eine oder mehrere, je nachdem wie komplex ein System ist.
Wir haben zum Beispiel, wir haben es ganz besonders komplex,
weil wir ja quasi ein Produkt haben, wo wir Anwendungen bauen,
das heißt, da entstehen sogar auch dynamisch welche dazu, und
dann haben wir quasi den App Manager, der ist neu, wo man das
quasi verwalten kann, das ist mal die erste App, die es da
gibt, so, also je nachdem was du halt so hast, kannst du halt
mehrere Anwendungen haben, so, und das ist jetzt auch wichtig
zu verstehen, und das ist so schön, man muss das trennen, es
gibt die Anwendung, und die sind für sich und die Anwendung die
Applications. In denen definierst du quasi
schon rollen. Ne, was später die Users da
machen dürfen und die Users, die sind auch für sich.
Ja die legst du erstmal an, aber die haben erstmal beide
miteinander nichts zu tun, das sind 2 einzelne stapel
Anwendungen und User. Ja und wenn du und das ist
wichtig, das hat Fusion auch gut gelöst.
Und wenn du jetzt sagen willst dieser User hat irgendwas in der
Anwendung zu tun, dann registrierst du ihn für eine
Anwendung und das nennt sich Registration das ist die nächste
Komponente. Registration assoziiert einen
User in einer Anwendung oder in mehrere oder umgekehrt.
Da kannst du also End zu n machen.
Das Wichtige ist, dass du nämlich aber innerhalb des
Tennens, in dem wir jetzt sind, sind die User und die Anwendung
unique, davon gibt es nicht 2 gleiche also den Gerrit Meyer
gibt es unter dem tenet Bäckerei genau ein einziges Mal.
Aber das könnte so sein, dass du 2 Jobs hast.
Gerrit, du bist bei der morgens frühs von 4 bis 6 backst du
Brötchen in der Bäckerei, dann bist du User im Tenant Bäckerei
und danach gehst du zum Handwerksbetrieb rüber und
schleifst da irgendwie ein. Rohre glatt, irgendwie.
Ja, dann bist du, dann kommst du dann noch mal vor und sogar mit
dem gleichen, eventuell mit dem gleichen Username, was du
wahrscheinlich nicht hast, weil du dann deinen Firmennamen ne
andere E-Mail ist so, aber dann bist du separiert so ja.
Aber innerhalb des gleichen Tennens, wenn da mehrere
Anwendungen sind, bleibst du der gleiche User und wirst quasi
über die Registration quasi nur zugeordneter.
So und der letzte Punkt hab ich auch schon kurz angewählt, die
Rouls ja das ist das, das ist das Wichtigste, das eine ist ja
Authentifizierung, also festzustellen ist, dass
derjenige, mit dem ich spreche ist wirklich das Gerrit, das
machst du indem du User namens Passwort am Anfang gibst und das
zweite ist. Welche Rechte hast du denn dann
wenn du da bist in der App und die Rollen das ist auch wichtig,
die muss man pro Applikation denken.
Also jede Anwendung, jede Application hinterlegt die
möglichst verfügbaren Rollen, die gesamte Dimension aller
Rollen. Was gibt es da drin und in der
Registrierung? Wenn ich dich registriere auf
diese Anwendung, dann bekommst du einen Untersatz dieser Rollen
oder alle, je nachdem Admin Viewer was weiß ich Editor und
so weiter und sofort die Registrierung speichert, also
quasi die erstens mal die Zugehörigkeit zur Anwendung und
zweitens deine Rolle innerhalb. Der Applikation, das sind jetzt
12345. So tenant application User
Registration und Rolls 5 Komponenten relativ einfach und
wenn du die im Kopf hast und einmal verstanden hast, da gibt
es n cooles Bild. Auch das kann ich euch leider
nicht zeigen, aber über Text sprechen hier, dann hast du,
dann kommst du klar, da kriegst du die komplexesten Probleme
gelöst. Wenn du das ineinander gut
steckst. Das war eine krasse Erkenntnis
für mich. Jetzt gibt es vielleicht die
Leute die sagen ja was ist mit dem Permissions, also dem
Rechten. Kann man erstmal weglassen.
Du kannst auch rollen. Kannst du ja sehr granular
aufbauen und dann bildest du letzten Endes permissions ab
durch eine Rolle, die ganz spezifisch ist, weil ein User
kann ja auch mehrere Rollen haben denke ich mal dann pro.
App das ist so genau du hast. Das ist immer so.
Ja, das ist das ist das im Rabak Role Based System ist es so,
dass du mehrere Rollen gleichzeitig haben kannst?
Genau, und damit also die permissions kann man.
Die einfach weggelassen so und ich merke du kommst da völlig
gut klar mit Rollen, weil es ist nämlich auch ich, mein Kopf und
auch der von vielen anderen Entwicklern ist halt komplett
geflogen. Mit so vielen Begriffen und so
viel Zeus. Es wird Überengeniert und
aufgeblasen im Netz und du kommst überhaupt nicht mehr auf
den grünen Grund alleine von deiner logischen denke her.
Und wenn man jetzt und und Fusion aus da steht so schön in
einem so einem in einem Artikel so Pass auf wir machen Back to
the roots. Reset ja resette dein Kopf.
Alles was du weißt hier diese 5 Komponenten gibt es mit denen
denkst du. Ist cool.
Es dauert n Moment und wenn man es aber erstmal hat, dann kommt
man sehr sehr sehr weit kann ich sagen, weil wir sind nämlich
fertig und ruhig, es funktioniert aber.
Bestimmt gibt es auch noch andere tolle Tools da draußen.
Ja klar, ich, ich sag das ja nur, weil ich, also ich will
jetzt auch genau ich, ich fand, ich find es halt schön, weil die
Leute. Sich ein paar Gedanken gemacht
haben, es auch ordentlich aufzuschreiben, so ist klar.
Es gibt viele andere Tools und die haben wahrscheinlich auch
mal irgendwo geguckt und waren vielleicht auch nicht die
initialen Autoren, ich will es nur mal, wollte ich nur mal so
sagen. Okay cool du das waren die
Komponenten auch zu dem Thema. Dann kommt jetzt das Thema, was
du vorhin auch schon mal angerissen hast.
Also es gibt diese ganzen Flows und Prozesse, also also
insbesondere dann auch in der in der Interaktion mit den
eigentlichen Usern, angefangen mit dem mit dem Signup.
Also was man natürlich heutzutage kennt ist, wenn man
auf modernes Webtool geht und ins ask Tool, dann nehme ich
eigentlich nur noch Sinner mit Google.
Ich kann mich aber natürlich auch klassisch mit E-Mail
Adresse und. Also weil ich natürlich Kugel
benutze, privat wie auch in der Firma so.
Hat natürlich nicht jeder das Glück, aber welche gibt es noch
und was gibt es dazu zu wissen? Ja, ich wollte technisch nur mal
genau. Ich wollte eigentlich nur mal
durchgehen, was was müssen wir alles bedenken, wenn wir user
Management machen, was gibt es alles für Prozesse und für
Flows, also den ersten den man kennt hast du schon gesagt
Signup das heißt wenn ich ganz neu irgendwo in eine Anwendung
reinkomme und es gab mich noch nie, die Anwendung kennt mich
noch nicht, dann muss ich ein Signup machen, so viel wie eine
Registrierung, eine initiale Registrierung, das mache ich
auch nur genau ein einziges Mal. Warum ist das anders als einen
Login? Weil ich muss ja dem der
Anwendung mitgeben, wer ich bin, genau, also nicht nur Username
und Passwort, sondern ich will vielleicht noch den First Name
und den last Name zu deutschen Vornamen und Nachnamen wissen,
manchmal muss ich da auch schon einen Account angeben, je
nachdem wie das System gestrickt ist oder noch XY Informationen,
das ist sehr unterschiedlich, andere brauchen irgendwie ganz
dringend Telefonnummer von dir oder was weiß ich so ja.
Genau. Und dann wirst du quasi, dann
wirst du quasi initial angelegt und auch das ist auch deswegen
noch unterschiedlich dieser Registrierungsprozess, weil bei
vielen SARS Anwendungen müssen dann initial Ressourcen für dich
angelegt werden, vielleicht irgendwelche Docker Container
hochgefahren werden, Datenbanken vorher logiert werden oder
irgendwie was, ja weil nach der Registrierung bist du ja quasi
in so einer Art, ja hast du so eine Art Finanz workspace oder
wie auch immer, aber du bist natürlich irgendwie ein in dem
System drin und willst damit arbeiten, das heißt sie brauchen
irgendwie. Gewisse Art von Speicher, Cloud
oder irgendwas für dich, ja. Jetzt lass noch mal bleiben bei
dem Beispiel, was du jetzt gesagt hast.
Also ne wie bei uns ne Applikation wo es Tendenz gibt.
Ja grundsätzlich und also Mandanten und das heißt wenn ich
jetzt als Erster. Oder wenn ich mich jetzt da
anmelde, ja und parallel den Tenant erstelle.
Also wird User und Kennet erstellt, richtig, dann ist das
so, dass da Ressourcen hochkommen et cetera, oder?
Du sagst es also das hab ich jetzt, das hast du noch besser
formuliert als ich hab es gerade vergessen.
Genau wenn du mich als erstes, du bist ja quasi ne Nase, also
nicht human User, aber du legst quasi in dem Registrierprozess
gleichzeitig den Tenant an für. Dich, ob jetzt bewusst oder
unbewusst wie der. Bäckereimitarbeiter und wirst du
da unbewusst so aber den quasi wenn es die Bäckerei noch nicht
gab, in der du arbeitest. Und du dich jetzt aber als
Mitarbeiter als Nase der Bäckerei anmeldest, dann wirst
du quasi Ersteller dieser dieses Tendenz Bäckerei am Anfang.
Genau das ist der Punkt, ja und das ist und und und das
unterscheidet quasi die Registrierung wie wie man und im
Englischen heißt es mal signup ich finde es immer sehr
verwirrend und das andere heißt sign in Sign als ich glaube, als
deutscher Staatsbürger ist man immer verwirrt, was jetzt was
ist. Also ich war es jedenfalls
länglich. Ja, ich finde auch sign und
Login besser als Unterscheidung tatsächlich.
Manche nennen es auch Registration und Login.
Dann wird es noch klarer. Ja, genau, ja ist
Geschmackssache. Ich hab mich jetzt dran gewöhnt,
dass signeup halt quasi hat. Die initiale Registrierung ist
und genau und der Unterschied danach zum Login oder Sign in ja
ist dann es gibt den ja und es gibt die Nasen und ich war schon
mal im System, ich bin irgendwie nur rausgeflogen weil ich lange
nicht mehr drinne bin. Ja und jetzt muss ich mich quasi
einloggen, authentifizieren, das ist der
Authentifizierungsprozess. Und melde mich beim System an.
Und was dann passiert ist auch ich muss quasi das System muss
dann quasi auflösen okay da hat sich Gerrit Mayer angemeldet und
der hat jetzt sich in dieser Applikation angemeldet und da
drin hat er folgende Rollen und das weiß das System sofort nach
der Anmeldung. Ja deswegen das ist wichtig ja
also wenn du dieses dieses Formen, ob das jetzt mit ob du
klickst mit Google oder Usernamen und Passwort ist Wurst
danach weiß das System schon ganz genau welche Rollen du hast
im nächsten Moment, weil jetzt ist es wichtig, jetzt geht die
Webseite quasi auf. Soll ja schon quasi gefiltert
sein zu dem was du siehst oder nicht?
Ja, je nachdem was du für ne Rolle hast.
Ja bist du Admin, siehst du für sie irgendwie alles, bist du
irgendwie was weiß ich Operator oder sowas kannst du halt
bestimmte Sachen nicht sehen, ganz klassisch.
Ja, musst du auch. Wahrscheinlich gleich alles da
sein, weil wir ja über Single Page Applications reden, ne,
dass dann alles für mich mit meinen Rechten entsprechend
vorbereitet. Ist ganz genau, ganz genau.
Das ist dann quasi die Logik, die steht dann im Frontend, das
muss man also, wenn man Single Page Application hat, da muss
man quasi im Frontend wissen. Diese Rolle, ja, und dann kann
man quasi Sachen ein oder ausblenden.
Gemanaged wird das alles übers Backend, also sage ich gleich,
aber noch, was kann man am nächsten Punkt?
Ich wollte jetzt einmal kurz die Flows gehen, also wir hatten
jetzt Registrierung, Login, dann haben wir typischerweise
vergisst man immer wenn man es wenn man es selber
implementiert, dann denkt man so OK Registrierung Login fertig
ja. Ach nee, der hat ja dein
Passwort vergessen. Ja, das muss ja auch noch
irgendwie vor Gott, Passwort, Flow ja ganz klassisch, ja, und
das ist gar nicht so einfach, weil da musste irgendwie ne Mail
schicken, da brauchst ne Verification ID, technisch ist
das auch schon wieder ein bisschen aufwendig so ja so und
dann haben wir noch was wenn wir einen Sign haben, dann haben wir
immer eine App die eigentlich publicly available ist, wo ich
quasi nicht sage, also dann darf ja jeder jede Bäckerei, jeder
jeder Hansel und pamsel kann halt einen Account erstellen.
Wenn er dann noch nicht weg ist. Das kann ich vielleicht nicht
wollen, weil ich nur sage, NÖ, die App ist nur für ganz
bestimmte Leute, die ich vorausgewählt habe und dann
komme ich zu einem dritten Flow. Das ist typisch Invite Flow, das
heißt, den kann man abbilden über verschiedene Dinge, aber
ganz typisch ist, ich kenne halt eine E-Mail, ich nehme jetzt
nochmal den Garrett, weil er hier gerade bei mir gegen
gegenüber sitzt, hätte ich beinahe gesagt, wir sind aber
Remote weiter, aber der Gerrit, Ich kann jetzt sagen, nur der
Gerrit darf jetzt hier in meiner App, dann schicke ich dem Gerrit
Halt so eine Art invitation E-Mail, dass er gerne sich ein.
Einloggen dürfte. Ich erstelle quasi schon den den
Garrett, ich mach quasi den Tennen schon fertig und
registriere ihn vor. Aber die Komplexität hier ist,
ich kann ihn mir noch nicht vorgeben, was dein Passwort sein
wird, ja oder ob er sich mit Google danach einloggt.
Ja, das kann nicht so trivial. Ja, ich sag Ihnen nur Pia, komm
mach das fertig, ja und dann sucht sich der Gerrit später
noch n Passwort aus oder loggt sich per Google ein und dann ist
er im System ne. Aber aber jemand anders kann
halt nicht einfach ins System rein, weil er erst ne
invitation. Also in meinem Kopf ist da
einfach schon ne Datenbankeintrag dann vorhanden
halt mit einem mit einer User ID.
Letzten Endes also meine E-Mail-Adresse zum Beispiel und
ich fülle dann nachher das Datenbankfeld.
Passwort noch ja auf den auf der richtigen Art und Weise.
Eben richtig. So ist es, sogenannte ne so
tatsächlich so trivial. Und dann und jetzt, ich sag es
noch mal ne kurze zum echten Leben und so funktioniert schon
wieder nicht. Wenn du dann nach dem Google
Login machst weil. Das kennen wir vielleicht auch.
Es gibt ja Leute, die haben mehrere Google Logins, ja
mehrere Konten, konten ja Content bei bei Google so und
ich lade dich jetzt ein auf garrett.garrett@heißenwehr.com
was dein Google Account ist. Du gehst auf den Link, drückst
auf Login mit Google, nimmst aber deinen privaten Google
Login. Ne, schon ist mein
Datenbankeintrag finden für die Katze gewesen.
Ja und auf einmal kommst du mit einer anderen E-Mail rein als
also davon muss ich mich auch schützen, ne also.
Der Teufel ist im Detail User Management ist wirklich nichts
was was man eben mal gerade so schnell absteckt.
So, das muss man alles checken, prüfen und man ist froh wenn es,
wenn es wirklich ne gute Bibliothek gibt, die einem da n
bisschen hilft. OK, dann haben wir es.
Ich würd sagen, das sind die wichtigsten Flows.
Nee, es gibt noch einen so n One Time Access, das hat man ganz
oft, wenn man jemanden irgendwie so n Download Download anbietet
ja wo man sagt so hier hier auf unserer Plattform gibt es
irgendwas geschütztes im geschützten Bereich kannst du
Grad runterladen ne und das ist vielleicht sogar jemand ganz
extern oder irgendsowas kann man ja manchmal kennt man das so von
Microsoft 365 oder irgendsowas ich share halt irgendwie so ein
Dokumenten oder Irgendsowas ja das kann ich ja nicht einfach
offen sharen, dann braucht jemand und ich will auch nicht
deswegen nur weil der einmal was runterlädt den jetzt als User
unter dem Nintendo anlegen und und und da brauchst du ne Art
Runtime. Besser, und das gibt, das gibt
es halt auch, dann kann ich halt so One Time, Magiclinks und so
weiter wie das heißt irgendwie erstellen und dann darf man sich
da einmal was runterladen, dann muss es auch mit getrackt werden
und so weiter ja das sind so typische Flows.
Ja, also sign in Signal, Forget, Passwort invite und so Runtime
Dinger jetzt. Habe ich noch eine Frage, die
mir da jetzt gerade ein Film ist.
Ich kann ja zum Beispiel auch bei uns im Google Drive oder ich
könnte es wahrscheinlich auch in Dropbox oder Microsoft.
Onedrive kann ich ja einzelne Dateien wie auch Ordner also
freigeben. Ich habe ja die Möglichkeit da
auf auf auf Dateiebene eine Freigabe zu machen und entweder
an den bestehenden User aus meinem Tennant auszuwählen,
indem ich das jetzt speziell nochmal freigebe oder eben nicht
auch wieder mit Rollen oder ich kann auch sagen, also shared
oder public. Also.
So. Und dann der Public auch wieder
zuordnen. Ist das jetzt
bearbeitungszugriff Kommentarzugriff oder?
Nur Ansicht, also Ansichtskommentar oder
Bearbeitung. Was passiert da Speicher ich
dann mit mit der Datei oder mit dem Ordner Rechte oder ist es
gibt es dann sowas wie ein Public User der dann wieder
rollen hat? Kann dir nicht genau sagen, wie
Google das gemacht hat, aber du also allein, dass du
philosophierst drüber siehst du schon, wie komplex das ist.
Und man kann manche Sachen auch auf verschiedene Sachen angehen.
Ne. Also man kann ne Ressourcenrolle
geben oder dann user und so weiter das man muss sich das,
man muss sich da jeden Flow. In diesen und deswegen hatte ich
jetzt am Anfang gesagt, in diesen Komponenten, die ich
arbeiten und application User Registration und Rules muss man
sich hinlegen. Ja und vielleicht mal auf dem
Blatt Papier sogar aufzeichnen. Ja und dann sich überlegen was
macht das Sinn ne? Also das ist ich und also, und
um das noch mal zu sagen, was da Google macht und so weiter das
ist halt wirklich komplexe Materie.
Ja und es ist auch sehr tatsächlich, wenn man jetzt
Microsoft, ich weiß das gerade weil ich, ich bin halt tief im
Thema drin, weil ich es gerade mache seit 3 Monaten, wenn man
sich zum Beispiel anguckt, wie Microsoft intern ihre
Authentifizierung macht und Google könnte meinen, da gibt es
ein Standardrezept, ist aber auch nicht so auch komplett
unterschiedlich. Also auch architektonisch.
Da gibt es schon. Es gibt mehrere Wege, die nach
Rom führen, ne und auch manchmal nicht ganz klar welcher der
Beste ist. Oder es bleibt ein komplexes
Thema. Ja, umso spannender, dass du
einfach jetzt auch diese Erfahrung berichtest.
Da muss man auch sagen, es gibt ja auch hier wieder andere Wege
und und. Auf jeden Fall soll auch jeder
so machen, wie es soll. Ich also unser Podcast ist
sowieso nur, man kann ja abschalten, wenn es einem nicht
passt. Also wir sind durch die Flows
durch. Wir gehen noch ein bisschen
technischer runter, ich wollte eine Sache noch mal sagen für
dieses Google Login, das ist ein bisschen magisch, oder Microsoft
Login. Das wollte ich.
Einmal kurz sagen, Apple gibt es auch jetzt hier bei der
Aufnahmeplattform geht es mit Spotify.
Es bieten viele an. Ja, genau, genau, genau das ist
so. Man nennt das im Fach Chinesisch
Itp Login über Idp über Identity Provider.
Und es ist tatsächlich, also ich muss sagen, es ist unglaublich
cool, weil die User experience, ich, ich mag überhaupt nicht
mehr, also es ist ja furchtbar, dass man überhaupt diese ganzen
Passwörter hat und und dann muss n passworttresor haben und
ständig sich das merken, ja und wie einfach ist das Leben, wenn
ich einfach überall mein Google Login nehmen kann?
Ich bevorzuge das schwer, ich glaube.
Dass in Zukunft das noch viel stärker kommt und man sieht es
an den Saaten, du hast das sehr gerettet, jeder, jeder bietet
das quasi schon an. Es gibt ja auch Bestrebungen
glaub ich vom vom Bund, also zum Beispiel in Deutschland
irgendwie nen so ne Art Identity Provider Service auch auch auch
zu bauen und zu machen. Da gibt es ja alles mögliche,
aber auch da wahrscheinlich setzen sich am Ende einfach die
Big Text da durch, aber die. Eh schon.
Die Accounts haben von also die Apples und Googles und so.
Und tatsächlich ist das aber noch, ich muss sagen das, das
kriegst du nicht geschenkt. Also Login mit Google und so
weiter das ist und vor allen Dingen nicht in SPAS Single Page
Applications. Und auch da können, also das ist
vorbereitet in jetzt, ich sag es nur mal kurz bei Fusion aus und
auch bei Austhero und so weiter also alle alle Dienstleister in
der Authentifizierungsbranche, die bereiten dir das schon vor,
ja. Und die können das nur bis zum
gewissen Maße vorbereiten. Zwar aus sicherheitstechnischen
Gründen ja, und den Rest musst du selber machen und das, was
wir selber machen müssen, das will ich jetzt einmal kurz
sagen, das weiß man nämlich typischerweise nicht, also ich
wusste es jedenfalls auch nicht so ganz genau, das hat nämlich
mit O aus 2 zu tun und so weiter da wo hat man ne Folge, das will
ich gar nicht ansprechen, aber was?
Was du außerhalb deiner ganzen Software, Architektur und dieses
Einbindens von deinen, von was auch immer du da nimmst, von
einem Authentifizierungsdienstleister
oder sowas noch machen musst, ist.
Wenn du jetzt als Firma selbst, ich sprech mal von uns, als
heißen du eher nen Google Login zum Beispiel anbieten möchtest.
Dann musst du selber erst mal nen Account haben bei Google.
Google Cloud Account das ist Voraussetzung, warum?
Weil du musst nämlich sowas, das heißt sogenannten O aus Client,
den musst du anlegen, ja, und zwar und im Notfall ist das
sogar richtig krass, den musst du, wenn du, wenn du damit noch
mehr Sachen machen willst, quasi von Google aus, dann muss das
auch verifiziert werden von Google usw das heißt?
Der Softwareentwickler, der das machen will, der muss zu Google
Cloud gehen und da die richtigen Knöpfe drücken und nen so ne Art
an so ne Art O aus Client anlegen.
Ja mit und auch da die ganzen Sachen hinterlegen Privacy
Policy dann ihr kennt das so n bisschen wenn ihr mit Login mit
Google mal. Besten Falle kommt dann so ne.
Kommt dann so ne nächstes Pop up?
Das ist dann schon von Google das ist der Punkt, man macht das
ja nicht mehr bei sich, sondern wir und das haben wir in der
Folge langwierig Auseinandergelegt in der O.
Aus 2 Folge könnt ihr euch doch irgendwo anhören, aber man ist
quasi auf dem Server von Google. Aber im coolsten Falle will ich
da trotzdem mein Logo anzeigen. Ja, weil was mach ich denn
jetzt? Ich möchte mich einloggen bei
Heisenware, also will ich da heißen wer Logo sehen und dann
steht da irgendwie hier willkommen sie loggt sich jetzt
einfach, heißen wir übrigens hier sind die Privies, die Terms
und die die Data Policy Terms und so weiter die musst du auch
lesen, das ist rechtlich verbindlich und so weiter das
muss halt richtig hinterlinkt sein und dann muss das auf einen
Link zeigen der auf heisenwehr.com zeigt und nicht
bei Google irgendwo und so weiter und sofort jetzt kann man
sich schon vorstellen, das kann ja nicht irgendwie magisch
passieren, das heißt ich muss das tatsächlich bei Google hin
konfigurieren und machen und so weiter und da gibt es.
Secret Tokens und so weiter und und leider ist es so, dass das
Halt bei jedem unterschiedlich ist.
Bei Google geht es halt so und bei Microsoft halt anders.
Ja und wenn ich jetzt n Microsoft Login haben will, die
wenn ich den erstmal hab wenn ich da das mache ich über die
Azure das Azure Portal. Dann hab ich gleich ganz viele
Abgefrühstückt, weil nun die Halbe die halbe Welt gehört.
Ja, Microsoft, also ich weiß nicht, was da alles zugehört,
dann hab ich die gleich mit drin, ne da krieg ich dann so,
aber das muss ich jetzt auch erstmal machen, dann muss ich
mich also erstmal n Azure mit Azure beschaffen und n Portal da
aufziehen und meine Firma da registrieren und und und und und
und ja. Also das mal.
Also wenn man das wenn ihr plant das zu tun, bisschen Zeit
einplanen, weil das ist tatsächlich nicht ganz trivial.
Ich könnte mir fast vorstellen, dass es auch schon wieder SARS
Provider gibt oder Dienstleister, die das wieder
alles bündeln. Diese ganzen Social Finance und
Signups. Hab ich noch nicht gesehen, weil
das ist. Also ja, wär vielleicht ne
Marktlücke, aber ich hab es noch nicht gesehen.
Das ist weil weil das halt echt du musst auch verifiziert werden
dann von Google. Also wir haben jetzt auch so,
bei uns läuft dann so n Verification Ding die gucken ist
bist du dann bist du gibt es die Firma Adresse und so.
Weiter und sofort scheint, ja, könnte, scheint ja, als könnte
man das einfacher machen und benutzen alle.
Also ich wette da gibt es was aber.
Ich bin ja auch ein bisschen blöde und habe das irgendwie
genau. Vielleicht gibt es ein Tool.
Glaube ich nicht. Aber es gibt bestimmt Sachen,
die es dir Bündel, aber er hat wieder dann andere wie immer hat
dann wieder andere Nachteile, hast extra kosten was auch
immer, musst halt abwägen. Musst abwägen.
Genau, also, es geht. Was dann passiert, ist auch
total elegant. Es gibt es gibt dann quasi, also
wenn ich jetzt die es gibt in den Nutzerdatenbank und wenn ich
ein User über über E-Mail und Passwort habe, dann lebt er in
meiner Datenbank und wenn ich das nicht hab über Google oder
Microsoft oder wie auch immer, ja dann lebt quasi von dem nur
so eine Art Id und tatsächlich die ganze Passwortverwaltung ist
Outgesourct zu Google, das heißt du kannst ja auch dein Google
Passwort ändern, das interessiert mich gar nicht wenn
du Über Google bei mir eingeteilt ist.
Also hat das deine Vorteile. Gut so, jetzt einmal noch
verstanden, verstehen wir noch einmal kurz, was wir für
technische Komponenten brauchen, wenn wir sowas umsetzen und das
ist ganz klar, wir brauchen eine Datenbank, wir brauchen immer
irgendwie eine Datenbank, im besten Fall eine relationale ich
nehme gerne Post Respekt wo halt irgendwie die ganzen Nutzer
Dinger drin stehen, ob das JETZT id PS oder nicht muss das
irgendwie verwalten. Dann brauchen wir, das ist
wichtig, einen ein logisches Backend.
Also selbst wenn du nen Dienstleister hast und hast da
irgendwie APIS und so weiter wir müssen dran denken, wenn wir in
einem Frontend sind in einem SPA, dann läuft der der Code in
dem Browser des Klienten, das heißt?
Ich darf aber nicht auch ein einziges Token haben, was total
sicherheitsrelevant ist. Ja, weil das ist alles
potentiell hackbar, ja. Das darf nicht im Frontend sein.
Man. Darf nicht im Frontend sein,
genau ich, ich muss halt alles was der der der der wirkliche
Zugriff auf die Datenbank ja um die Einträge zu machen, Passwort
gewechselt und so weiter und sofort, das muss alles über
einen Backend gekapselt werden, das klingt mega aufwendig, man
denkt so Scheiße wieso? Ich hab doch jetzt hier zum
Beispiel auch Fusion aus hatten API und so weiter ihr könnt ja
direkt vom Frontend aufrufen, so könnte man erst denken.
Ich warne alle davor, das überhaupt erst mal zu versuchen,
weil dann brauche ich ja den, wenn ich was vom Frontend
aufrufen will, eine API, dann brauche ich da ja auch ein Token
Führer, sonst kommen ja nicht Abi nicht ran und wenn ich das
vom Frontend direkt ausmachen will, dann heißt das Token
irgendwo im Frontend. Also ihr müsst es Kapseln über
es muss quasi ein logisches Backend geben, was das was das
Kapselt und da drin noch mal die Datenbank abrufen macht.
Im Frontend gibt es gefälligst nichts.
Dann habe ich noch weitere Komponenten, dann muss ich, wenn
ich sowas implantieren muss, muss ich über webforms
nachdenken, weil ich also ich brauche auf jeden Fall ein paar
Fans für zum einen geben von wenn da nur ein Google Knopf
drauf ist und so weiter und zum Passieren Passwort changen und
so weiter das kann ich mir überlegen ob ich die also wenn
ich das integriert habe dann kann ich diese forms selber
machen hoch customized so wie ich es Bock habe so machen wir
zum Beispiel zum Beispiel oder aber ganz viele Lösungen wie
gesagt bieten vorgefertigte Komponenten an auch für Rect und
so weiter nehme ich halt die und kann die Halt modifizieren,
modifizieren, modifizieren per Logo oder wie auch immer, lass
die so aussehen wie es passt. Kann ich mir überlegen und dann
ganz wichtig. Bei diesem ganzen Authentication
Krams E-Mails heute noch das die Standard Kommunikation für die
ganzen Invites forgot Passwort, Flows und und und und ich brauch
halt E-Mail und E-Mail verification weil die E-Mail ist
mein Nutzername Punkt. Ja E-Mail ist also für für
normale Leute ist die E-Mail der Nutzername würde ich auch gar
nichts anderes machen. Und dann brauche ich halt eine
Art und Weise, das kann ich auch hinterlegen.
Ich brauche halt einen E-Mail smtp Server, der in der Lage
ist. Sehr, wie soll ich sagen, immer
Funktionierend quasi E-Mails rauszuschicken, so ja essentiell
sonst. Was hat die User abgehängt?
Ja und jetzt nehme ich kurz noch auf und dann habe ich so von
meinem Specialist eigentlich alles runter gebetet, wir haben
ja was wichtig ist ist wir wollen ja die Nutzer auch nicht
nerven mit ihrer Eingabe vom Usernamen und Passwort, außerdem
ist das ein kritischer Prozess wenn ich ein Passwort eintippe,
das will ich so wenig wie möglich machen, ich will
eigentlich mit dem Passwort nicht.
Arbeiten, weil das ist ein kritischer Prozess, weil
potenziell immer. Sind gelauscht werden könnte
oder sowas oder? Ja, einfach bald?
Nee, einfach weil der, weil das Datum, was ich eingebe, nämlich
das Passwort, das Kritischste ist ja was du hast, ja.
Und weil Leute, wir, weil wir wissen, dass viele Nutzer ihr
Passwort vielleicht an mehreren Stellen das Gleiche benutzen und
so weiter und sofort ja. Ist einfach n Kritisches einfach
einfach nen sensitives Stück Information.
Ja was du so wenig wie möglich anfasst, Punkt ja.
Einfach am Sicherheitssprech so. Ja je weniger du das eintippen
musst und damit verhandeln musst, desto sicherer.
Ja, so und deswegen gibt es Tokens, ja, und das will ich
einfach noch mal sagen, weil das war für mich auch noch ne
Erkenntnis, welche Tokens gibt es eigentlich in der modernen,
in der modernen Welt, ja? Also wenn du einmal dein dein
klar initial musst du irgendwo mal n Usernamen Passwort
eingeben. Ja und dann wird dieses Username
Passwort getauscht gegen den Access Token.
Access Token, so heißt es ja. Das Access Token ist ein
sogenanntes J Double UT TOKEN, EIN JSON Web Token.
Was das ist, könnt ihr euch später angucken, haben wir
vielleicht immer ne Folge, ja. Dieses Access Token hat ne kurze
Lebensdauer. Kurz heißt zwischen sowas wie 30
Minuten oder 3 Stunden. Das ist typischerweise so dieses
Session ja. Dann läuft das ab.
Dann wirst du rausgeschmissen und musst dich quasi wieder dein
Passwort eintippen. Ist die eine Variante, oder?
Aber, und jetzt gibt es ein zweites Token, das sogenannte
Refresh Token, ne das Refresh Token kann man sich vorstellen
wie ein anderes Passwort, das ist schon fast auf der Ebene, es
passt ist auch kein J Double UT Token das Refresh Drucken ist
einfach ein langer generierter String.
So, der lebt nicht 30 Minuten und auch nicht 3 Stunden, der
hat typischerweise ne Lebenszeit von viel länger irgendwie ne
Woche n Monat ein Jahr kann man sich aussuchen, so ja.
So und das Refreshtoken, das darf auch im, das darf sogar
auch im Browser gespeichert werden.
Ne das das würd ich sagen damit ne also die das Passwort nicht
ja das Passwort auch verschlüsselt, das ist wichtig
ja das liegt, das kennt keiner, ja außer der Nutzer ja ne
Datenbank wird das verschlüsselt abgelegt.
Und dann arbeitest du mit dem Access Token für den
kurzfristigen Zugriff. Und wenn der alle ist, dann
holst du dir mit dem Refresh Token ein neues Access Token.
Klingt irre, ist aber Standard. Und dann muss ich mich
zwischendurch, also was, was ist für den Nutzer, muss ich mich
nicht wieder, also muss ich nicht wieder mein Passwort und
Usern eingeben. Nein, wenn du.
Einfach eingeloggt, aber im Hintergrund passieren diese
Prozesse. Passieren wilde Dinge?
Genau das kriegst du alles nicht mit.
Ja, deswegen sage ich immer Authentication, das sieht
einfach, wenn es gut läuft, hast du selber gesagt, Gerrit, dann
ist das irgendwie kommt es nicht vor, aber.
Im Hintergrund werden Refresh Stokes gegen Access Tokens
getauscht und so weiter und sofort.
Ja, ich könnte Buch schreiben, Refresh Tokens machen wir aber
nicht. Jetzt gibt es ja noch die
Möglichkeit, beim Login bei vielen Seiten zu sagen, Remember
Me oder Remember Me on this device oder in this Browser.
So, da kann ich dann quasi bestimmen, ob ich mich beim
nächsten Mal noch wieder authentifizieren muss oder
beziehungsweise authentifizieren muss ich mich immer.
Die Frage ist nur wie ob ich wieder mein Passwort.
Brauche das Remember me würde ich sagen.
Ich weiß nicht wie die Leute das machen, weil es gibt halt
wirklich viel Authentication. Gesagt, aber das Remember Me ist
genau das benutze ich refreshtalkings oder nicht.
Wenn ich Remember me anmache und dann sage ich, OK, ich mache
eigentlich also in der modernen O.
Aus 2 Welt, sage ich dann, OK, ich benutze refresh Tokens und
dann kann das sein, dass du n Jahr lang eingeloggt bist.
Ja, je nachdem wie die Policy von der Firma ist und ich
ehrlich gesagt ich bin n Fan davon, weil zum Beispiel wenn
wir mobile Apps haben, es ist ja nichts gruseliges.
Du willst jetzt gerade dein Fahrrad ausleihen und du hast es
eilig und dann sagt dir die blöde App, jetzt muss ich
erstmal dein Passwort eingeben. Ja, das hast du erstens nicht im
Kopf, weil das solltest du auch nicht im Kopf haben und dann
musst du dein Passwort Manager haben, den musst du erstmal auf
dem Telefon haben, dann musst du den sich einloggen, dann will
der auch wieder dein Passwort haben und und und.
Da sind schon die halbe Stunde rum bis du dich da angemeldet
hast. Ja, deswegen sage ich immer,
lass die Leute doch eingeloggt so ja von der UX.
Aber es gibt halt mit diesen Refresh Tokens einen sauberen
Weg um festzustellen, dass es auch sauber ist.
Denn vor allen Dingen man kann. Mittracken das ist wichtig.
Das Refresh Tocken ist ja ein bestimmtes Token und das kennt
man in der quasi in der hinteren liegenden Welt.
Und wenn jetzt das Refresh Token zweimal benutzt würde oder von
einem anderen gleichzeitig, dann kann man schon gleich die Hände
hoch sagen und hier ist irgendwas gequietscht, so ist
irgendwas komisch. Jetzt muss man vielleicht sagen,
musste ich gerade daran denken. Es gibt natürlich Apps und
Anwendungen, da will ich das auf keinen Fall, also mein Banking
oder mein Broker auf dem Telefon oder auch als Webanwendung, da
läuft auch meist ein Countdown runter, dass man.
Ausgeloggt wird. Und wenn ich jetzt sich mehr
bewegt oder so. Genau, ja, das muss man dann
halt abschätzen, dass man so gegen gegen verschiedene Sachen
ne, aber im Prinzip alles was ich heute erzählt hab, auch
diese, also diese Access Tokens und die Refresh Tokens und
dieses ganze Zusammenspiele, das ist Moderne aus 2 Methodologie
und das ist stand der Technik und das ist auch sicher zu dem
was man bis heute verstanden hat.
Jetzt gibt es noch einen Token das ich noch erwähnen, das ist
nämlich wichtig, da muss man auch einmal kurz drüber
nachdenken wie Fresh und Access Tokens sind halt für unsere
Humanus. Ich hatte ganz am Anfang gesagt,
es gibt ja auch diese kleinen Users, die haben davon nichts,
weil die können sich ne, also die loggen sich ja so nicht ein,
die haben dann sogenanntes Authentication Token, also die
können auch n Passwort haben, aber dann sage ich ich geb es
gibt nen Authentication Token, das ist noch mal anders, ist
aber auch ist kein JW Token ist auch einfach nur ein langer
String der aber nicht verschlüsselt abgespeichert
wird, das ist der Unterschied und die können halt quasi mit so
einem Authentication Token in die Systeme rein, das hat auch
einen Vorteil bei Authentication Tokens können viel schneller.
Also der ganze Validierungsprozess und so
weiter ist viel schneller, weil das nicht encrypted ist.
Encryption und so weiter dauert immer Zeit und bei den Klienten
will ich Speed haben, hinten drin ne, da arbeite ich mit
Authentication Token so. Also es gibt diese 3 Arten von
Tokens, typischerweise Access Refresh und Authentication
Authentication ist quasi sowas wie ein Passwort.
Und damit würde man auch zum Beispiel, es gibt ja bei ganz
vielen Web Diensten auch die Möglichkeit, andere Tools zu
integrieren. Also zum Beispiel kann ich bei
unserem aus unserem Firmenkonto die Transaktionen in Google
Sheets reinschreiben lassen in so eine Tabelle.
Um die, um dann daraus was auch immer zu machen, ja Auswertung
oder so. Ja hab ich dann auch so ne
Authentication Token. Ne, da hast du Access Tokens,
das geht alles über jw. Typischerweise Access Tongue,
weil das also das ist der Austausch zwischen Systemen, das
ist das Schöne, also man hat sich, man hat n Standard
gefunden im O aus 2 und dieses dieses Access Token, dieses JW
Token hat einen standardisierten Aufbau und da sind auch das
standardisiert beschrieben, wer bist du, was ist dein Tenant und
was sind deine Rollen, das ist da quasi alles lokal abgelegt
und normalerweise wird die Verbindung zwischen
verschiedenen Systemen über dieses Access Token gemacht,
über das JW Token ok, dann kriegst du auch sowas wie Single
Sign on hin SSO. Verschiedene Dinge hinweg
basieren alle auf diesem JW Token, auf dem Access Token ne.
Cool, Booker, danke, dann würde ich sagen, kommen wir zum Ende.
Hast du noch? Was letztes zu sagen.
Nö, eigentlich nicht. Man cool ist es, wenn dein
System noch anbietet, dass du beliebige private extra
Informationen, die du vielleicht die irgendwie was mit
Applikationen und Usern haben, noch einfach dazu speichern
kannst. Das gibt es bei Fusion Ows auch,
das fand ich richtig cool, weil dann kannst du noch sowas machen
wie im SARS, kennen wir das auch, Gerrit Pläne also hier
Basic, Enterprise und so weiter und sofort, das willst du ja
auch, typischerweise vielleicht zum Beispiel Antennen dran
klatschen und so weiter da kann man sich genau überlegen und
dann ist es schön, wenn das System flexibel genug ist.
Ja, um da ne sehr speziellen Anforderungen auch noch
irgendwie zu hinterlegen. Ja und das kann man da auch und
das das bei der Auswahl von so einem System glaub ich sollte
man da auch n Auge drauf halten und ansonsten hab ich mir das
hab ich mir die Seele vom Leib gesprochen und kurz mal alles
raus erzählt. Gefühlt einer wieder bisschen
länger geworden als geplant. Ist doch gut.
Gute gute Länge, prima, OK, dann machen wir hier n Deckel drauf
dank dir für den Einblick ins User Management.
Ich fand es richtig spannend heute viel gelernt, dann bis in
2 Wochen ja macht es gut. Macht es gut.
Tschüss aus Hamburg. Einfach komplex wird präsentiert
und produziert von Highsow. Wir freuen uns auf deine Fragen
und deinfeedbackanpodcast@heiseweb.com
vielen Dank fürs Hören dieser Folge bis Dienstag in 2 Wochen
und Tschüss aus Hamburg.