Wie behandelt man Benutzer und Zugriffsrechte in ASP.NET MVC?

Guten Tag,

ich möchte in meinem MVC Webprojekt Benutzer zulassen deren Daten ich aus einer entfernten Anwendung per REST API beziehe. Ich bekomme an Daten die Userdaten und welchen Teil des Webprojekts der Benutzer sehen darf.

Leider fehlt mir momentan die zündende Idee wie man das umsetzt. Lässt sich sowas mit OAuth2.0 umsetzen ? Also ich weiss schon wie man "früher zu ASP Zeiten" eine Benutzerverwaltung gemacht hat, möchte aber ungern das Rad neu erfinden.

Vielleicht hat ja jemand einen Denkanstoss für mich.

Danke
Michael

Könntest Du den ersten Satz evtl. so formulieren, dass man ihn als Aussenstehender, der Dein Projekt nicht vor sich hat, verstehst?

Ich kann mir ungefähr denken, was Du willst: Du hast eine Webanwendung A und irgendwoanders einen WebService B.
Der Benutzer verwendet die Anwendung A aber die Daten selbst muss A - mit den Benutzerkontext - von B holen. Richtig?

Ja, sowas kann OAuth 2.0 über den Implicit Workflow.

Kann ich versuchen 😃

Es handelt sich um ein Projekt welches Dienste im Abo Modell anbietet. Die komplette Abrechnung und Benutzerverwaltung erledigt ein externes Shopsystem.

Mit diesem gleiche ich per REST API die Benutzerdaten (email und Passwort welches bcrypt verschlüsselt ist) ab und die Moddule welche gebucht/bezahlt sind.

Michael

ich muss da nochmal nachhaken. Welche Möglichkeit gibt es, dass ein Benutzer nur "seine" Daten zu sehen bekommt ? Momentan habe ich den Controllerzugriff per Identity geregelt. Programmtechnisch funktioniert das, aber natürlich kann der Benutzer z.B. direkt in die Browseradresszeile eine andere Datensatz ID eingeben und bekommt dann Zugriff auf fremde Daten ? Muss ich bei jedem Zugriff die Benutzerid mit abfragen oder gibt es eine andere Lösung ?

Michael

Muss ich bei jedem Zugriff die Benutzerid mit abfragen

Ja, ausnahmlos.
Bei jedem Request muss die Identität des Benutzers abgefragt werden sowie muss eine Abfrage erfolgen, ob er auf den Datensatz / Aktion Zugriff hat oder nicht.

Lässt Deine Anwendung ein Zugriff über die URL auf einen anderen, unbefugten Datensatz zu, dann ist das eine Sicherheitslücke.

Das, was Du über den Controller abdeckst, nennt sich Authentifizierung: das Ermitteln einer Identität.
Was Du selbst programmieren musst ist die Authorisierung: das Überprüfen der Rechte auf eine Aktion oder Datensatz.
Das ist Programm-Logik und in Deiner Verantwortung.

oder gibt es eine andere Lösung

Nein.

Hallo micha0827,

da REST stateless ist hat der Request alles mitzubringen, was er braucht um bearbeitet zu werden. In dem Fall sollte er irgendeine Art Token mitbringen, dass der Server auseinandernimmt und dann kannst du auf die UserId oder was du eben brauchst, zugreifen und in deine where-Klausel beim Abfragen der Daten einbauen.

So sollte jeder Nutzer nur das sehen, was er sehen sollte.

Gruss

Coffeebean

Hallo Abt,

also die UserId in einer Session Variable ablegen und bei jeder DB Abfrage mit einbeziehen ?

Michael

Wenn Du OAuth benutzt, wovon Du gesprochen hast, dann hast Du keine Session, sondern ein Token.
Der Token identifiziert dabei den Benutzer (Access Token).

PS: les Dich in die unterschiedliche Authentifizierung und Authorisierungsarten ein.
Wenn Du absolut ohne Peilung sowas umsetzt und eher nur rum probierst, dann ist _eigentlich _garantiert, dass etwas schief geht.

ich benutze ASP Forms Authentication.
Die Benutzerdaten (ausser Username und Passwort) und die Rollen sind bei mir im SQL Server gespeichert.
Ich mach nur für die Abfrage von Benutzername und Passwort einen REST Call der mir die UserID gibt die mit meiner SQL DB übereinstimmt.

Michael

Wieso bitte nimmst Du Forms Authentication und dann noch ein zusätzlichen Call für die UserID?
Das ist alles andere als ein sicherer Weg 😉

Forms Authentication erstellt Dir ein Cookie, normalerweise. Damit bist Du authentifiziert. Für weitere Anfrage nimmt den Cookie.

Forms ansonsten, was ich nicht empfehlen würde, sondern eben OpenID/OAuth-Mix, dann brauchst Du keinen REST Call für eine UserID.
Das öffnet ja Missbrauch Tür und Tor. Lese Dich bitte in Loginmechanismen ein. Das ist ansonsten absolut fahrlässig.

weil die Vorgabe ist dass die Benutzer in einem anderen System registriert sind und sich nicht noch einmal bei mir registrieren sollen.
D.h. die Anmeldung soll mit den gleichen Benutzerdaten erfolgen.

Michael

Hallo micha0827,

suchst du Single-Sign-On (SSO)?

What is SSO (Single Sign On)?

Gruss

Coffeebean