✔ DataSource über @Ressource injezieren

[saftmeister]

Dadurch das du den JNDI-Namen in der Datasource angepasst hast, findet deine Security-Konfiguration ihre Datasource nicht mehr. Du müsstest entweder deine DataSource-Konfiguration (und damit den Lookup innerhalb der Bean) anpassen oder den des Security-Moduls an die DataSource-Konfiguration anpassen.

Also das hier passt nicht zusammen:

<datasource jndi-name="java:jboss/datasources/mydb"...

<module-option name="dsJndiName" value="jdbs/mssql"/>

Du könntest jetzt "einfach" das Security anpassen:

<module-option name="dsJndiName" value="java:jboss/datasources/mydb"/>

Wie da allerdings vorher eine Anmeldung möglich war, kann ich auch nicht nachvollziehen. Ich kann mir nur vorstellen, dass der Security-Kontext vorher auf die LDAP-Variante ausgewichen ist. So gut kenne ich mich aber mit den Security-Kontexten nicht aus.

Du solltest aber auf jeden Fall auch den LDAP-Url anonymisieren ;-) Könnte mir vorstellen, dass firmen-interne Infrastrukturen (wie bspw. Hostnamen) einem NDA unterliegen.

 

[BLR]

Das selbe habe ich mir auch gedacht, deswegen habe ich in die Datasource für den "lookup" geschrieben:

<datasource jndi-name="java:jboss/jdbc/mssql" pool-name="mydb" enabled="true" use-java-context="true">

Nun verwende ich den selben JNDI-Namen wie in der security-domain.
Das selbe dann noch in die Persistence.xml und in die Bean reingeschrieben....deployen funktioniert, aber das Einlogen konnte ich immer noch nicht.

Dann habe ich mir noch gedacht, wenn ich den "pool-name = mydb" habe, dann schreibe ich:
@Ressource(name="mydb") rein, mit dem Eintrag in der persistence.xml : "java:jboss/jdbc/mssql" bzw. auch "mydb". All das hat nicht funktioniert.

Jedenfalls denke ich jetzt, dass der jndi-name im Datasource nichts mit dem jndi-name in der security-domain zu tun hat, denn
normaleweise steht im Jboss schon eine datasource:

<datasource jndi-name="java:jboss/datasources/ExampleDS" pool-name="ExampleDS" enabled="true" use-java-context="true">

Und ich konnte mich trotzdem einlogen.....
Der Treiber, der in der Standalone.xml geschrieben ist, sieht so aus:

<driver name="mssql" module="mssql">

Wäre dann name = "mssql" auch gleichzeitig die Definition von dem jndi-namen für den Treiber??

Bzw. habe ich den Jndi-Namen in der Module.xml beschrieben, wo den Treiber als "resource-root" angegeben habe?

 

[saftmeister]

JDBC-Treiber-Name ist ein Alias, unter dem das Modul (JDBC-Treiber-Library + Abhängigkeiten) registriert im Container sind. Die werden normalerweise unter $JBOSS_HOME/modules im Dateisystem hinterlegt und bekommen eine module.xml, in der die Library selbst und die Abhängigkeiten (bspw. JTA, JCA u.ä.) eingetragen sind.

Die DataSource selbst ist abstrakt und abhängig von einem JDBC-Treiber (via Name). Die DataSource wird im JNDI registriert, damit Beans sie via Lookup erreichen können (ist normalerweise aber nicht notwendig, siehe nächsten Punkt).

Der EntityManager verwendet eine DataSource via JNDI-Lookup. Der wird verwendet, um die Entity-Pojos zu verwalten.


Wenn du jetzt ein Security-Modul einkonfigurierst, musst du ja das code-Attribut versorgen. Da steht bei dir "Database", was ein Alias für org.jboss.security.auth.spi.DatabaseServerLoginModule ist. In der Dokumentation zu dieser Klasse steht, dass wenn die Property dsJndiName nicht gesetzt ist, wird "java:/DefaultDS" verwendet, was auch wieder ein Alias auf eine spezifische DataSource ist (sofern der Default nicht geändert wird, handelt es sich dabei um "java:jboss/datasources/ExampleDS"). Du hast ja einen angegeben, also sollte diese DataSource auch verwendet werden. Der Wert in dsJndiName muss aber auf einen gültigen DataSource-Eintrag verweisen.

