Vom Monolith zu Microservices

[internet]

Hallo,

meine Applikation ist über die Jahre / Monate ziemlich groß geworden, wobei sie nicht produktiv ist
Ich habe eine Applikation, die u.a. folgendes abdeckt:

1. ERP (Rechnungen, Angebote, Aufgabenverwaltung, Materialverwaltung, Reisekostenberechnung, Projektverwaltung, Anfrageverwaltung....)
2. Personalsuche
3. Projektweitergabe
4. Materialsuche weltweit

Alles läuft aktuell in einer WebApp (JSF, JAVA EE) - Applikation und in einer Datenbank. Das Ganze ist mandantenfähig aufgebaut.
Im ERP hat quasi jeder Mandant seinen eigenen Bereich (Eigene Angebote, Rechnungen, Aufgaben usw.).
Hier spiele ich gerade auch mit dem Gedanken pro Mandant (Kunde) auch ein eigenes Datenbank- Schema zu haben (siehe auch anderer Thread).

Die rotmarkierten Services (Personalsuche, Projektweitergabe, Materialsuche) sind Services, die übergreifend sind.
Also ein Mandant kann Personal bei anderen Mandanten anfragen oder Material von anderen Mandanten ausleihen.

Nun überlege ich aber das Ganze zu trennen. Mir schwebt vor dann eben 4 WebApps zu haben für die oben aufgeführten Services. Wobei das ERP System weiterhin das "führende System" sein soll. Theoretisch könnte man dann die jeweilige Applikation auch Standalone betreiben. Also eigene Weboberfläche für Personalsuche, Projektweitergabe, Materialsuche....

Was ich nun aber nicht ganz verstehe:

Vom ERP System (also mehr oder weniger die "führende Applikation", muss ich natürlich entsprechend auf 2,3,4 (rotmarkiert) zugreifen können.
Aktuell stelle ich mir also vor die Controller - Klassen umzubauen, sodass die Daten aus den verschiedenen Datenbanken kommen.
D.h. ich stelle bei 2,3,4 entsprechende REST - Services zur Verfügung.
Soweit so gut.

Nun aber:

1. Wie sieht der Login zu 2,3,4 aus? Ich habe auf der Seite vom ERP einen Mandanten mit einer ID und nun brauche ich wiederum einen User jeweils in 2,3,4, welcher ich wiederum verwende um einen Webservice Call durchzuführen, sodass die jeweilige App weiß, dass ich es auch bin.

Vorstellen könnte ich mir dann, dass ich jeweils eine Tabelle in der jeweiligen Applikation habe:

ERP:
ExternalApp Tabelle

• ID
• APIKey (API Key)
• AppType (Personalbörse...)
• MandatoryFK

Personalsuche
ApiKey Tabelle

• ID
• APIKey (API Key)
• CompanyFK

Mache ich jetzt einen Webservice Call gegen die Personalsuche - App, gebe ich im Request Header einfach entsprechend den API Key mit und bin somit authorisiert.

2. Wie sieht die Implementierung der Web - GUI aus? Die JSF - Seiten müssen ja dann immer noch in der ERP - Applikation sein, die ich bisher implementiert habe? Die Controller - Klassen greifen dann eben nicht mehr auf die Datenbank vom ERP zu, sondern per REST Webservice.
Ausgenommen sind Adminseiten für die Personalbörse etc., die können dann direkt in 2,3,4 sein.

Ist das so ein korrektes Vorgehen?

 

[KonradN]

Wie sieht der Login zu 2,3,4 aus?

Du hast eine Stelle, der alle Services vertrauen. Dort meldet der User sich an und bekommt ein Token. Mit diesem Token kann er dann auf alle Webservices zugreifen.

Das kann z.B. mit Keycloak gemacht werden.

Da besteht also nicht die Notwendigkeit, irgend etwas selbst zu bauen zumal es in dem Bereich so viele Angriffsvektoren gibt: Da will man nicht wirklich selbst etwas bauen so das nicht eben genau das Spezialgebiet von einem ist. Und damit nutzt Du dann einen OAuth2 / open-connect Mechnismus (Als eine Möglichkeit. Keycloak bietet mehrere Provider an....)

Und bei Microservices trennst Du die Verantwortlichkeiten auf. ERP und User Management / Login sind doch auf jeden Fall zwei getrennte Verantwortlichkeiten und sollten daher getrennt werden.

 

[LimDul]

Stichwort wäre hier Single-Sign-On über OAuth2, wie z.B. Keycloak. Der User wird gegen Keycloak authentifziert, bekommt dort ein Token. Und mit dem kann er sich in allen anderen Anwendungen authentifzieren (egal ob im UI oder per Rest)

 

[internet]

Stichwort wäre hier Single-Sign-On über OAuth2, wie z.B. Keycloak. Der User wird gegen Keycloak authentifziert, bekommt dort ein Token. Und mit dem kann er sich in allen anderen Anwendungen authentifzieren (egal ob im UI oder per Rest)

Ok, wie sieht das dann datenbankseitig aus?
Wo speichere ich den Token etc.?

 

[LimDul]

Gar nicht. Die werden nur in der Session gehalten.

 

[internet]

Gar nicht. Die werden nur in der Session gehalten.

aber irgendwo muss doch der Token in einer DB abgelegt sein?
Woher soll ich wissen, das Token: 123456789 zum Mandant1 gehört?
Das Ganze Setup ist mir nicht klar

Ich verwende Apache Shiro für die Security in der App, falls diese Info relevant ist

 

[LimDul]

Du brauchst das nicht in der Datenbank - der User sendet das Token. Und mit dem Token über Keycloak bekommst du den Usernamen/userid. Und damit hast den Usernamen/Userid und das ist alles was du brauchst.

Du bräuchtest dann vermutlich kein Apache Shiro mehr, sondern könntest direkt auf OAuth2/Spring Security setzen - aber da schwindet mein Wissen schnell.

Ansonsten hier per Google mal was dazu gefunden: https://dzone.com/articles/how-to-use-apache-shiro-and-oauth-20-to-build-a-se


Grundsätzlich funktioniert OAuth2 wie folgt.

Der User meldet sich mit Benutzer & Passwort bei einem OAuth2 Provider (was hier auch Apache Shiro sein kann, wenn ich es richtig verstehe aus dem Link). Der OAuth2 Provider wiederum sendet dem User ein Token. (Das hat in der Regel auch eine begrenzte Gültigkeit und muss regelmäßig refreshed werden). Mit dem Token wiederum kann er sich bei der eigentlichen Anwendung anmelden - die ist ein OAuth2 Client. Über das Token wird automatisch bei dem OAUth2 Provider die erforderlichen Daten (Username, Userid, Berechtigungen etc.) nachgelesen.

 

[Robert Zenz]

Freundliche Erinnerung: Wenn man einen Monolithen in Microservices zerteilt, hat man immer noch einen Monolithen, dafuer aber mit mehr beweglichen Teilen.

Die Zerteilung wird erst dann interessant wenn die einzelnen Dienste unterschiedlich skalieren (muessen). Also wenn man einen Monolithen mit X, Y und Z hat, diesen dann zerteilt, und die genau 1:1:1 hat man immer noch einen Monolithen der dafuer wenigstens komplizierter ist als vorher. Wenn man den zerteilt und dann im Verhaeltnis 1:12:500 laufen hat, hat man offensichtlich etwas gewonnen.

Alernativ kann man auch eine Trennung nach Teams machen, also wenn man wirklich drei 5-Personen Teams hat, kann es auch hilfreich sein diese abzutrennen in einzelne Dienste. Arbeitet man alleine auf dem Monolithen, ist der Monolith nicht unbedingt schlecht.

 

[internet]

Du brauchst das nicht in der Datenbank - der User sendet das Token. Und mit dem Token über Keycloak bekommst du den Usernamen/userid. Und damit hast den Usernamen/Userid und das ist alles was du brauchst.

und woher kommt dann das Token aus der ERP - App? Das Token muss doch irgendwo gespeichert sein?
Oder wird das Token generiert, wenn der User sich mit Username / Passwort anmeldet?

Wie kann ich mir den OAuth2 Provider vorstellen? Ist dann eine Standalone Software?

 

[KonradN]

Keycloak (Oder was auch immer du nutzt) hat natürlich eine Datenbank und in der ind die User und ihre Zuordnung gespeichert. Und die wichtigen Informationen sind in dem Token dann gespeichert. Daher brauchst Du auf den Zielsystemen nichts darüber zu wissen.

Die Zielsysteme kennen und vertrauen dem System, der die Token ausgibt. Und daher vertraut es den Informationen, die in dem Token stehen (Das Token ist natürlich signiert und kann daher nicht verändert werden). Wenn also in dem Token drin steht: Mandant1, dann ist das Mandant1.

Wie das drin steht, muss man dann sehen. Es gibt Rollen und so. Die Mandanten könnten also entsprechend Rollen sein.

 

[internet]

Puh, also das klingt kompliziert
Für Shiro gibt es wohl auch eine Lib dazu:

GitHub - bujiio/buji-pac4j: Bridge from the pac4j security library to Shiro

Bridge from the pac4j security library to Shiro. Contribute to bujiio/buji-pac4j development by creating an account on GitHub.

github.com

Ich habe gerade mal spaßeshalber diese Demo bei mir installiert: Ich schätze das geht in die Richtung, was ich benötige...

GitHub - pac4j/buji-pac4j-demo: Shiro webapp using the buji-pac4j bridge and the javaee-pac4j security library

Shiro webapp using the buji-pac4j bridge and the javaee-pac4j security library - pac4j/buji-pac4j-demo

github.com

------------------

Ich habe keine Ahnung, ob ich das richtig verstehe:
Es gibt von Google zB auch eine Schnittstelle, die als OAuth2 Provider dient? D.h. ich melde mich mit meinem Google Account an. Wenn der Login bei Google korrekt ist, erhalte ich Zugriff?

In der shiro.ini finde ich das:

oidcConfig = org.pac4j.oidc.config.OidcConfiguration
oidcConfig.clientId = 167480702619-8e1lo80dnu8bpk3k0lvvj27noin97vu9.apps.googleusercontent.com
oidcConfig.secret = MhMme_Ik6IH2JMnAT6MFIfee
oidcConfig.useNonce = true

googleOidClient = org.pac4j.oidc.client.GoogleOidcClient
googleOidClient.configuration = $oidcConfig
googleOidClient.authorizationGenerator = $roleAdminAuthGenerator

1) Was ist das für eine ClientID und woher kommt diese?

