Hinzufügen von benutzerdefinierten context-Informationen zu EJB-Methode aufruft

Möchte ich weitergeben-Authentifizierung Informationen zu EJB stateless session beans, die beim aufrufen Ihrer Methoden aus einer Java-Webanwendung (Wicket). Die Informationen bestehen aus einer Benutzerkennung und eines Authentifizierungs-Typ (Sie erinnern sich Cookies oder user/Passwort) gespeichert ist, die in der http-session. Eine offensichtliche Lösung ist, fügen Sie diese als parameter an alle EJB-Methoden, aber dies ist mühsam und ich hoffe, dass eine andere Lösung existiert.

Den JNDI-lookup von EJB-beans erfolgt über javax.die Benennung.InitialContext#lookup(String) in der web-tier.

Gibt es eine portable Möglichkeit, um die Authentifizierungsinformationen an eine aufrufende Kontext, so es verfügbar ist, zu den Bohnen geben? Ich brauche diesen Prozess, um verfügbar zu sein für den Anrufer sowohl in der EJB-Schicht (für eine eventuelle web-service-Endpunkt) und in der web-Schicht.

Einige weitere Informationen

Ich bin mit Java EE 6. CDI ist nicht benutzt, und ich würde eher vermeiden, es umzusetzen.

Authentifizierung erfolgt, indem der web-Schicht mit stateless beans Validierung erinnern, cookies, und Benutzer/Passwort-Kombinationen. Wenn ein Besucher zuerst auf die site, die Authentifizierung mit der remember-cookie probiert. Wenn schließlich erforderlich, wird der Benutzer aufgefordert, die Anmeldung mit Benutzername und Passwort. Wie oben erwähnt, wird die Authentifizierung-status wird gespeichert, in der http-session. Ich glaube nicht, das die Java-EE-security-Modell basiert auf reichen, da ich nicht herausfinden konnte, wie diese Authentifizierung könnte, angemessen berücksichtigt werden.

Den Autorisierungs-Schema basiert auf dynamischen Rollen ähnlich wie Facebook bestimmt die Autorisierung basierend auf der Verbindung zwischen 2 Usern und einige Einstellungen. Einige Handlungen auch berücksichtigen, die Art der Authentifizierung. Zum Beispiel, änderung von account-Einstellungen erfordert, Benutzer/Passwort und das cookie ist noch nicht genug. Von dem, was ich verstanden habe, die Java-EE-standard-Gruppen und-Rollen sind nicht eine gute Passform für diese Anforderung.

Andere Verwandte Fragen, die ich gefunden

EJB3 & Wie JAAS-Subjekt/AUFTRAGGEBER weitergegeben EJB Tier vom servlet-container?

Die Kontrolle der Sicherheits-Grundsatz verabschiedet, die auf eine EJB-Aufruf

Die Bindung einer Benutzer-Entität und einem GlassFish AUFTRAGGEBER

Zugriff auf die wichtigsten Kunden innerhalb einer ejb-Methode

dynamische Rollen auf einem Java-EE-server

Ich hoffe meine Frage ist klar genug. Wenn mehr Informationen benötigt werden, werde ich mich gerne zur Verfügung stellen.

Bearbeiten

Feste links. Notiz hinzufügen über die CDI.

  • adam-bien.com/roller/abien/entry/how_to_pass_context_with beschreibt einen Ansatz mit thread-lokalen Speicher für den Austausch von Kontextinformationen zwischen den Schichten. Ich bin jedoch besorgt, dass clustering und asynchrone Methodenaufrufe wird es problematisch mit solchen Ansatz.
