Ich möchte Authentifizierungsinformationen an EJB-Stateless-Session-Beans weitergeben, wenn sie ihre Methoden von einer Java-Webanwendung (Wicket) aus aufrufen. Die Informationen bestehen aus einer Benutzer-ID und einem Authentifizierungstyp (erinnern Sie sich an Cookie oder Benutzer / Passwort) und werden in der http-Sitzung gespeichert. Eine naheliegende Lösung ist, dies als Parameter für alle EJB-Methoden hinzuzufügen, aber das ist umständlich und ich hoffe, dass eine andere Lösung existiert.
Die JNDI-Suche nach EJB-Beans erfolgt über javax.naming.InitialContext # lookup (String) in der Webschicht.
Gibt es eine Möglichkeit, die Authentifizierungsinformationen einem aufrufenden Kontext hinzuzufügen, damit sie für die Beans verfügbar sind? Ich brauche diesen Prozess für Anrufer sowohl in der EJB-Schicht (für einen eventuellen Web-Service-Endpunkt) als auch in der Web-Schicht.
Ich verwende Java EE 6. CDI wird nicht verwendet und ich würde es lieber vermeiden, es zu implementieren.
Die Authentifizierung wird von der Web-Schicht mit statuslosen Beans durchgeführt, die Cookies und Kombinationen aus Benutzer und Passwort bestätigen. Wenn ein Besucher zum ersten Mal auf die Site zugreift, wird eine Authentifizierung mit dem Erinnerungscookie versucht. Wenn es erforderlich ist, wird der Benutzer aufgefordert, sich mit einem Benutzernamen und einem Passwort anzumelden. Wie oben erwähnt, wird der Authentifizierungsstatus in der http-Sitzung gespeichert. Ich verwende das Java EE-Sicherheitsmodell nicht basierend auf Realms, da ich nicht herausfinden konnte, wie dieser Authentifizierungsablauf richtig integriert werden kann.
Das Autorisierungsschema basiert auf dynamischen Rollen, ähnlich wie Facebook die Autorisierung basierend auf der Verbindung zwischen zwei Benutzern und einigen Präferenzen bestimmt. Einige Aktionen berücksichtigen auch den Authentifizierungstyp. Zum Beispiel erfordert die Änderung von Kontoeinstellungen Benutzer / Passwort und der Cookie ist nicht genug. Soweit ich das verstanden habe, sind die Java-EE-Standardgruppen und -rollen für diese Anforderung nicht geeignet.
EJB3 & amp; Wie wird JAAS subject / principal vom Servlet-Container an die EJB-Ebene weitergegeben?
Kontrolle der Sicherheit Prinzip eines EJB-Anrufs
Binden einer Benutzereinheit und eines GlassFish-Principals
Zugriff auf den Client-Principal 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 es gerne zur Verfügung stellen.
Feste Links. Notiz über CDI hinzufügen.
Ich denke, du solltest darüber nachdenken:
Erstellen eines Interceptors für den Autorisierungsprozess. Sie erhalten einen gemeinsamen Platz für die Autorisierung, unabhängig davon, von welcher Ebene aus der Anruf getätigt wurde. Sie könnten prüfen, ob der Aufrufer die Methode aufrufen darf oder ob seine Sitzung noch aktiv ist (z. B. in der Datenbank überprüfen).
Im Interceptor konnten Sie einige benutzerbezogene Daten mit InvocationContext#getContextData().put("user-related-data-name", someObj) übergeben. In der aufrufenden EJB können Sie diese Daten mit SessionContext#getContextData() erhalten.
Ein Beispiel für die Weitergabe kontextabhängiger Daten mit SessionContext finden Sie hier
Der letzte (und interessanteste Teil) wäre, wie die Benutzeranmeldeinformationen auf der EJB-Ebene abgerufen werden. Wenn Sie über den WebServices-Endpunkt sprechen, dann müssen Sie eine Art von Begrenzungsklasse bereitstellen oder Methoden angeben, die für jeden Aufruf eine sessionId benötigen.
Wenn es darum geht, HttpSession -Daten vom Servlet zum EJB zu propagieren ... Es könnte ein langer Schuss sein, aber ich würde daran denken, den CDI zu verwenden. Ihr Servlet verwendet möglicherweise eine @SessionScoped -Bohne, die die Benutzeranmeldeinformationen enthält, und Sie injizieren die gleiche @SessionScoped -Bohne in den Interceptor.
Ich bin mir nicht sicher, ob es überhaupt möglich ist (CDI-Beans in die Interzeptoren zu injizieren oder @SessionScoped zwischen Servlets und EJB-Layern zu teilen).
Tags und Links security java-ee authentication java-ee-6 ejb-3.0