2) Meine Berechtigung (Authorisierung) erfolgt von der App (ERP...). Kann ich das dann dennoch weiter nutzen?

3) Aktuell habe ich User und Passwort. Ist das dann obsolet?

 

[KonradN]

Also wenn Du in Deine Anwendung Dich über Google anmelden können willst, dann ist es bei Web Anwendungen so, dass Du das erst einmal registrieren musst. Denn da kommen dann auch so Dinge mit ins Spiel wie die Adresse, zu der man zurück geleitet wird.

Der Ablauf für Anwender ist dann grob beschrieben so:

• Du gehst auf Deine Webseite. Die verlangt eine Anmeldung bei Google. (Oder generell zu dem Identity Provider)
• Dazu kommt es dann zu einer Weiterleitung zu Google (Es wird also eine Seite vom Identity Provider angezeigt)
• Da meldet sich der User dann an - egal wie. Das kann User / Passwort sein. Google wird bei Business Logins auch noch 2fa Prüfungen machen ... Das ist halt komplett Sache vom Identity Provider
• Wenn man sich anmelden konnte, dann wird man von der Seite des Identity Providers wieder zu der Applikation weiter geleitet - mit dem Token!

Dazu gibt es aber sehr viele Seiten, Videos, ... die das im Detail erklären. Daher wäre es sinnvoll, sich das einmal im Detail anzusehen.

 

[KonradN]

Wie das mit der Google Anmeldung z.B. in Wordpress aussehen kann incl. Beschreibung, wo man was registrieren muss, findest Du hier:
Log in with Google – WordPress plugin | WordPress.org

Das einfach nur als Info, wenn Du das nutzen willst.

Aber Google kennt natürlich keine Mandanten - Du musst also noch einen eigenen UserService haben, der dann weiss, welche Google Accounts zu welchem Mandanten gehören. Hinter einem Google Account steckt auch eine Email Adresse - das könnte eine Verlinkung sein. Wenn es um Geschäftskunden geht, dann kannst Du ggf. Domains von Kunden als Zuordnung nutzen.

 

[internet]

Aber Google kennt natürlich keine Mandanten - Du musst also noch einen eigenen UserService haben, der dann weiss, welche Google Accounts zu welchem Mandanten gehören. Hinter einem Google Account steckt auch eine Email Adresse - das könnte eine Verlinkung sein. Wenn es um Geschäftskunden geht, dann kannst Du ggf. Domains von Kunden als Zuordnung nutzen.

ja und dann wären wir wieder bei der Frage, welche Datenbank - Tabellen benötigt werden

Daher ist die Antwort verwirrend

Du brauchst das nicht in der Datenbank - der User sendet das Token. Und mit dem Token über Keycloak bekommst du den Usernamen/userid. Und damit hast den Usernamen/Userid und das ist alles was du brauchst.

 

[thecain]

Nichts ist da verwirrend in Konrads Beispiel wird ein 3rd Party Dienst verwenden, in LimDuls beispiel betreibst du das selber und hast auch nichts zu mappen.
Aber Grundsätzlich macht es Sinn sich in das Thema genauer einzulesen, wenn man es in einer Software für Kunden einsetzen will. (Das gilt eigtl für alle Themen, besonders Sicherheitsrelevante)

 

[LimDul]

und woher kommt dann das Token aus der ERP - App? Das Token muss doch irgendwo gespeichert sein?
Oder wird das Token generiert, wenn der User sich mit Username / Passwort anmeldet?

Das wird generiert.

Wie kann ich mir den OAuth2 Provider vorstellen? Ist dann eine Standalone Software?

