Wir evaluieren Shiro für eine benutzerdefinierte Saas-App, die wir erstellen. Scheint wie ein großartiges Framework tut 90% von dem, was wir wollen, out of the box. Mein Verständnis von Shiro ist grundlegend, und hier ist, was ich zu erreichen versuche.
Szenario 1
%Vor%Szenario 2
%Vor%Fragen:
Gemeinsam für Sc 1 & amp; 2 Wie kann ich Shiro mitteilen, welche Datenbank verwendet werden soll? ich erkennen Sie, dass es über eine Art benutzerdefinierte Authentifizierung erfolgen muss Filter, aber kann mir jemand den logischsten Weg weisen? Plan zu verwenden die URL des virtuellen Hosts, um shiro und mybatis zu sagen, welche DB zu verwenden ist.
Erstelle ich einen Bereich pro Client?
Sc 1 (Benutzernamen sind über LDAP-Clients hinweg eindeutig) Wenn Benutzer jdoe wird von client1 und client2 geteilt, und er wird über client1 authentifiziert und versucht auf eine Ressource von client2 zuzugreifen, wird Shiro erlauben oder haben ihn wieder einloggen?
Sc 2 (Benutzernamen nur innerhalb der Datenbank eindeutig) Wenn sowohl Client 1 als auch Client 2 erstellt einen Benutzer namens jdoe, dann wird Shiro dazu in der Lage sein Unterscheiden Sie zwischen jdoe in Client 1 und jdoe in Client 2?
Meine Lösung basierend auf Les 'Eingabe ..
%Vor%Neuer Typ von Token ..
%Vor%Ändern Sie meinen geerbten JDBC-Realm
%Vor%Und schließlich das neue Token beim Einloggen verwenden
%Vor%Sie werden wahrscheinlich einen ServletFilter benötigen, der vor allen Anfragen steht und eine mandantId für die Anfrage auflöst. Sie können diese aufgelöste Mandanten-ID als Anforderungsattribut oder als Threadlocal speichern, sodass sie für die Dauer der Anforderung überall verfügbar ist.
Der nächste Schritt besteht darin, wahrscheinlich eine Unterschnittstelle von AuthenticationToken, z. TenantAuthenticationToken mit einer Methode: getTenantId() , die von Ihrem Anforderungsattribut oder threadlocal gefüllt wird. (z. B. getTenantId () == "client1" oder "client2" usw.).
Anschließend können Ihre Realm-Implementierungen das Token und in ihrer supports(AuthenticationToken) -Implementierung überprüfen und true nur dann zurückgeben, wenn das Token eine TenantAuthenticationToken -Instanz ist und das Realm mit dem Datenspeicher für diesen bestimmten Mandanten kommuniziert.
Dies impliziert einen Bereich pro Client-Datenbank. Beachten Sie jedoch Folgendes: Wenn Sie dies in einem Cluster tun und jeder Cluster-Knoten eine Authentifizierungsanforderung ausführen kann, muss jeder Client-Knoten in der Lage sein, eine Verbindung zu jeder Client-Datenbank herzustellen. Das Gleiche gilt für die Autorisierung, wenn Autorisierungsdaten (Rollen, Gruppen, Berechtigungen usw.) ebenfalls über Datenbanken verteilt sind.
Je nach der Anzahl der Clients ist dies abhängig von Ihrer Umgebung möglicherweise nicht gut skalierbar - Sie müssen dies entsprechend beurteilen.
Wie für JNDI-Ressourcen, ja, Sie können sie in Shiro INI über Shiro's JndiObjectFactory referenzieren:
%Vor%Die Factory sucht die Datenquelle und stellt sie anderen Beans zur Verfügung, als ob sie direkt im INI deklariert wäre.
Tags und Links multi-tenant shiro