Alles klar danke.

@Abt dein neues Beispiel auf Github hilft sehr! Github

warum nicht? Mit dem wäre das Problem schon gelöst.

Das Backend hat einen kleinen Funktionsumfang und muss relativ häufig installiert werden (Jedes mal liegt eine andere Datenbank mit Benutzern dahinter). Um den Aufwand möglichst gering zu halten, wurde sich damals für das Paket AspNet.Security.OpenIdConnect.Server entschieden, was mit dem Backend ausgeliefert wird.
Außerdem würde ein für sich laufender IdentityServer die Ausfallsicherheit nicht besonders erhöhen, da nun lediglich der IdentityServer ausfallen müsste, um die Applikation unbrauchbar zu machen.

warum nicht? Mit dem wäre das Problem schon gelöst.

Der IdentityServer würde ein Token ausstellen und ich würde in der Web API den IdentityServer als Issuer eintragen. Woher wissen die einzelnen API´s, das dass Token gültig ist? Ich nehme an, der IdentityServer muss nicht bei jedem Request gefragt werden.

Ich durchsuche gerade die Spezifikation des OpenID Connect Protokolls um eine Antwort zu finden. Allerdings wird es mir noch nicht 100% klar.

Hast du dann bei deiner OpenId-Variante ein Authentifizierung gegen was?

Die Applikation läuft stets in einem internen Netzwerk und die Credentials werden gegen eine Datenbank geprüft. Es ist quasi ein Resource Owner Password Credentials Flow.

Vielen Dank

Hallo zusammen,

was ist der übliche Weg um einen REST-Service mit Token-Authentifizierung zu skalieren?

Ich muss natürlich sicherstellen, dass ein Benutzer mit jedem Backendseitigem Service sprechen kann, egal bei welchem er sich angemeldet hat.

Daher muss das Token von jedem Service für gültig gehalten werden.

Es wird zurzeit kein eigenständiger IdentityServer eingesetzt, sondern eine relativ kleine Bibliothek: ASP.NET.OpenId die in der eigentlichen Applikation sitzt.

Was habe ich nun für Möglichkeiten?

1. Token auf Basis eines festen Zertifikats erstellen. Das Zertifikat bekommt dann jede Instanz des Services und sollte so kompatible Tokens erzeugen
2. Ich habe ansetze mit Redis als "Key-Store" gesehen

Habt ihr Erfahrungen und könntet mich beraten?

Vielen Dank

Alles klar, danke für die Erklärung!

Das heißt ich schütze die Daten des Servers gegen unerlaubte Browser-Clients?

Ich habe es nicht getestet, aber gehe davon aus, dass ich außerhalb des Browsers die Header ohne Probleme ignorieren kann.

Hallo zusammen,

ich bräuchte mal eine Klarstellung bezüglich CORS.

Ich habe bereits einige Erklärungen gelesen, allerdings ist bisher nicht alles klar.

Ausgangspunkt: Frontend und Backend laufen nicht unter der gleichen origin.

Damit die SOP nicht verletzt wird, muss ich nun über die entsprechende CORS-Middlware für ASP.NET Core die richtigen Header setzen lassen.

Somit ist der Zugriff auf das Backend kein Problem.

Aber an welcher Stelle wird nun die Sicherheit erhöht? (Clientseitig, Serverseitig)

Ich würde vermuten, dass damit der Client im Browser geschützt werden soll. Aber unter welchen Bedingungen ist die Sicherheit höher?

Vielen Dank.

Da es sich vom eigentlichen ADO.NET Kommunikationparadigma unterscheidet, ist es für mich in diesem Sinne schon ein Bug; egal was die andere Seite als Grund darstellt.

Demnach hatte ich mich richtig erinnert, dass dies z.B. beim SQL-Server nicht zu Problemen führt?

Wechsel der Datenbank ist leider keine Option.

Ich werde mal mit der Lifetime der Connections hantieren und im Notfall Richtung eigenem Connection-Pooling testen.

Sehr ärgerlich.

Ist es denn deiner Meinung nach ein Bug? Da in dem Issue-Tracker von "expected behavior" gesprochen wird.

Wenn ich mich richtig entsinne, passiert mir das mit dem SQL-Server nicht. Allerdings habe ich momentan keinen zum testen.

Kann jemand bestätigen, dass z.B. das neustarten des SQL-Servers mit über Connection-Pooling verbundenem Backend keine Probleme macht?

verwendetes Datenbanksystem: Firebird

Hallo zusammen,

wir benutzen momentan ein Backend auf ASP.Net Core Basis in zusammenspiel mit Firebird.
Connection-Pooling ist aktiviert. Sollte nun die Datenbank

1. kurzzeitig nicht erreichbar sein
2. ein Attachement über die DB geschlossen werden
3. aus welchen Grund auch immer eine Connection wegbrechen

geht nichts mehr.

Der Grund ist folgender: > Fehlermeldung:

FirebirdSql.Data.FirebirdClient.FbException: Error reading data from the connection.

Laut diesem Issue, ist das das vorgesehene verhalten: http://tracker.firebirdsql.org/browse/DNET-585?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel

Mir fallen nun nur 2 "Lösungen" ein:

1. Connection-Pooling deaktivieren (würde ich nicht unbedingt als Lösung sehen)
2. Die Exception fangen, den Pool leeren und den SQL erneut absetzen

Beim leeren des Connection-Pools wäre nur die eine Anwendung betroffen und keine anderen.

Habt ihr bessere Ideen?

Danke und Grüße

Wenn ich mich recht entsinne, gibt es eine Diskussion unter dem Titel: "Nullable reference types".

https://github.com/dotnet/csharplang/issues/36

https://github.com/dotnet/csharplang/blob/master/proposals/nullable-reference-types.md