Kann - muss nicht. Das ist ein Stück Software, dass das OAuth2 Protokoll implementiert. Das kann z.B. Keycloak sein, das kann ein Aufsatz auf Microsoft ADFS sein, dass kann ein handgeschriebenes Stück Software sein. Persönlich würde ich Keycloak favorisieren, weil das extrem weit verbreitet ist.


Der OAuth2 Provider ist aus Sicht deiner Anwendung ein Stück Software, dass es dir ermöglicht aus einem Token (mit dem sich der Nutzer bei dir in der Anwendung anmeldet) die Informationen zu diesen Nutzer zu lesen, die der OAuth2 Provider gespeichert. Hostest du ihn selber (z.B Keycloak) kann der Provider bereits sagen "User2 ist auf Mandant 47" berechtigt. Weil du innerhalb von Keycloak die Berechtigungen pflegst.

Nutzt du z.B. Google als OAuth2 Provider, kannst du natürlich nicht in Google die Berechtigungen pflegen. Dann sagt dir Google nur zu dem Token gehört der Google User mit der ID X. Dann musst du bei dir noch eine Datenbanktabelle pflegen wo drin steht "User X ist auf Mandant 47" berechtigt.


OAuth2 sorgt nur dafür, dass du in der Security deiner Anwendung nicht mehr user/password prüfen musst, sondern das du den User geliefert bekommst (indirekt über den Token) und daher auch beim Absprung in andere Anwendungen oder Aufruf von Services kein Passwort schicken musst - sondern nur den Token

 

[KonradN]

ja und dann wären wir wieder bei der Frage, welche Datenbank - Tabellen benötigt werden

Daher ist die Antwort verwirrend

Daher gab es den klaren Hinweis auf einen Identity Provider wie Keycloak. Du setzt einfach einen Container mit Keycloak auf und konfigurierst den. Da musst du nichts mit Datenbanken machen (außer natürlich der Tatsache, dass Keycloak eine Datenbank hat).

Und selbst wenn Du Google nutzen willst als Identity Provider: Da musst Du einfach einmal schauen, was Du da genau bekommst. Und dann kannst Du Dir überlegen, was die Anforderungen sind. Da wir die genauen Anforderungen nicht kennen, kann ich Dir nicht sagen, was da notwendig ist.

Übliche Verfahren, die man diversen Stellen sieht: Du hast eine Anwendung und wenn da eine Anmeldung von einem externen Provider kommt (Google, Microsoft, GitHub, Facebook, .... Was auch immer Du da konfigurieren willst!), dann schaust Du, ob der User bekannt ist. Ist dies nicht der Fall, dann wird ein neues Konto erstellt und mit der Anmeldung verbunden. So kann man ein eigenes Profil haben / pflegen, denn diese ganzen Identity Provider haben darüber ja keinerlei Kenntnis.

Oder - was Du z.B. hier im Forum sehen kannst: Leute müssen manuell eine Registrierung durchführen und können dann nachträglich einen externen identity provider verlinken.

Du kannst da beliebige Use Cases aufstellen, die notwendigen Daten ermitteln und dann entsprechend etwas aufbauen. Damit programmierst Du eine eigene Userverwaltung. Das kann man machen. Aber das ist Aufwand und es bedarf einer Planung.

Oder du gehst - wie schon mehrfach erwähnt - einfach hin und besorgst Dir eine fertige Lösung. Dann musst Du nichts mehr entwickeln. Ein mögliches, freies Produkt ist hier z.B. Keycloak. Sowas ist sehr schön aufsetzbar, es gib viel Dokumentation, viele die davon Ahnung haben und Fragen beantworten, Videos, Tutorials, ....

Aber wie immer: Man muss sich damit beschäftigen! Und das ist kein Thema, bei dem wir Dinge vorgeben können. Das ist ansonsten etwas wie: "Ich möchte eine Verwaltung für meinen Betrieb programmieren. Was für Datenbank Tabellen benötige ich?"
a) Die Anfrage ist nicht konkret genug und du erwartest eine extrem konkrete Antwort
b) Genau das ist die Aufgabe des Software Entwicklers. Anforderungen analysieren und dann entsprechend ein Konzept erstellen.

 

[KonradN]

Was evtl. auch Sinn machen kann ist eine Recherche, ob es für die verwendete Software / Libraries "übliche" Identity Provider gibt. Spring Boot hat z,B. https://spring.io/projects/spring-authorization-server.

Generell ist und bleibt meine Empfehlung aber, dass man sich einen fertigen Identity Provider sucht und den dann nur mit best practices verwaltet. Da ist es dann deutlich erschwert, kritische Security Löcher zu bauen.

