Welche Daten sollen als "Claim" gespeichert werden?

In ASP.Net Core finde ich, dass die ClaimsAutorisierung eine sehr nicht konkrete Methode ist. Wir können alles als ClaimTypeund ClaimValuepaar hinzufügen ; Gruppen, Vorname, Nachname, Brithdate, canAccessThisURI, isEditor usw. Bei diesem Ansatz (Speichern von allem, was als Ansprüche gespeichert werden kann) wird jedoch eine große Anspruchstabelle erstellt, die 50% meiner Anwendungsdaten enthält.

Ich frage mich als gute Praxis, welche allgemeinen Daten als Ansprüche gespeichert werden sollten.

Ein Anspruch ist einfach eine Tatsache über einen Benutzer, die möglicherweise verwendet werden kann, um jemanden in Ihrem System zu identifizieren oder zu autorisieren . Diese beiden Einschränkungen sollten ausreichen, um das einzuschränken, was Sie als Anspruch geltend machen würden.

Einige Ideen für Ansprüche umfassen:

• Benutzeridentifikation
• Nutzername
• Benutzer Email
• Rollen
• Gruppenmitgliedschaften

Die Metadaten des Benutzers sollten auf das beschränkt sein, was erforderlich ist, um die App für den Benutzer zu personalisieren und den Benutzer mit seinen Daten zu verknüpfen. Die Benutzer-ID reicht aus, um den Benutzer mit Daten zu verknüpfen oder einen Prüfpfad bereitzustellen. Sei nicht gierig.

Rollen und Gruppenmitgliedschaften sind Berechtigungsansprüche. Wenn Ihre Anwendung beispielsweise Gruppen enthält, können Sie anhand der Liste der Gruppen, zu denen der Benutzer gehört, schnell überprüfen, ob diese auf eine private Gruppe zugreifen können oder nicht. Rollen sind etwas feinkörniger und sprechen dafür, welche Berechtigungen ein Benutzer hat. Diese sind normalerweise anwendungsspezifisch. Fügen Sie daher nur das hinzu, was Sie zur Durchsetzung benötigen.

Es gibt viele Systeme, insbesondere STS / Verbundsysteme, die dies folgendermaßen tun:

• eine Behauptung, die den Benutzer eindeutig beschreibt
• Zusammenstellung von Ansprüchen, die allgemeine konzeptionelle Dinge beschreiben, zu denen sie (und andere) Zugang haben

Die "Profildaten" des Benutzers in der App werden möglicherweise nicht in die von Ihnen verwendete Authentifizierungsquelle übersetzt und Sie verwenden möglicherweise nicht immer oder nicht alle Benutzer dieselben Endpunkte.

Wenn Sie mit der alten Forms-Authentifizierung vertraut waren, ist sie analog zum Benutzernamen- und Rollenmodell, und viele der integrierten Funktionen sehen immer noch so aus, wenn Sie System.Security.Claims.ClaimTypes von Name und Rolle entsprechend verwenden.

Weder das alte noch das neue Modell haben Ihnen bei der Vererbung von Ansprüchen oder Rollen viel von der Stange gegeben, aber das ist nicht besonders schwierig zu implementieren, und durch die Implementierung können Sie das Volumen von Ansprüchen oder Rollen reduzieren, die Sie benötigen, um auf Anfrage im Spiel zu bleiben anfordern.

Wenn Ihre Anwendung einen Geburtstag nachverfolgen muss, ihn aber nicht in einem Sicherheitsmechanismus verwenden muss, hat die Aufbewahrung in der Anspruchssammlung keinen wirklichen Vorteil. Legen Sie es in einen separaten Profildatensatz oder so.

Wenn Ihre Anwendung den Geburtstag als Anspruch von einem anderen System erhalten muss, sehen Sie sich eher das Anpassen der föderierten Authentifizierung oder das Fortbestehen des zusätzlichen Anspruchs an.