InformationsquelleAutor bernie | 2011-11-05
  1. 9

    Ich denke, Sie sollten Bedenken:

    1. Erstellen eines interceptor für die Autorisierung. Es wird Ihnen einen gemeinsamen Ort für die Autorisierung trotz, aus welcher Schicht der Anruf gemacht wurde. Sie könnten prüfen, ob der Aufrufer darf die Methode aufrufen oder wenn die session noch aktiv ist (D. H. überprüfen Sie es in die DB).

    2. In der interceptor-Sie passieren könnte, einige Nutzer-bezogene Daten mit InvocationContext#getContextData().put("user-related-data-name", someObj). In der Anrufer-EJB-können Sie diese Daten mithilfe SessionContext#getContextData().

    Ein Beispiel der Weitergabe von kontextuellen Daten mit SessionContext finden hier

    Den letzten (und interessanteste Teil ist) würde, wie man die Anmeldeinformationen des Benutzers auf die EJB-Schicht. Wenn Sie sagen, dass über WebServices Endpunkt als ich denke, Sie müssen eine Art von Grenze-Klasse oder geben Sie ein Verfahren, die einige sessionId für jeden Anruf.

    Wenn es um die Vermehrung HttpSession Daten vom Servlet zum EJB... Es könnte eine lange gedreht, aber ich würde denken mit der CDI. Ihre Servlet vielleicht @SessionScoped bean enthält den Benutzer-Anmeldeinformationen, und Sie Spritzen den gleichen @SessionScoped bean innerhalb der interceptor.

    Ich bin mir nicht sicher, ob es überhaupt möglich (Injektion von CDI beans in der Abfangjäger oder die gemeinsame Nutzung @SessionScoped zwischen Servlets und EJB ' s Schichten).

    • (Trennen mussten meine Antwort in 3...) in Bezug auf 2, das ist eine gute Idee, vor allem, wenn ich passieren können Kontext-Informationen, ohne eine Methode argument. Ansonsten würde ich verwenden, Reflexion auf die argument-Liste zu finden, die eine enthält den auth-info.
    • In Bezug auf 1, gibt es ein problem mit Abfangjäger, obwohl eine Methodensignatur wie removeTransaction(AuthenticationInfo authInfo, long personId, long transactionId). In diesem Fall wird die Genehmigung ist abhängig von personId aber der interceptor nicht zu erhalten, argument-Namen, sondern nur die argument-Typen. Daher ist Ihre einzige Möglichkeit, um festzustellen, ob argument #2 oder #3 ist das hinzufügen von meta-Daten irgendwo welche bekommen kann out-of-sync mit der Deklaration der Methode. Ist dies nicht der Fall, wenn die Autorisierung erfolgt ist, als ein Methodenaufruf in die Körper von removeTransaction.
    • Wie für die CDI, die ich momentan nicht verwenden, und es meine Wahrnehmung seiner mangelnden Reife, vor allem im Hinblick auf die integration mit meinem web-Frameworks (Wicket), macht mich nicht wollen, um den Schalter. Ich mag mich irren aber. Dennoch, Ihre Idee ist sicherlich interessant jedoch. Es erlaubte mir, mich zu finden stackoverflow.com/questions/2607019/... das gibt etwas mehr Einblick.
    • AD 2. ja - ANMUTIGEN - es Hinzugefügt werden kann, ohne specyfing zusätzliche Parameter der Methode. AD 1. gut, wenn Sie Angst haben, dass ich denken kann mit benutzerdefinierten annotation wie @AuthorizationData; als Abfangjäger könnten Sie InvocationContext#getMethod()#getParameterAnnotations(), dann suchen Sie für die parameter, die hat @AuthorizationData zugewiesen und dies wird die Anzahl der parameter, die Sie möchten zu bekommen.
    • In meiner ersten Antwort bezog ich auf die Möglichkeit des Hinzufügens von Kontext-Informationen für eine EJB-Methode aufruft, von der web-Schicht. Die von Ihnen vorgeschlagene Lösung mit CDI arbeiten könnte, aber es ist nicht anwendbar für meinen Fall leider.
    • Ich nehme Ihre Antwort, da es dem am nächsten, was ich wollte.
    • Danke @bernie. Ich habe dieses gekennzeichnet als 'Favorit', wie ich wollte, zu tun, einige spike-Lösung wenn ich haben etwas Zeit übrig.
    • Ich habe den link zu der Seite, wo ich gezeigt habe, wie contextData verwendet werden könnten. Hoffe, es wird helfen, zu Sie.

    InformationsquelleAutor Piotr Nowicki
Schreibe einen Kommentar