Und so lange du keinen Grund hast, Keycloak auszuschließen: Wieso gehst Du da nicht erst einmal drauf zu. Damit hast Du ein solides Fundament, auf dem Du aufbauen kannst. Und auch mit Keycloak kannst Du dann andere Identity Provider mit einbinden, also z.B. erlauben, dass Leute sich mit Google Account anmelden können (https://keycloakthemes.com/blog/how-to-setup-sign-in-with-google-using-keycloak) Aber das sind dann Dinge, die Du später machen kannst.

==> Vermeide, Dich zu verzetteln. Mach einen Schritt nach dem anderen!

 

[internet]

Ich habe jetzt mal rudimentär etwas aufgemalt um mein Vorhaben etwas zu veranschaulichen:

• Das "ERP" ist die Applikation, welches auf die 3 anderen Applikationen zugreifen kann
• Die anderen 3 Applikationen kommunizieren nicht untereinander
  
  
• Jede Applikation kann auch alleine betrieben werden.
  • Das heißt jede Applikation hat User und die User wiederum haben verschiedene Berechtigungen. D.h. in jeder Applikation gibt es Datentank - Tabellen "User", "Permission", "UserPermission", "Rollen"...
  • Jede Applikation hat eine eigene Datenbank (beim ERP könnte man noch darüber nachdenken, ob jeder User seine eigene Datenbank erhält)
    
• Die Idee ist, dass die ERP App einmalig gegen die anderen 3 System connected und dann eben einen User / Zugriff bekommt.
  • Hierzu müsste ich dann vermutlich diese Info in einer Datenbank ablegen wie "UserExternalApi", sodass ich eben ein Mapping zwischen "User" vom ERP und dann den User von den anderen 3 Apps habe.
  • Also sowas wie: UserFK, API_Key, AppName

Ich glaube ich tue mir hier gerade schwer das zu verstehen, da ich zusätzlich den Punkt "Berechtigungen" innerhalb der jeweiligen App habe.
Mir ist immer noch nicht klar, wo ich die Beziehung zu einem Token und dem "User" der jeweiligen App ablege.

Angenommen ich habe diesen Prozess:
Ein neuer Kunde registriert sich beim ERP System und nutzt hier die Facebook Login Möglichkeit.
Was passiert dann im Hintergrund? Vorausgesetzt der User kann sich bei Facebook erfolgreich anmelden?
Nun muss doch in meiner App etwas passieren, wie:

• Neuer User erstellt
• Mapping zu diesem Facebook Token zu diesem User speichern

 

[thecain]

Hast du dich jetzt in OAuth2 eingelesen? Willst du Keycloak einsetzen?

 

[internet]

Hast du dich jetzt in OAuth2 eingelesen? Willst du Keycloak einsetzen?

siehe Post davor.... ich bin mir nicht sicher, ob das für mich passt.... Ich will die Berechtigungen in der Applikation verwalten und nicht irgendwo bei Keycloak

 

[LimDul]

Das heißt, die User können in den verschiedenen System auch anders heißen, andere Passwörter haben etc. Wenn ich als Anwender von a nach b wechsle muss ich mich wieder bei anmelden? Das möchtest du?

 

[LimDul]

Ich habe jetzt mal rudimentär etwas aufgemalt um mein Vorhaben etwas zu veranschaulichen:

Anhang anzeigen 21406

• Das "ERP" ist die Applikation, welches auf die 3 anderen Applikationen zugreifen kann
• Die anderen 3 Applikationen kommunizieren nicht untereinander
  
  
• Jede Applikation kann auch alleine betrieben werden.
  • Das heißt jede Applikation hat User und die User wiederum haben verschiedene Berechtigungen. D.h. in jeder Applikation gibt es Datentank - Tabellen "User", "Permission", "UserPermission", "Rollen"...
  • Jede Applikation hat eine eigene Datenbank (beim ERP könnte man noch darüber nachdenken, ob jeder User seine eigene Datenbank erhält)
• Die Idee ist, dass die ERP App einmalig gegen die anderen 3 System connected und dann eben einen User / Zugriff bekommt.
  • Hierzu müsste ich dann vermutlich diese Info in einer Datenbank ablegen wie "UserExternalApi", sodass ich eben ein Mapping zwischen "User" vom ERP und dann den User von den anderen 3 Apps habe.
  • Also sowas wie: UserFK, API_Key, AppName

Ich glaube ich tue mir hier gerade schwer das zu verstehen, da ich zusätzlich den Punkt "Berechtigungen" innerhalb der jeweiligen App habe.
Mir ist immer noch nicht klar, wo ich die Beziehung zu einem Token und dem "User" der jeweiligen App ablege.

Angenommen ich habe diesen Prozess:
Ein neuer Kunde registriert sich beim ERP System und nutzt hier die Facebook Login Möglichkeit.
Was passiert dann im Hintergrund? Vorausgesetzt der User kann sich bei Facebook erfolgreich anmelden?
Nun muss doch in meiner App etwas passieren, wie:

• Neuer User erstellt
• Mapping zu diesem Facebook Token zu diesem User speichern

Ein Token wird nicht gespeichert. Das wurde bereits mehrfach gesagt. Das ist eh nur 5 Minuten oder so gültig. Mit den Token bekommst du von Facebook eine User ID. Die musst du speichern

 

[internet]

Das heißt, die User können in den verschiedenen System auch anders heißen, andere Passwörter haben etc. Wenn ich als Anwender von a nach b wechsle muss ich mich wieder bei anmelden? Das möchtest du?

Das kommt jetzt drauf an.
Ich sehe zwei Möglichkeiten für den Login

1) Anfrage an API
Logge ich mich beim ERP System an und möchte ein Projekt weiter vermitteln (also per API einen Request auf die "Projektweitergabe" - App), dann soll das ERP System den User nehmen, der initial in einer Mapping - Tabelle o.ä. beim ERP System hinterlegt wurde:

Also sowas wie:
UserExternalAPI

• ID
• Token (Einen API Token, den ich von "Projektweitergabe" mal bekommen habe)
• App (in dem Fall "Projektweitergabe")
• UserFK (Mein User in der ERP App).

In der Projektweitergabe brauche ich ebenfalls eine Tabelle:

APIKey

• ID
• Token
• UserFK (Mein User in der Projektweitergabe App).

2) Absprung von ERP GUI auf Projektweitergabe GUI
Logge ich ich mich beim ERP System ein und möchte zB über einen Button "Gehe zu Projektweitergabe App" in die GUI von Projektweitergabe abspringen, dann sollte das bestenfalls ohne weiteren Login funktionieren.

---------------------------

Jetzt probiere ich das mal zu verstehen wie der Prozess durch einen Facebook Login aussehen würde.
Nochmal: mir ist nicht klar wie der Prozess abläuft und was ich in welcher Applikation speichern muss - aber ich probiere es nun mal:

1) GUI Maske der ERP App für Registrierung. Anstatt eine Emailadresse und Passwort auszufüllen, nutze ich "Facebook login".
In meiner ERP App wird in der Datenbank Tabelle ein neuer User erstellt.
Anstatt Username und Password zu befüllen, fülle ich zwei Felder "AuthProviderUserId" und "AuthProvider".
In "AuthProvider" steht dann "Facebook"
In "AuthProviderUserId" steht eine UserId, die ich beim Request für den Facebook Login zurückbekommen habe.

2) Möchte ich mich nun erneut in der ERP App anmelden, klicke ich wieder FacebookLogin. Ich erhalte wieder den "AuthProviderUserId" zurück. Nun wird aber noch in meiner User Tabelle geschaut, ob es den User nicht schon gibt (= gibt es die AuthProviderUserId in der User Tabelle). Wenn ja wird nicht wieder ein Eintrag in der User Tabelle erzeugt, sondern ich bin eingeloggt und bekomme zusätzlich alle Berechtigungen aus der Tabelle "Permission" für diesen User.

 

[KonradN]

Also zum ersten Teil ist bereits genug geschrieben worden. Da werde ich mich nicht weiter äußern. (Egal für wie bedenklich ich es halte. Du scheinst da etwas aufzubauen, dessen Abläufe Du nicht verstehst. Und das für eine über das Netz erreichbare Software für potentiell sehr viele Kunden ... Das kann nur schief gehen!)

Der Ansatz bezüglich Facebook kann so funktionieren. Aber das geht auch prinzipiell deutlich weiter. Dazu kannst Du einmal bei Facebook lesen, was die da so bieten. Die bieten halt auch, dass die Token bekommst und die kannst Du dann ebenso verwenden. Und da gibt es dann aber auch noch spezielle Dinge wie das token_for_business. Das findet sich aber alles unter https://developers.facebook.com/ - das Erwähnte speziell unter Nutzer über Apps und Seiten hinweg zuordnen - Facebook Login

 

[internet]

Also zum ersten Teil ist bereits genug geschrieben worden. Da werde ich mich nicht weiter äußern. (Egal für wie bedenklich ich es halte. Du scheinst da etwas aufzubauen, dessen Abläufe Du nicht verstehst. Und das für eine über das Netz erreichbare Software für potentiell sehr viele Kunden ... Das kann nur schief gehen!)

Wie gesagt, wenn mal jemand aufzeigen kann, was wie in welcher App gespeichert werden muss und wie dieser Login / Authentifizierungsprozess aussieht.

Aber Google kennt natürlich keine Mandanten - Du musst also noch einen eigenen UserService haben, der dann weiss, welche Google Accounts zu welchem Mandanten gehören. Hinter einem Google Account steckt auch eine Email Adresse - das könnte eine Verlinkung sein. Wenn es um Geschäftskunden geht, dann kannst Du ggf. Domains von Kunden als Zuordnung nutzen.

Wie sollte das aussehen?

