login-config.xml in the ear

[vprise]

Generally JBoss is very good at out of the box deployment, in which our ear file contains all the deployment information necessary (such as as datasource details etc....).
However when it comes to login-config.xml its a problem, this is really a file that should reside within the ear file but there is no standard way I could find other than creating a SAR file specifically for that purpose. While the SAR solution is a pain I did it and it worked (despite multiple warnings) in JBoss 3.0.x however now with version 3.2.x it fails.
I don't really want to fix this, setting up login from a database table
should be simple. I also don't want to change the login-config.xml
within jboss since this leave room for error when clients deploy
our application and when developers set up a new machine. Deployment should be trivial. This works for every other file in JBoss except for the login-config.xml.

Am I mistaken?
I own the JBoss paid documentation and the security related documentation leaves a lot to be desired (understatement) it goes into greate detail about many extream cases without detailing the most common situation, web based application authenticating against a database as an easy to use/deploy example. This should be trivial, but instead JBoss chose to go with JAAS which may be powerful but is just too complicated for the needs of even large projects.

[kanagawa]

I have this same problem... did you ever manage to find a way to make it work?

[tthiele]

Even without paid JBoss documentation one should cope with the JAAS part of JBoss. All nessesary things are described in the QuickStart or elsewhere because JBoss follows the standard. Nothing is wrong with this imho. It is a fundamental concept of JAAS that the login modules (PAM's) are provided by the application server and not by the application itself. If your applications want/need full control over the security issues you should dispose of all declarative security (resp. JAAS) and write thes parts by hand (the old traditional way).

I had the same problem, but we decided to educate our customers and convince them that the pluggable authentication is a valueable thing and it's worth to make a little administrative efford. It worked and all are happy with that.

[kanagawa]

Can you direct me to the relevant standards documents or JSRs? I must be missing something important in my understanding of the J2EE architecture. It doesn't yet make sense that the enterprise application should be able to describe the security domain to which it wishes to belong, but not also define a new security domain with new authentication requirements and modules.

[tthiele]

hmmm... What I can mention without digging much: j2ee-1_3-fr-spec.pdf section J2EE.3.3 and ejb-2_0-fr2-spec.pdf section 19.8.

The deployment descriptors jboss.xml and jboss-web.xml do not _define_ new security domains. They only _reference_ them. Providing these security domains is the business of the application container. This must be leveraged outside the myapp.ear.

Hmmm... as far as I remember/understood the game: There are the roles administrator (or deployer?, runs the app server) and application provider (bean provider resp. assembler? - delivers the .ear).

The idea is that the administrator is responsible for the application server and he doesn't trust the application provider at all. So the application provider must not be able to control the security domain (by means of the 'standard').

[kanagawa]

I suspect you're correct about the intent--server administrators shouldn't trust the application; but, when an application deployment descriptor can deploy into an arbitrary security domain and set its EJBs to run-as an arbitrary role, its kind-of moot. The application provider really runs the show, at that point. I'll take a look at the specifications and let you know if I find anything interesting.

[tthiele]

the correct part which you should watch is: j2ee-1_3-fr-spec.pdf section J2EE.2.10.4 (see paragraph "Configuration")