Ich vermute jetzt, dass weil dein DataSource nicht registriert war, der Login den Fallback auf LDAP gegangen war. Dann hast du einen Login via LDAP-Account vollzogen. Jetzt, da korrekte JNDI-Name des DataSource-Eintrags in das Security-Modul einkonfiguriert wurde, versucht der Login den Account in der MSSQL-Datenbank zu finden, das geht schief (Benutzer nicht vorhanden, Passwort falsch, Role-Eintrag nicht gefunden, etc.) und ein Login via LDAP wird nicht mehr ausgeführt.

Ich kann das hier leider nicht testen, da ich kein LDAP zur Verfügung habe.

Du kannst dir jedoch deine eigene Login-Klasse schreiben, in der Doku zu Security-Domain steht wie man Custom-Module erstellt. Die kannst du dann sogar debuggen.

Könnte mir jedoch auch vorstellen, dass du den Log-Level für das Java-Package org.jboss.security.auth.spi auf DEBUG stellst, herausfindest, was da schief läuft: http://middlewaremagic.com/jboss/?p=453

 

[BLR]

Vielen Dank für deine Antwort

ch vermute jetzt, dass weil dein DataSource nicht registriert war, der Login den Fallback auf LDAP gegangen war.

Welche Datasource genau ? Die, die standardmäßig da ist oder die ich erstellt habe:

<datasource jndi-name="java:jboss/jdbc/mssql" pool-name="mydb" enabled="true" use-java-context="true">

Jetzt, da korrekte JNDI-Name des DataSource-Eintrags in das Security-Modul einkonfiguriert wurde

also meine "java:jboss/jdbc/mssql" meinst du wahrscheinlich

versucht der Login den Account in der MSSQL-Datenbank zu finden

Also in der MSSQL-Db steht nur der User-name und die User-Rolle, kein Passwort oder sowas....das befindet sich ganz wo anders.

Nehmen wir mal an, dass deine Vermutung richtig ist, dass Login auf den Fallback auf LDAP gegangen war UND jetzt habe ich so eine DataSource

<datasource jndi-name="java:jboss/jdbc/mssql" pool-name="mydb" enabled="true" use-java-context="true">

Und nun geht nicht mehr LDAP.
Was müsste man den machen, damit er wie vorher auf den LDAP geht?

 

[saftmeister]

Du könntest mit dem Attribut "flag" spielen, was am <login-module>-Element hängt. Das steht bei dir auf "required", stell es doch bei der Database-Variante mal auf "sufficient" wie in der Dokumentation beschrieben.

 

[BLR]

Danke für den Tipp.
Es gibt in meiner Standalone.xml mehrere Stellen mit <login-module>

<security-domain name="other" cache-type="default">
  <authentication>
  <login-module code="Remoting" flag="sufficient">
  <module-option name="password-stacking" value="useFirstPass"/>
  </login-module>
  <login-module code="RealmDirect" flag="required">
  <module-option name="password-stacking" value="useFirstPass"/>
  </login-module>
  </authentication>
  </security-domain>
  <security-domain name="vis" cache-type="default">
  <authentication>
  <login-module code="org.jboss.security.auth.spi.LdapLoginModule" flag="sufficient">
  <module-option name="password-stacking" value="useFirstPass"/>
  <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
  <module-option name="java.naming.provider.url" value="ldap://myHouse.com/"/>
  <module-option name="java.naming.security.authentication" value="DIGEST-MD5 GSSAPI"/>
  <module-option name="rolesCtxDN" value="ou=None,dc=my-house,dc=com"/>
  </login-module>
  <login-module code="Database" flag="sufficient">
  <module-option name="password-stacking" value="useFirstPass"/>
  <module-option name="dsJndiName" value="jdbs/mssql"/>
  <module-option name="principalsQuery" value="select login from user where login = ?"/>
  <module-option name="rolesQuery" value="select role,'Roles' from user_role where login = ?"/>
  </login-module>
  </authentication>
  </security-domain>

Ausser dem Flag bei dem Wert "RealmDirect" habe die Werte auf "sufficient" oder "optional" gesetzt.
Dabei kommt immer die selbe Meldung:

Access to the requested resource has been denied

 

[saftmeister]

Sorry, ich bin kein guter Ratgeber, was diese Security-Domains angeht. Ich kann dir nur raten, das Manual zu diesen Punkten genauestens zu lesen und ggf. mal den Log-Level auf Debug zu stellen (wie in #13 vorgeschlagen).

 

[BLR]

Soo...Problem gelöst.
Die DataSource habe ich aus der Standalone.xml in die eigene xml ausgelagert.
Und injeziert habe ich das mit: @Ressource(mappedName="jndiName")
Danke für die Hilfe.

 

[saftmeister]

Interessant, danke für die Lösung.