OAuth2 sorgt nur dafür, dass du in der Security deiner Anwendung nicht mehr user/password prüfen musst, sondern das du den User geliefert bekommst (indirekt über den Token) und daher auch beim Absprung in andere Anwendungen oder Aufruf von Services kein Passwort schicken musst - sondern nur den Token

Die Berechtigung soll in der jeweiligen App gepflegt wird, nicht in Keycloak

Also wenn Du in Deine Anwendung Dich über Google anmelden können willst, dann ist es bei Web Anwendungen so, dass Du das erst einmal registrieren musst. Denn da kommen dann auch so Dinge mit ins Spiel wie die Adresse, zu der man zurück geleitet wird.

Der Ablauf für Anwender ist dann grob beschrieben so:

• Du gehst auf Deine Webseite. Die verlangt eine Anmeldung bei Google. (Oder generell zu dem Identity Provider)
• Dazu kommt es dann zu einer Weiterleitung zu Google (Es wird also eine Seite vom Identity Provider angezeigt)
• Da meldet sich der User dann an - egal wie. Das kann User / Passwort sein. Google wird bei Business Logins auch noch 2fa Prüfungen machen ... Das ist halt komplett Sache vom Identity Provider
• Wenn man sich anmelden konnte, dann wird man von der Seite des Identity Providers wieder zu der Applikation weiter geleitet - mit dem Token

Soweit habe ich es verstanden. Was aber geschieht nun mit dem Token? Wie mappe ich das gegen meinen User von meiner App, sodass ich eben dessen Berechtigungen bekomme etc. Laut @LimDul wird der Token nicht in der Datenbank gespeichert, sondern die UserId vom AuthProvider.

Grundsätzlich funktioniert OAuth2 wie folgt.

Der User meldet sich mit Benutzer & Passwort bei einem OAuth2 Provider (was hier auch Apache Shiro sein kann, wenn ich es richtig verstehe aus dem Link). Der OAuth2 Provider wiederum sendet dem User ein Token. (Das hat in der Regel auch eine begrenzte Gültigkeit und muss regelmäßig refreshed werden). Mit dem Token wiederum kann er sich bei der eigentlichen Anwendung anmelden - die ist ein OAuth2 Client. Über das Token wird automatisch bei dem OAUth2 Provider die erforderlichen Daten (Username, Userid, Berechtigungen etc.) nachgelesen.

Ok, wenn ich die Emailadresse mittels dem Token erhalte, dann kann ich den User aus der App damit auch laden... wäre ein Ansatz?

 

[LimDul]

Wie gesagt, wenn mal jemand aufzeigen kann, was wie in welcher App gespeichert werden muss und wie dieser Login / Authentifizierungsprozess aussieht.

Was in welcher App gespeichert werden muss hängt davon ab, wie du dein System modellierst.
Und um es noch mal ganz klar zu sagen: Wer auf diesem Level über Datenbanktabellen redet, hat keine Ahnung wovon er redet. Es geht zu diesem Zeitpunkt nicht um Datenbanktabellen oder Attribute. Es geht um Domänen und fachliche Zuständigkeiten. Welche Anwendung ist für was zuständig.

Die Berechtigung soll in der jeweiligen App gepflegt wird, nicht in Keycloak

Lies dich mal genauer ein. Es geht um Authentifzierung. Nicht um Berechtigung. Das sind zwei Konzepte, die komplett getrennt sind - auch wenn sie oft in einem abgebildet werden.

Soweit habe ich es verstanden. Was aber geschieht nun mit dem Token? Wie mappe ich das gegen meinen User von meiner App, sodass ich eben dessen Berechtigungen bekomme etc. Laut @LimDul wird der Token nicht in der Datenbank gespeichert, sondern die UserId vom AuthProvider.

In dem du OAuth2 nutzt. Probier das ganze endlich mal aus, stell dir Keycloak + eine JEE/Spring Boot Anwendung hin, pack einen OAuth Client rein und fertig. Und oh wunder - du bekommst in deiner Anwendung einer UserID & ein Token zu Gesicht, weil die Security der Anwendung als OAuth Client den Lookup macht.



Was dir komplett fehlt, ist eine High Level Perspektive. Kannst du folgende Fragen beantworten:

• Wer soll die Authentifzierung machen?
• Wo liegen die Rollen/Berechtigungen?
• Wo erfolgt die Abrechnung?
• Wo bucht der User neue Systeme zu? (Verwaltungsoberfläche)
• Wo kann man Rollen & Berechtigungen sehen/pflegen?

Mal ein ganz simpler Geschäftsvorfall:
* Anwender hat bisher Materialsuche gebucht und will jetzt Personalsuche dazubuchen. Wo macht er das? Wie ist sichergestellt, dass es eine Abrechnung gibt, dass er einen Überblick hat? In deinem Schaubild gibt es kein System, in dem das passiert. Diese Fragen musst du für eine Microservice Architektur klären. Ansonsten läuft das auf einen Spinnennetz, also einen verteilten Monolithen, raus, der schwieriger zu warten ist als der Monolith vorher.

 

[KonradN]

Ich kriege gerade einen Hass ... ich hatte eine lange Antwort geschrieben und dann mit dem blöden Touchpad wohl irgendwo geklickt und weg war es ... auch nichts als Entwurf gespeichert ... Ich habe da keinen Bock mehr ...

Daher nur einmal ganz in Kürze:
Beschäftige Dich intensiv mit der Materie. Spiele damit herum. Keycloak ist oft genannt worden. Hast Du da mal was aufgesetzt und damit herum gespielt? Und dann entsprechend Dokumentation gelesen und so viele weitere Dinge zur Recherche gefunden wir OAuth2, openid-connect, JWT, ....

Ich sehe massive Probleme, weil die Grundlagen fehlen. Fängt schon an, dass Du "Microservices" haben willst aber dann soll jeder seine eigene User Verwaltung haben? WTF?

Im Augenblick würde ich sagen: Vergiss es. Mach einen Monolithen. Der hat dann auch eine User Verwaltung. Da kannst Du dann Facebook und Co auch integrieren als Anmeldemöglichkeit und gut ist es. Das vereinfacht vieles.

Sobald Du es aufteilen willst: Mache es richtig. Und natürlich hast Du dann einen Service zur User-Verwaltung. Was willst Du sowas auch selbst machen, wenn die Komplexität nicht verstanden wurde und daher Security Probleme extrem wahrscheinlich werden!

Wenn Du Keycloak nimmst und damit rumspielst, dann kannst Du viel machen. Einfache App schreiben mit Anmeldung sollte easy sein (Gibt ja genug Guides egal welche Technologie). Und schon kannst Du spielen. Schau Dir an, was da passiert. Also in den http Request schauen, da den Bearer Token mal kopieren und in jwt.io einfügen zum schauen, was da denn in den Zeichen drin steckt ... all sowas!)

Und Rechte sind natürlich zentral. Was erwartest Du denn? Da kommt ein Kunde mit mehreren Angestellten. Dann habe ich da mein Konto und will Kollegen berechtigen: Dan gehe ich erst nach ERP und vergebe da Rechte ... dann muss ich in "Personensuche" und da auch Rechte vergeben u.s.w.? Ist das Dein Ernst?

