Ich habe den ganzen Tag gegoogelt und mir verschiedene Fragen angesehen und versucht, die beste Lösung für die Implementierung von Authentifizierung und Autorisierung zu finden. Ich habe jetzt einen Teil der Lösung gefunden, hoffe aber, dass jemand die Lücken füllen kann. Mir ist klar, dass es unten viel Text gibt, aber bitte ertragen Sie mich: O)
Hintergrund
Ich habe eine teilweise abgeschlossene CRM-Anwendung geerbt, die derzeit JSF 2.0, JavaEE 6, JPA und eine PostgreSQL-Datenbank verwendet. Leider haben die Leute, die ursprünglich angefangen haben, diese Web-App in ihrer unendlichen Weisheit zu bauen, entschieden, dass es das Beste wäre, die Authentifizierung / Autorisierung zu Ende zu lassen - ich muss sie jetzt einfügen.
Die Anwendung ist im Wesentlichen in drei Ebenen aufgeteilt - die Ansichten, die verwalteten Beans und die DAOs. Dies bedeutet, dass die verwalteten Beans besonders "fett" sind, da sie die gesamte Geschäftslogik, Validierungs- und Navigationslogik enthalten.
Authentifizierungs- / Autorisierungsanforderungen
Wo ich bin
Das erste, was ich vorhabe, ist Folgendes zu tun: Benutzerauthentifizierung und Autorisierung mit JAAS und Servlet 3.0 Login Beispiel. Dies, glaube ich, wird meine ersten 3 Anforderungen erfüllen.
Um Save Buttons usw. auf Seiten anzuzeigen / auszublenden, kann ich die in beschriebene Technik verwenden diese SO Antwort . Dies wird Anforderung 4 teilweise lösen, aber ich denke, dass ich noch die Aktionsmethoden und / oder die verwalteten Beans selbst sichern muss. Ich möchte zum Beispiel eine Anmerkung oder etwas zur save () -Methode für die Kunden-Bean hinzufügen können, um sicherzustellen, dass nur Benutzer mit der Rolle "Customer Service" sie aufrufen können - hier beginne ich mit Problemen .
Ich denke, eine Option wäre, etwas zu tun, was ich in der Ansicht vorschlage, und facesContext zu verwenden, um zu überprüfen, ob der aktuelle Benutzer "in role" ist. Ich bin nicht scharf darauf, da es nur meinen Code durcheinander bringt und stattdessen lieber Anmerkungen verwendet. Wenn ich jedoch diese Route hinuntergehen würde, wie würde ich einen http 403-Status zurückgeben?
Die Anmerkungen von javax.annotation.security. * scheinen gut geeignet zu sein, um den Zugang zu Bereichen der Anwendung klar zu definieren, aber soweit ich weiß, können sie nur zu EJBs hinzugefügt werden. Dies würde bedeuten, dass ich meine gesamte Geschäftslogik aus den verwalteten Beans, in denen sie sich derzeit befindet, in neue EJBs verschieben muss. Ich denke, dies hätte den zusätzlichen Vorteil, dass die Geschäftslogik in eigene Klassen (Delegierte, Dienste oder wie auch immer man sie nennt) aufgeteilt wird. Dies wäre jedoch ein ziemlich großer Refactor, der nicht durch fehlende Unit-Test- oder Integrationstests unterstützt wird. Ich bin mir nicht sicher, ob die Verantwortung der Zugriffskontrolle auch auf dieser neuen Service-Ebene sein sollte - ich denke, dass es auf den verwalteten Beans sein sollte.
Andere Alternativen
Während meiner Recherchen habe ich viele Leute gefunden, die Frameworks wie Spring und Seam erwähnen. Ich habe eine begrenzte Erfahrung mit Seam, ich denke, dass es für dieses Projekt gut geeignet gewesen wäre. Soweit ich mich erinnere, löst es die Autorisierungsprobleme, die ich habe, aber ich denke, es ist zu spät, um es jetzt einzuführen .
Ich habe auch Shiro an verschiedenen Orten erwähnt. Nachdem wir uns das 10-minütige Tutorial angesehen haben, schien dies eine gute Lösung zu sein, besonders in Verbindung mit Deluan Quintaos Taglib , aber ich konnte keine Tutorials oder Beispiele finden, wie ich sie in eine JSF-Web-App integrieren könnte .
Die andere Alternative, auf die ich überraschend regelmäßig gestoßen bin, ist die Implementierung einer benutzerdefinierten Lösung - das scheint mir verrückt zu sein!
Zusammenfassung
Zusammenfassend möchte ich nun eine Anleitung dazu geben, ob ich den richtigen Weg in Bezug auf die Implementierung von Authentifizierung und Autorisierung gehe und wie ich diesen fehlenden Teil der Sicherung einzelner Methoden und / oder verwalteten Beans (oder zumindest der Code, an den sie delegieren) und / oder wie ich einen HTTP-Status 403 manuell zurückgeben kann.
Nach vielen Recherchen bin ich zu dem Schluss gekommen, dass erstens die Anforderungen meiner Anwendung von einem Einsatz auf einem Anwendungsserver profitieren würden, der die Java EE-Spezifikation vollständig implementiert, und nicht von einem Servlet-Container wie Tomcat. Da das Projekt, an dem ich arbeite, Maven nutzt, war es wichtig, die Abhängigkeiten richtig einzurichten - das war nicht einfach und erforderte ein gutes Stück Googeln und Trial-and-Error: Ich bin mir sicher, dass es einen wissenschaftlichen Ansatz gibt könnte genommen werden.
Ich musste dann Erstellen Sie ein mysql-Modul , um meine Anwendung dazu zu bringen, mit der Datenbank richtig zu kommunizieren, und entfernen Sie dann die Factory, die zum Erstellen von DAOs implementiert wurde, und konvertieren Sie sie stattdessen in EJBs. Ich musste auch hibernate.cfg.xml aktualisieren, um auf die hinzugefügte Datenquelle und persistence.xml zu verweisen, um den Transaktionstyp auf JTA zu setzen und auch auf die JTA-Datenquelle zu verweisen. Die einzige andere Komplikation war, dass das Open Session In View-Muster verwendet wurde, was dazu führte, dass ich beim Start auf Entitäten in den Ansichten mit lazinen Initialisierungsfehlern im Hibernate endete. Ich habe den Filter, wie unten in dieser Antwort gezeigt, erneut implementiert, um dies zu umgehen. Ich sehe dies als eine vorübergehende Maßnahme, um Dinge wieder in Gang zu bringen, bevor ich diesen Bereich hoffentlich umgestalten und die Notwendigkeit für den Filter beseitigen kann.
Der Wechsel zu JBoss hat etwas mehr als einen Tag gedauert und ich bin mir sicher, dass es viel schneller gelaufen wäre, wenn ich mehr Erfahrung mit Java EE und Maven hätte. Jetzt, wo ich an diesem Punkt bin, bin ich in einer guten Position, um die Sicherheit der Naht 3 in das Projekt fallen zu lassen und das zu nutzen, anstatt zu versuchen, eine Lösung zu hacken, die im Wesentlichen die Richtung ist, die ich gehen würde. Das Schöne an Seam 3 ist, dass Sie in gewisser Weise auswählen können, welche Module Sie verwenden, anstatt das gesamte Framework (wie Seam 2) hinzufügen zu müssen. Ich denke, einige der anderen Module werden aber auch hilfreich sein und werden mir unter anderem helfen, die offene Session in View Pattern loszuwerden.
Eine Sache, die mich mit der Verwendung von Seam beschäftigt hat, war, dass ich über DeltaSpike informiert wurde. Dies scheint die Naht zu ersetzen und es gibt keine Pläne für weitere Nahtversionen. Ich habe entschieden, dass, da die Naht immer noch unterstützt wird und wenn DeltaSpike so lange dauert wie Naht 3, dann ist es ziemlich sicher, Naht 3 zu verwenden.
Ich werde hoffentlich dazu kommen, einen richtigen Blogbeitrag zu schreiben, der diese Migration genau beschreibt.
%Vor%Haben Sie etwas mit Spring Security versucht - Neueste Version 3
Im Gegensatz zur Verwendung eines Anforderungsfilters oder der Verwendung von JAAS ist die Federsicherheit ein umfassendes Sicherheitsframework, das die meisten Ihrer Sicherheitsbedenken löst. Sie können ihn verwenden, um einen Benutzer mithilfe eines db-Bereichs zu authentifizieren, ihn zu autorisieren und bei Bedarf entsprechend den bereitgestellten Authentifizierungsinformationen umzuleiten.
Sie können die Methoden sichern, die Sie geschrieben haben Ссылка
@PreAuthorize ("hasRole ('ROLE_XXX')") ist der Weg
um bestimmte Elemente einer Seite sicher zu machen .. //Inhalt
mehr lesen und Beispiele Ссылка
Tags und Links java-ee authentication authorization jsf jsf-2