I've created a small testproject now to find out how I can get this to work. And I think it is worth sharing.
We loop through the ClientLoginModule
(which is provided by Wildfly)
in the first stage (of the ApplicationRealm
which is used to secure the remote-
connection). This module stores the credentials (somewhere?) and they are available afterwards to my other login-module.
<security-realm name="ApplicationRealm">
<authentication>
<jaas name="AppRealmLoopThrough"/>
</authentication>
</security-realm>
Of course, this security-domain has to be defined afterwards:
<security-domain name="AppRealmLoopThrough" cache-type="default">
<authentication>
<login-module code="Client" flag="required">
<module-option name="multi-threaded" value="true"/>
</login-module>
</authentication>
</security-domain>
<security-domain name="other" cache-type="default">
<authentication>
<login-module code="com.someExample.CustomLoginModule" flag="required"/>
</authentication>
</security-domain>
In the CustomLoginModule
(which extends UsernamePasswordLoginModule
) I can do the following to retrieve username and password:
final String[] usernameAndPassword = getUsernameAndPassword();
System.out.println("received username: " + usernameAndPassword[0] + " and password " + usernameAndPassword[1]);
getUsernameAndPassword()
is a method provided by the base class UsernamePasswordLoginModule
.
Of course, the secured EJBs have to be annoteded with @SecurityDomain("other")
(or via deployment-descriptor) to get my CustomLoginModule
invoked.
Btw: I know that the security-domain other
has some special meaning and should not be used for the application - this was just for testing... ;)
I was not very successful when trying to find an explanation for this. For me it seems that the login-modules are invoked in two steps: first when the AppRealmLoopThrough
is used for the ApplicationRealm
which is the security-realm for the http-remoting-connector
. In this "step" the username and password are available.
The second "step" is the invocation of the CustomLoginModule
when the container checks the EJB-permissions. In this phase by default there is no way to get the password (as tried initially). Does this sound reasonable?