Sieh das Token wie einen Zettel. Da steht dann drauf: KonradN darf ERP und Personensuche. Und der Chef hat das unterschrieben. Den Zettel bekomme ich und dann kann ich mit den Zettel herum gehen: ERP zeige ich den Zettel und der lässt mich machen. Ich gehe zu Personensuche und heya - ich darf machen. Ich gehe zu Projektweitergabe und da bekomme ich ein "Du kommst hier nicht rein".
Und der Zettel wird nirgend gespeichert. Ich gehe zum Chef und sage: Ich bin KonradN und ich will den Zettel. Der Chef weiss, was ich darf und schreibt den Zettel und unterschreibt diesen. Und den Zettel bekomme ich. Der wird nicht gespeichert oder so. Ich bekomme den Zettel und kann damit machen, was ich will. Und ich zeige ihn halt vor ....

Das ist der Ablauf wenn man extrem grob drauf schaut. Es gibt noch Erweiterungen. So steht auf dem Zettel, wie lange er gültig ist. Evtl. bekomme ich auch einen zweiten Zettel, den ich nutzen kann, um den ersten zu erneuern. All so Spielchen. Aber das Gute ist: Das ist 08/15 Kram. Du hast fertige Implementierungen und die machen das schon. Du musst Dir also keine Gedanken machen, wie du so einen Zettel implementieren, signieren, Signatur prüfen, .... kannst.

Und wenn Du Microservices verwendest, dann musst Du nur den User Service anpassen, wenn plötzlich noch andere Autorisierungen dran kommen. Du musst ggf. keinen User Service schreiben, wenn Du Keycloak hast und das ausreicht. Und vor allem: Es ist möglich, gewisse Dinge zu konfigurieren: Ein großer Konzern kann kommen und sagen: Meine Mitarbeiter sollen alle sich anmelden können (um z.B. im "ServiceDesk" Modul ein Ticket zu erfassen. Und der hat keine Lust zig-Tausend User anzulegen. Aber er hat ein Identity Management System und das kannst Du konfigurieren. Schon kann man sich auch damit anmelden. Und ggf. kommen Berechtigungen darüber mit, die Du dann noch mappst auf Deine Berechtigungen. Dann kann der Konzern seine bisherigen Prozesse verwenden um Berechtigungen zu vergeben ... Da gehen also echt geniale Dinge ....

Aber das ändert nichts daran: Du solltest damit spielen um da langsam rein zu kommen.

 

[mihe7]

Gehen wir mal von einer idealen Welt mit ehrlichen Menschen aus. Dann könntest Du eine Tabelle für das Benutzerprofil anlegen mit E-Mail-Adresse, Mandant, Namen usw.

Man bräuchte kein Passwort, würde einfach sagen: hey, ich bin der Benutzer mit der E-Mail-Adresse soundso und gut ists. Problem ist, dass es auf der Welt nicht so läuft, also muss die Angabe des Benutzers überprüft werden. Heißt: wir haben eine weitere Tabelle, in der wir die E-Mail-Adresse (als Benutzernamen) und das Passwort speichern. Der Benutzer authentisiert sich gegenüber dem System somit mit Benutzername und Passwort und das System authentifiziert die Angaben. Die Tabelle wird also nur dafür benötigt, um sicherzustellen, dass der Benutzer derjenige ist, der er vorgibt zu sein.

Das geht aber natürlich auch anders, indem ein Dritter, dem ich vertraue, mir versichert, dass es sich um die "Person" handelt. Und nichts anderes ist das Token: ein "Papier", dessen Angaben ein Dritter bestätigt.

Heißt in der Regel: Du schmeißt die Benutzer/Passwort-Tabelle raus, weil Du die Prüfung nicht mehr selbst machst. Stattdessen bekommst Du ein Token, das den Benutzernamen enthält (und Du nicht nochmal überprüfen musst) -> Thema erledigt.

 

[Oneixee5]

Ich habe jetzt mal rudimentär etwas aufgemalt um mein Vorhaben etwas zu veranschaulichen:

Anhang anzeigen 21406

• Das "ERP" ist die Applikation, welches auf die 3 anderen Applikationen zugreifen kann
• Die anderen 3 Applikationen kommunizieren nicht untereinander
  
  
• Jede Applikation kann auch alleine betrieben werden.
  • Das heißt jede Applikation hat User und die User wiederum haben verschiedene Berechtigungen. D.h. in jeder Applikation gibt es Datentank - Tabellen "User", "Permission", "UserPermission", "Rollen"...
  • Jede Applikation hat eine eigene Datenbank (beim ERP könnte man noch darüber nachdenken, ob jeder User seine eigene Datenbank erhält)
• Die Idee ist, dass die ERP App einmalig gegen die anderen 3 System connected und dann eben einen User / Zugriff bekommt.
  • Hierzu müsste ich dann vermutlich diese Info in einer Datenbank ablegen wie "UserExternalApi", sodass ich eben ein Mapping zwischen "User" vom ERP und dann den User von den anderen 3 Apps habe.
  • Also sowas wie: UserFK, API_Key, AppName

Ich glaube ich tue mir hier gerade schwer das zu verstehen, da ich zusätzlich den Punkt "Berechtigungen" innerhalb der jeweiligen App habe.
Mir ist immer noch nicht klar, wo ich die Beziehung zu einem Token und dem "User" der jeweiligen App ablege.

Angenommen ich habe diesen Prozess:
Ein neuer Kunde registriert sich beim ERP System und nutzt hier die Facebook Login Möglichkeit.
Was passiert dann im Hintergrund? Vorausgesetzt der User kann sich bei Facebook erfolgreich anmelden?
Nun muss doch in meiner App etwas passieren, wie:

• Neuer User erstellt
• Mapping zu diesem Facebook Token zu diesem User speichern

Ich sehe hier keine Microservices, das sind einfach lose gekoppelte Module. Zusätzlich kann man sich das viel leichter machen, wenn die Benutzerverwaltung auch ein Modul wäre. Dann müsste man die Daten nicht 4 mal vorhalten.

 

[internet]

Ich sehe hier keine Microservices, das sind einfach lose gekoppelte Module. Zusätzlich kann man sich das viel leichter machen, wenn die Benutzerverwaltung auch ein Modul wäre. Dann müsste man die Daten nicht 4 mal vorhalten.

Du hast Recht - ich denke der Begriff "Microservice" ist nicht ganz genau hier.
Ich möchte das Projekt entkoppeln, sodass ich nicht mehr ein rießen Projekt habe, sondern eben die 4 oben genannten.
D.h. jedes Projekt kann theoretisch auch eigenständig laufen und hat auch seine eigene Benutzerverwaltung.

Klar, ich könnte nun ein Microservice "Benutzerverwaltung" haben, in der ich dann eben die Daten für alle 4 Applikation vorhalte.
Dann habe ich aber zu viele Abhängigkeiten.

Zu Keycloack:
-> Ich habe das nun mal installiert und ich bin schwer begeistert.

Dennoch habe ich nun ein paar Verständnisfragen, insbesondere die Verbindung zu meiner Applikation.

Was ich nun verstanden habe:
1) Ich habe mit Keycloack einen Authprovider, in dem ich meine ganzen User habe. Sprich das ist eine Datenbank, die mir sämtliche User vorhält. Daneben könnte ich eben auch Social Login über Keycloack anbieten.

