Laden...

ASP.NET WebAPI - Untersch. Datenbanken pro Anwendung zum Autorisieren benutzen

Erstellt von Rioma vor 8 Jahren Letzter Beitrag vor 8 Jahren 1.694 Views
R
Rioma Themenstarter:in
228 Beiträge seit 2013
vor 8 Jahren
ASP.NET WebAPI - Untersch. Datenbanken pro Anwendung zum Autorisieren benutzen

Hallo zusammen,

ist es möglich unter bestimmten Umständen die Autorisierung auf einer 2ten Datenbank zu machen?

Verwendet werden die BearerToken über OAuth2.

Zum Beispiel über einen Parameter im TokenEndpointPath, oder einen 2ten Endpoint?

Gegen welche Datenbank autorisiert werden soll, entscheidet der Client.

Leider habe ich bisher keine Hinweise dazu gefunden.

Danke euch 😃

EDIT: Theoretisch muss nur die Datenbank-Connection ausgetauscht werden, der Rest ist identisch.

16.806 Beiträge seit 2008
vor 8 Jahren

Fragen wie "ist es möglich" können generell immer mit Ja beantwortet werden - hab ich Dir glaub schon mal gesagt. 😉

Die Frage hier ist viel eher, ob das mit den Boardmitteln geht - und das kann in diesem Fall mit Nein beantwortet werden.
Das müsstest Du selbst implementieren.

Dass ein Client die Quelle für die Authorisierung auswählen darf hört sich zudem sehr komisch an.

2.207 Beiträge seit 2011
vor 8 Jahren

Hallo Rioma,

meinst du "Eine zweite Datenbank zum Autorisieren benutzen" oder meinst du "Zwei Datenbanken zum Autorisieren benutzen?"

es ist in modernen Applikationen sogar so gedacht, dass man das Token von einem "externen" Server bekommt und die Resource dann mit dem ausgestellten Token arbeitet.

Decouple OWIN Authorization Server from Resource Server

zeigt das entkoppeln ja auch. Falls du das meinst.

Dass der User aber wählen kann gegen welche Quelle er sich autorisieren will ist mir, bis auf external Logins, wo man eben Yahoo, MS, Facebook etc. wählt, nicht bekannt.

Gruss

Coffeebean

R
Rioma Themenstarter:in
228 Beiträge seit 2013
vor 8 Jahren

Danke erstmal für die Antworten.

Nicht der User direkt wählt aus, sondern die jeweilige Client-Anwendung.

Anwendung 1 --> DB1
Anwenung 2 --> DB2

Der Rest ist identisch.

Zurzeit ist der Authorization-Server nicht ausgelagert. Das sollte Allerdings kein Problem darstellen.
Da die Logik gleich ist und sich nur der Connection-String ändert, würde ich auch gerne bei einem Authorization-Server bleiben.

Hättet ihr vielleicht einen Tipp, wie das ganze bewerkstelligt werden kann?

A
350 Beiträge seit 2010
vor 8 Jahren

Hi,

das musst du mir erklären : Ihr nutzt OAUTH2 um euch zu Authorisieren.
Gut.
Wo und warum musst du dich aber nochmal Authorisieren?

Ich versteh denn Sin dahinter nicht ganz 🤔

2.207 Beiträge seit 2011
vor 8 Jahren

Hallo Ahrimaan,

er will sich nicht zweimal Authorisieren.

Je nach Client will er DB1 oder DB2 fragen. Zumindest habe ich das so verstanden.

Gruss

Coffeebean

R
Rioma Themenstarter:in
228 Beiträge seit 2013
vor 8 Jahren

Genau Coffeebean, danke 😃

Wahrscheinlich könnte ich im Header irgendein Flag mitsenden, um zu wissen welche DB gewünscht ist, aber so richtig kommt mir das auch nicht vor.

A
350 Beiträge seit 2010
vor 8 Jahren

Je nach Client will er DB1 oder DB2 fragen. Zumindest habe ich das so verstanden.

Ah ok.
Dann ist es "relativ" simpel.
Dein Client übermittelt irgendwie zB im Header seine ClientID oder einen Key den du definierst.
Anhand dessen wird die DB Connection auf der API Seite aufgebaut.
Dazu kannst du je nach Client standartheader setzen in AngularJS zB durch einen httpInterceptor

Grüße
Ahri

Hinweis von Coffeebean vor 8 Jahren

Keine Full Quotes. Du bist lang genug dabei. [Hinweis] Wie poste ich richtig?

2.207 Beiträge seit 2011
vor 8 Jahren

Wahrscheinlich könnte ich im Header irgendein Flag mitsenden, um zu wissen welche DB gewünscht ist...

Ja sowas wäre mir auch spontan eingefallen. Nur halt kein Flag, was direkt auf die DB verweist wie einen kompletten Connectionstring oder den DB-Namen oder sowas. Sondern eben etwas nicht so ganz so aussagekräftiges.

Aber sowas in die Richtung schwebte mir auch vor. Interceptor - an den Request hängen und so weiter...

Gruss

Coffeebean

16.806 Beiträge seit 2008
vor 8 Jahren

... Authentifzieren.
Gut.
....Authentifzieren ?

Authentifizierung != Authorisierung

Thread-Ersteller hat nach letzterem gefragt.

A
350 Beiträge seit 2010
vor 8 Jahren

FIXED 😉

R
Rioma Themenstarter:in
228 Beiträge seit 2013
vor 8 Jahren

Dann wird es darauf hinauslaufen. Vielen Dank

16.806 Beiträge seit 2008
vor 8 Jahren

Ahrimaan, macht den Beitrag jetzt nicht sinnvoller.

Wo und warum musst du dich aber nochmal Authorisieren?

