JAAS RolesQuery rauskriegen

[peez]

Da ich üblicherweise sowieso überall die selbe Authentifizierungsmethode (org.jboss.security.auth.spi.DatabaseServerLoginModule) verwende, bin ich gerade dabei, den Login in ein Framework zu verpacken.

Jetzt habe ich das Problem, dass ein falscher Login nicht bei loginContext.login() erkannt wird, sondern erst wenn die erste Datenbankoperation passiert... Korrigiert mich falls das einfach nur ein Programmierfehler ist

Jedenfalls hatte ich es bisher so, dass ich in meiner projektspezifischen Login-Bean eine kurze Methode hatte, die entsprechend eine Abfrage gemacht hat mit dem aus dem Login resultierenden Principal Namen. Bei einem falschen Login hat dann diese die Exception geschmissen.

Jetzt wo das in ein Framework kommt, weiß ich ja noch nicht, wie die Datenbankstruktur bzw. Businessobjekte aussehen und kann deshalb keine Abfrage machen.
Eigentlich habe ich ja im Security-Descriptor schon die passenden Queries:
[XML]
<?xml version="1.0" encoding="UTF-8"?>
<deployment xmlns="urn:jboss:bean-deployer:2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:jboss:bean-deployer:2.0 bean-deployer_2_0.xsd">

<application-policy xmlns="urn:jboss:security-beans:1.0" xsi:schemaLocation="urn:jboss:security-beans:1.0 security-beans_1_0.xsd" name="DPMAM">
<authentication>
<login-module code="org.jboss.security.auth.spi.DatabaseServerLoginModule" flag="required">
<module-option name="unauthenticatedIdentity">guest</module-option>
<module-option name="dsJndiName">java:/dpmam_ds</module-option>
<module-option name="principalsQuery">SELECT USER_PasswordMD5 FROM USERs WHERE USER_Name=?</module-option>
<module-option name="rolesQuery">SELECT USGR_Name, 'Roles' FROM USerGRoups
INNER JOIN USER_USGR_Zugehoerigkeit ON
USerGRoups.USGR_ID=USER_USGR_Zugehoerigkeit.USGR_ID
INNER JOIN USERs ON USER_USGR_Zugehoerigkeit.USER_ID=USERs.USER_ID
WHERE USERs.USER_Name=?</module-option>
</login-module>
</authentication>
</application-policy>
</deployment>
[/XML]
Komme ich im Code irgendwie an die ran? Dann könnte ich diese Query ausführen nach loginContext.login()...

 

[FArt]

Da ich üblicherweise sowieso überall die selbe Authentifizierungsmethode (org.jboss.security.auth.spi.DatabaseServerLoginModule) verwende, bin ich gerade dabei, den Login in ein Framework zu verpacken.

Verstehe ich nicht. JAAS ist ein Framework, und das packst du in ein Framework?

Jetzt habe ich das Problem, dass ein falscher Login nicht bei loginContext.login() erkannt wird, sondern erst wenn die erste Datenbankoperation passiert... Korrigiert mich falls das einfach nur ein Programmierfehler ist

Ja, das ist klar. Der Login setzt nur die Prinzipalinformation am clientseitigen Kontext. Bei Servercalls werden diese Informationen dann automatisch mitgeliefert und vom passenden Loginmodul ausgewertet.

Sicher ein Bean mit einer echo-Methode mit diesem Loginmodul ab und mache den kurzen Call nach dem clientseitigen Login. Der Call geht durch das Loginmodul und du bekommst sofort die Rückmeldung.

 

[peez]

Verstehe ich nicht. JAAS ist ein Framework, und das packst du in ein Framework?

Ja klar Ich bin ein Freund von einfach benutzbaren Frameworks. D.h. ich will nicht erst noch ewig irgendwelche System-Properties manuell setzen müssen, irgendwelche Contexte und Handler holen / definieren, login machen, Login überprüfen, etc. wenn das eigentlich auch auf einmal geht.

Sicher ein Bean mit einer echo-Methode mit diesem Loginmodul ab und mache den kurzen Call nach dem clientseitigen Login. Der Call geht durch das Loginmodul und du bekommst sofort die Rückmeldung.

Meinst du damit eine Bean, die schon ein @SecurityDomain hat? Die ist ja auch projektspezifisch...

 

[FArt]

.. dann machst du halt ein eigenes Bean, nur zu diesem Zweck...

 

[JimPanse]

Hi,

falls es sich um eine Web-Anwendung handelt dann brauchst du ab JBoss 5 kein LoginModul mehr.....

JBoss stellt hierfür -> WebAuthentication bereit (sehr coole sache ich musste früher auch immer so ein dämliches LoginModul schreiben um mit JAAS zu arbeiten)

UND JAAS ist kein Framework!!!! JAAS -> Java Authentication and Authorization Service ist der Standard-Sicherheitsmechanismus in Java!


1. jboss-web.xml

<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
<security-domain flushOnSessionInvalidation="false"/>
  <context-root>/<web-app></context-root>
	<security-domain>java:/jaas/DPMAM</security-domain>
	<resource-ref>
		<res-ref-name>jdbc/<DB-TYPE></res-ref-name>
		<res-type>javax.sql.DataSource</res-type>
		<jndi-name>java:/<DB-JNDI-NAME></jndi-name>
	</resource-ref>
</jboss-web>

In deinem Login-Controller (was immer du für eine Technologie verwendest)

// irgendwo
WebAuthentication webAuthentication = new WebAuthenticiation();

return (webAuthentication.login(username, password) ? "RICHTIG" : "FALSCH";

danach sind automatisch die Rollen gesetzt und den username bekommst du mit request.getRemoteUser()...

grüße

 

[FArt]

UND JAAS ist kein Framework!!!! JAAS -> Java Authentication and Authorization Service ist der Standard-Sicherheitsmechanismus in Java!

Zitat aus dem JAAS Reference Guide:

JAAS provides a framework that augments the Java 2 security architecture with such support.

Ja, JAAS ist ein Service, der ein Framework bereitstellt. Diese formalistische Ungenauigkeit wird im allgemeinen Sprachgebrauch akzeptiert, wenn man nicht unbedingt päpstlicher sein möchte als der Papst.

 

[peez]

<philosophie>Ist nicht auch Java ein Framework, um Betriebssystem-Funktionen zu kapseln?</philosophie>

Nein es geht leider nicht um Web-Anwendungen...
@FArt - die Bean müsste, um mit der richtigen Security-Domain ausgestattet zu sein, wieder projektspezifisch implementiert werden (und das mag ich ja bekanntlicherweise nicht )... An die Query aus dem Descriptor meinst du nicht, dass man rankommt?

 

[FArt]

<philosophie>Ist nicht auch Java ein Framework, um Betriebssystem-Funktionen zu kapseln?</philosophie>

@FArt - die Bean müsste, um mit der richtigen Security-Domain ausgestattet zu sein, wieder projektspezifisch implementiert werden

Nein. Wer gibt wann die application policy vor?
Die allgemeine Laufzeitumgebung (der projektunabhängige JBoss) oder das Projekt? Zumindest muss die Bean nicht neu implementiert werden. Lediglich beim Deployment muss ich das Bean passend konfiguriert werden.