Was ich bisher nicht verstehe:

1) Login / Registrierungsseite
Ich brauche dann keine eigene Login / Registrierungsseite mehr?
Es gibt von Keycloack ja auch eine eigene LoginPage / Registrierungsseite. Die URL wäre dann aber die Adresse von Keycloack und nicht die von meiner App?
Wenn sich ein neuer User in meiner App nun registrieren möchte, dann ruft er diese Seite auf:

http://localhost:9009/auth/realms/myapp/protocol/openid-connect/auth?client_id=account-console&redirect_uri=http%3A%2F%2Flocalhost%3A9009%2Fauth%2Frealms%2Fmyapp%2Faccount%2F%23%2Fsecurity%2Fsigningin&state=bdf10edf-dffb-4738-a14e-fd2fedb5127a&response_mode=fragment&response_type=code&scope=openid&nonce=8b9610d5-9165-4c96-8d8a-406eae92da81&code_challenge=n_RQM7wEyoVeGvl7Y1nb1HRbszhpLV6-KRZ_waMisC4&code_challenge_method=S256

Ich habe diese Einstellung:


Muss ich hier aber nicht meine App noch angeben:
localhost:8080/myapp ?

2) Wie funktioniert der Prozess der Registrierung zu meiner App?
Wenn sich ein neuer User in meiner App anmelden möchte, kann ich ihn auf die Registrierungsseite von Keycloack leiten. Der User füllt das Formular aus und der User wird in der Datenbank von Keycloack erstellt.
Das passt auch soweit alles.
Was ich nun aber nicht verstehe: wie ist nun der Prozess zu meiner App?
Meine App muss ja nun irgendwie mitbekommen "Hey, hier ist nun ein neuer User, erstelle mir nun diverse Dinge in der Datenbank".
Wie passiert das? Was muss ich implementieren... ?

3) Zuordnung in meiner App?
Um den User in meiner App zu identifizieren, benötige ich doch nun eine Mapping - Tabelle? Also sowas wie:

User:

• ID
• Email

4) Loginprozess
Wie funktioniert der Loginprozess? Mittels der Loginform von Keycloack kann ich mich ja versuchen zumelden. Wenn ich es richtig verstehe, dann läuft das so, dass ich eben meine Logindaten eingebe und dann auf eine definierte Zielseite zurückgeschickt werde (zB meiner Startseite der App für eingeloggte User).
Das ganze besagt ja nur, dass ich berechtigt bin. Nun geht es aber über die Authorisierung. Jeder User in meiner App kann ja wiederum andere Berechtigungen haben. Wie werden nun die Berechtigungen des Users geladen? Kommt hier dann Apache Shiro (in meinem Fall) zum Einsatz?

5) Loginprozess (in Keycloack vorhanden, aber in App nicht)
Dieser Prozess ist mir auch nicht klar. Bspw. habe ich einen User erstellt in Keycloack. Der User könnte nun auf die Loginseite gehen und sich erfolgreich authentifizieren. Nun gibt es aber keine Zuordnung in meiner App. Hier müsste ich doch den User in meiner App dann wieder neu erstellen.
Geht das so: dass ich Keycloack dazuzwinge immer auf eine bestimmte URL meiner App nach erfolgreichem Login umleite?
Beim Aufruf dieser URL wird eine Backend - Methode ausgeführt und geprüft, ob der User in meiner User - Tabelle der App vorhanden ist oder nicht.
Wenn ja, dann Weiterleitung auf die Startseite
Wenn nein: Weiterleitung auf die FirstLogin Page. Hier werden dann Dinge abgefragt, wie "Branche, Anzahl Mitarbeiter...."

 

[mihe7]

OpenID Connect

OAuth 2.0 hat sich als Standard für die Autorisierung von API-Zugriffen im Web etabliert. Wer es auch zum Login einsetzen wollte, war bisher auf anbieterspezifische Erweiterungen angewiesen. Mit OpenID Connect gibt es jetzt einen neuen Standard, der OAuth 2.0 um alle notwendigen Funktionen für...

www.heise.de

 

[Apologet]

Huhu @internet , der User (Name, E-Mail usw.), die Berechtigungen des Users und schlussendlich auch der Token müssen natürlich irgendwo gespeichert werden, also in einer Datenbank. Der Vorteil bei der Verwendung eines Drittdiensts ist nur, dass du den Login nicht mehr selber gegen unterschiedliche Angriffsvektoren sichern musst ... Die in der Datenbank hinterlegten Userdaten müssen natürlich sicher sein.

Der Aufwand ist also etwas mehr, dafür ist die Sicherheit (und Spamschutz) aber etwas höher.

 

[thecain]

Wieso sollte der Token gespeichert werden müssen?

 

[KonradN]

und schlussendlich auch der Token müssen natürlich irgendwo gespeichert werden

Nein, ein Token muss nicht in einer Datenbank gespeichert werden. Das ist auch relativ sinnfrei, da die Gültigkeit in der Regel relativ kurz ist.

 

[Apologet]

Er muss natürlich gespeichert und zur Verfügung stehen. Heute wieder Bullshit Tag?

 

[thecain]

Scheint so, ist die mal wieder ein neuer Username eingefallen...

 

[Apologet]

Der Service muss natürlich wissen und sich merken, welcher Token eine Berechtigung für den jeweiligen (Sub)Service hat oder nicht. Das ist trivial. Aber ihr könnt natürlich gerne ein bisschen Kindergarten spielen.

 

[KonradN]

Du hast von einem Speichern in einer Datenbank gesprochen. Und wir haben bereits mehrfach im Thread geschrieben, dass so ein Token eben nicht in die Datenbank gehört.

Vom ganzen Ablauf her macht es auch gar keinen Sinn. Wer soll es denn in eine Datenbank schreiben?

• Der Aussteller? Für den ist es doch uninteressant.
• Der es bekommen hat? Der will doch einfach nur Zugriff auf irgend eine Ressource und dazu verwendet er dann das Token. Klar, wenn man ggf. mehrere Dinge damit machen muss, dann speichert man es innerhalb der Anwendung. Das ist dann aber in der Regel eine einfache Variable.
• Der Verwalter der Resource interessiert es nur in so fern, als das er die Signatur und den Inhalt prüft. Danach ist das Token uninteressant.

Der Service muss natürlich wissen und sich merken, welcher Token eine Berechtigung für den jeweiligen (Sub)Service hat oder nicht.

Nein, muss er eben nicht. Der Service (der also die Ressourcen verwaltet) muss nur wissen, wem er vertrauen muss.
Das ist wie: Du vertraust Deiner Mami. Wenn jemand nun. mit einem Zettel kommt, auf dem Deine Mami geschrieben hat, dass Du etwas machen sollst, dann prüfst Du die Signatur und dann vertraust Du der Mami und machst, was da auf dem Zettel steht.

Der Zettel selbst ist daher nur zur Prüfung interessant. Und das war es dann. Das Token selbst muss da nicht vorliegen.

