Daniel, in the use cases I have run, I have placed custom login modules under WEB-INF/classes or WEB-INF/lib of my web application and it has worked. I am wondering where are you placing the custom login module code in the EAR.

The login module is loaded by the JDK. Afair, the tccl should be set to the class loader that can load the LM class before jaas kicks in. In your example, the LM class resides in the ejb3 jar inside an ear. Need to see what the tccl is for the jaas framework. One of the odd places in AS7 where tccl becomes important.

I have a similar problem. My login module resides in a JAR within the EAR's lib folder. It can be configured with a JNDI name and then invokes a session bean to perform the authentication task (it is somewhat complex because there a license manager involved). The login module gets called but the user name and the password are random UUIDs. I just want to know if I understand the problem described here correctly and if my problem could be just another incarnation of the same problem...

BTW and off-topic: is this the correct approach if the login process is very complex and depends from entities and other services...?

Frank - I would suggest starting your own thread showing the configuration you are using and the errors that you are seeing both client and server side. The issue is in the same area but makes more sense at the moment to have one thread per affected users so we can work through your scenario in it's own thread.

Thank you for this advise. In order to exclude the custom login module as the cause I just used the built-in "Database" login module. And see, there is the same problem: the user name and password are still random values. So I assume it is not the problem of using a custom login module somewhere in an EAR but a general problem...

Is there another solution besides installing them as modules ? Because I have to load multiple jars there ...

Not at this time. I posted the following update to the jira issue

This is by design (explanation to follow). Although instead of modifying the security module, the best approach is to define a new static module with its own jar (placing it in the modules dir) and reference it using the module="" tag in the security domain login module stack.

The reason it is not possible to use application classes is that remoting connections perform authentication once during the negotiation phase of the connection, and all subsequent ejb (or jndi etc) invocations share the same connection. So an authenticated connection can potentially span an arbitrary number of applications, and that information can not be known at the time of authentication

So in a nutshell we don't know which deployment is going to be invoked, and since more than one can be invoked, even if we did there is ambiguity. If you have to have completely different authentication/authorization code for multiple applications this means defining multiple separate realm and security domain configurations.

This has been implemented, and will be in the 7.1.1 release that will go out this week.

Basically you can now refer to a deployment in the "module=" attribute on a login module. The format is deployment.name. So for example, foo.jar would be "deployment.foo.jar". You can also refer to static modules as before.

(Adding the module to jboss_install_dir/modules/org/jboss/as/remoting/main and modifying the module.xml file at the same path works indeed as Daniel Jipa pointed out (Thanks). It's however not the most elegant solution of course but at least a workaround to continue coding.)

We namespace all deployments under "deployment.". So like if you have a deployment named "security.jar". The module name is "deployment.security.jar". If it's a nested deployment you just add the sub deployment as a suffix. my.ear/stuff.jar is "deployment.my.ear.stuff.jar".

Note that the configuration is slightly misleading in that it appears you can specify a module per login-module. Unfortunately due to a JAAS limitation, all modules in the stack have to have the same module= value. We will look into hacking that to allow each stack to have its own entry in a future release.