Authorisieren muss/sollte man ständig... mehr oder weniger bei jedem Befehl.
Authentifizieren beim Login.

3.003 Beiträge seit 2006
vor 8 Jahren

Weil's grad passt: nette Anekdote zum Thema Identifizierung / Authentifizierung / Autorisierung. Damit vergisst man auch den Unterschied nie wieder.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

16.806 Beiträge seit 2008
vor 8 Jahren

Gut, das steht in jedem Buch über Themen wie Login und Co.
Wichtig ist eher

Authentifizierung: Ist er es?
Autorisierung: Darf er es?

Bei üblichen Logiksystem spielt Identifizierung keine Rolle. Der Benutzer gibt dies explizit durch seinen Benutzernamen an.
Bei Windows Hello zB. aber schon.

Und was mir hier fehlt ist
Authentifizierung: ist er es _wirklich _ ? Zwei Faktor Authentifzierung oder bei Systemen wie Amazon implementiert, dass der Login bei kritischen Bereichen wiederholt werden muss.
Authorisierung: darf er es immer noch? => Ständiges Abfragen

3.003 Beiträge seit 2006
vor 8 Jahren

Ging mir auch nur um den Unterschied zwischen Authentifizierung und Autorisierung. Identifizierung ist einfach das Festlegen der Credentials, gegen die authentifiziert und autorisiert werden soll, das ist fast überall implizit. Aber jeder der drei Schritte ist innerhalb einer Architektur nur sinnvoll, wenn alle drei stattfinden. Aber geht zu weit vom Thema weg, ich fand den Beitrag aber sinnvoll, weil offenbar nicht allen der Unterschied klar war.

Und was mir hier fehlt ist
Authentifizierung: ist er es _wirklich _ ? Zwei Faktor Authentifzierung oder bei Systemen wie Amazon implementiert, dass der Login bei kritischen Bereichen wiederholt werden muss.
Authorisierung: darf er es immer noch? => Ständiges Abfragen

Jein, das fehlt nicht wirklich, weil, wie gesagt, theoretisch für jede Aktion, die eine Berechtigung benötigt, alle drei Schritte vorgenommen werden müssen, wenn die Aktion nicht innerhalb einer Sequenz stattfindet, die eine Änderung der credentials unmöglich macht. Im Web fällt mir auf die Schnelle keine solche Sequenz ein.

Aus Gründen [1] wird darauf gern verzichtet. Aber eine Authentifizierung "mittendrin" bedeutet keinesfalls höhere Sicherheit, sondern vielmehr, das in anderen Bereichen auf Sicherheit verzichtet wurde. Will sagen "wir machen es sicherer, weil wir an dieser Stelle noch einmal das Passwort verlangen" müsste eigentlich heissen "wir verzichten darauf, bei allen anderen Schritten nach dem Passwort zu fragen". Der Effekt ist derselbe, ja. Aber es ist eben nur sicherer als keine Authentifizierung, und im Web ist jede Aktion, die nicht extra authentifiziert/autorisiert wird, nicht sicher. Nur das Risiko ist (hoffentlich) an den Stellen nicht hoch.

Über das Amazon-System muss man nicht reden, das ist pures marketing. Wenn jemand dein Passwort hat, hat er es auch, wenn man 10mal abfragt, mal abgesehen von geklauten Sessions. Wenn diese Maßnahme die Sicherheit erhöht, dann muss sie vorher katastrophal gewesen sein.

Zweiter Punkt, 2-way-auth kombiniert einfach nur zwei der drei Möglichkeiten [2], jemanden zu authentifizieren. Wirklich überzeugend umgesetzt ist das im Web aber nirgends: ein Faktor ist dort immer das Passwort, und ein Passwort ist vergleichsweise nichts wert. Wenn du - nur als Beispiel - die Authentifizierung ausschließlich über, sagen wir, SMS machst, bist du im Endeffekt fast genauso sicher wie bei der Kombination von Passwort und SMS. Die Betonung auf 2-way-auth halte ich für Augenwischerei, die nur darüber hinwegtäuschen soll, dass Passwörter offenbar broken by design sind, man aber nicht allen Benutzern eine SMS-Auth aufzwingen kann. Überzeugender wäre eine Authentifizierung ohne Passwort, per physical token UND Irisscan, aber Hut ab vor den Benutzern, die das tolerieren 😄.

LaTino
[1] u.a. weil's dem Benutzer nicht zumutbar wäre.
[2] etwas, das man weiß (Passwort), etwas, das man hat (Handy), oder etwas, das man ist (biom. Merkmal)

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

16.806 Beiträge seit 2008
vor 8 Jahren

Ich geb Dir in vielen Punkten recht, aber nicht beim Thema 2-Faktor (zusammen mit den Verschwörungstheorien ) und das System hinter Amazon.
Amazon ist kein Marketing sondern hier geht es um potentielles Session-Hijacking, zB durch SSL-Interception.

Die Verschwörungstheorien: da lächle ich nur. Sorry..Obwohl. Nein, kein Sorry.

16.806 Beiträge seit 2008
vor 8 Jahren

.. dazu gbts übrigens seit wenigen Minuten ASP.NET Core Authorization with Barry Dorrans

3.003 Beiträge seit 2006
vor 8 Jahren

Ich geb Dir in vielen Punkten recht, aber nicht beim Thema 2-Faktor (zusammen mit den Verschwörungstheorien ) und das System hinter Amazon.
Amazon ist kein Marketing sondern hier geht es um potentielles Session-Hijacking, zB durch SSL-Interception.

Die Verschwörungstheorien: da lächle ich nur. Sorry..Obwohl. Nein, kein Sorry.

Session-hijacking hatte ich ja explizit erwähnt. Und welche Verschwörungstheorien?

LaTino

(interessanter Link, danke)

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)