Edit: Es muss also. nicht vorab vorliegen (In einer Datenbank oder so), ehe der Client sich meldet. Der Client, der auf die Ressource zugreifen möchte, muss natürlich das Token mitgeben und damit liegt zur Prüfung natürlich das Token vor. Das war also evtl. etwas missverständlich ausgedrückt.

 

[Apologet]

Nein, muss er eben nicht. Der Service (der also die Ressourcen verwaltet) muss nur wissen, wem er vertrauen muss.

Das kommt aufs gleiche raus.

 

[Apologet]

Der Client, der auf die Ressource zugreifen möchte, muss natürlich das Token mitgeben und damit liegt zur Prüfung natürlich das Token vor

Natürlich liegt der Token vor. Der Service muss den Token aber "kennen" resp validieren, sei's durch das Ablegen in der Datenbank oder im Zwischenspeicher ...

Aber du bist wieder etwas schwer von Begriff ... macht nix.

 

[KonradN]

Das kommt aufs gleiche raus.

Nein. es ist ein großer Unterschied, ob ich

• etwas verifiziere, in dem ich schaue, ob mir (auf irgend eine sichere Art und Weise) eine Version zuvor mitgeteilt wurde. Ich schaue also in der Datenbank, ob ich so ein Token habe
• etwas über den Inhalt verifiziere, also ob es mit einem private Key signiert wurde, ob die Daten formal richtig sind, ...

Bei Erstem bräuchte ich das Token (Nur wie soll ich es sicher bekommen? Ist etwas dubios) und bei zweitem will ich das Token nicht speichern oder so.

Aber der Prozess wurde hier mehrfach im Detail erläutert. Wieso muss man sowas immer wieder wiederholen? Kannst Du nicht einfach den Thread aufmerksam lesen?

 

[Apologet]

• etwas über den Inhalt verifiziere, also ob es mit einem private Key signiert wurde, ob die Daten formal richtig sind, ...

Bei Erstem bräuchte ich das Token (Nur wie soll ich es sicher bekommen? Ist etwas dubios) und bei zweitem will ich das Token nicht speichern oder so.

Wie die (verschlüsselte) Übertragung geschieht, ist doch egal. Der Service muss den Token beim Drittdienst erfragen und ggf. zwischenspeichern. Da geschieht keine "Magic".

 

[KonradN]

Natürlich liegt der Token vor. Der Service muss den Token aber "kennen" resp validieren, sei's durch das Ablegen in der Datenbank oder im Zwischenspeicher ...

Aber du bist wieder etwas schwer von Begriff ... macht nix.

Ich habe es - deutlich vor Deiner Antwort - spezifiziert. Denn wenn man die Aussage aus dem Kontext reisst (So wie Du es gerade machst), dann kommt genau sowas dabei raus.

Und das ganze nur, weil Du einen Fehler nicht eingestehen kannst? Oder hast Du den Prozess, der angewendet wird, immer noch nicht verstanden? Aber ganz offensichtlich hast Du noch nie irgend einen Service über Token abgesichert. Sonst wüsstest Du doch, wie ei Service mit Spring Boot, Quarkus, ... per oauth2 / openid-connect / ... funktionieren würde. Dann wüsstest Du, dass da keine Datenbank mit Token ist...

Aber wir haben genug geschrieben denke ich mal. Weitere Diskussionen sind sinnlos, da Dein Account mit allen Posts vermutlich eh in wenigen Stunden verschwunden sein werden ...

 

[Apologet]

Ja, Majestätsbeleidigung... Verzeihung, eure Hoheit...

 

[KonradN]

Wie die (verschlüsselte) Übertragung geschieht, ist doch egal. Der Service muss den Token beim Drittdienst erfragen und ggf. zwischenspeichern. Da geschieht keine "Magic".

Nein, hier ist vieles nicht egal. Schon Deine Begriffswahl ist nicht egal. Was genau meinst du, wenn Du von "Service" redest? Ich habe zuvor mal unterstellt, dass es der Ressource Server wäre. Aber der fordert kein Token irgendwo an. Das würde der Client machen. Und zwar beim Authorization Server

Nur als schnellen Überblick, was da die Player sind und wie diese kommunizieren:

OAuth2 Authentifizierung – MoodleDocs

docs.moodle.org

Ausführlicher wird es in den entsprechenden RFCs beschrieben, aber so tief muss man ja gar nicht rein. Und wenn es um Token geht, dann ist jwt.io wohl die beste Quelle, denn das wird heutzutage meist verwendet: JSON Web Token Introduction - jwt.io

Aber damit bin ich dann raus. Es ist alles gesagt worden. Und von Tobias kommt ja nur noch Quatsch...

 

[Apologet]

Und ja, ich habe das schon selber umgesetzt.

 

[KonradN]

Und ja, ich habe das schon selber umgesetzt.

Dann hast Du ganz offensichtlich einfach etwas genutzt ohne zu verstehen, was da passiert. Ist nichts Schlimmes - bei Anfängern findet man das oft.

 

[Apologet]

Was genau meinst du, wenn Du von "Service" redest? Ich habe zuvor mal unterstellt, dass es der Ressource Server wäre. Aber der fordert kein Token irgendwo an. Das würde der Client machen. Und zwar beim Authorization Server

Der Service ist der eigene Akteur, also der eigene Server; der Drittdienst ist die Authentifizierungsstelle. Der Client meldet sich beim Drittdienst, der prüft den Login und sendet einen Token an den Client, der Client sendet den Token an den Service/Server, der Server muss dann notgedrungen beim Drittdienst "nachfragen" oder der Token ok ist; also wird dieser vom Service/Server zwischengespeichert.

 

[KonradN]

Da kommen wir dann zu einer Fachlichkeit, die hier im Thread noch nicht angesprochen wurde. Daher äußere ich mich da auch noch einmal zu.

der Server muss dann notgedrungen beim Drittdienst "nachfragen" oder der Token ok ist; also wird dieser vom Service/Server zwischengespeichert.

Nein, da der Drittdienst (Das ist der Authorization Server) das Token signiert hat und der Server (Ressource Server) den public Key des Authorization Servers kennt bzw. vertraut ist eine Nachfrage eben nicht notwendig.

Es wird bei OAuth2 / OpenID-Connect geprüft:

• Token Type (z.B. Bearer Token, MAC Token, ....)
• Signatur wird geprüft
• Dann werden die claims des Token geprüft (Wer hat es ausgestellt, wie lange ist es gültig, ab wann ist es gültig, Zielgruppe, ...)
• Optional: Es kann eine Revocation List geprüft werden.
• Optional: Scope Prüfungen

Die Revocation List ist nur in Fällen interessant, in denen lange gültige Token ausgegeben werden. Also wenn ich ein Token ausstelle, das sehr lange gültig ist, dann möchte ich dies wiederrufen können. Dazu muss aber das Token selbst nicht gespeichert sein (auf dem Authorization Server). Das läuft rein über den Token Identifier. Optional können natürlich auch noch weitere Daten des Token gespeichert werden wie User Identifier, Client Identifier, Expiration Date, ...)

Das einfach einmal auf die Schnelle und in ganz kurz zu der Prüfung des Token.