Remote EJB with custom login module

[szhigunov]

I have created a WAR with some JSP and EJB. Was able to open JSP and call EJB remotely - no problem. Configured custom login module and turned on security. JSP work as expected, but there is a problem with remote EJB calls. My login module gets fired and I can read correct user name, but instead of password provided by the client I am getting something like 229c7599-c147-45ae-b541-8d03941e65dc. I want to emphasize that both WEB module and EJB are protected by the same security domain and when logon module is fired on behalf of the WEB - everything work just fine.

Any ideas? I am testing on EAP 6 / JBoss 7.3. Similar set up worked just fine on JBoss 4. I tried both flavors of EJB remoting (remote JNDI and ejb:): same result.

standalone.xml:

	<security-domain name="MyDomain" cache-type="default">
	<authentication>
	<login-module code="ejbwar.MyLoginModule" flag="required" />
	</authentication>
	</security-domain>

jboss-web.xml:

<jboss-web>

    <security-domain>MyDomain</security-domain>

</jboss-web>

EJB:

@Stateless

@RolesAllowed("test")

@SecurityDomain("MyDomain")

EJB client:

	jndiProperties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
	jndiProperties.put("jboss.naming.client.ejb.context", "true");
	jndiProperties.put(Context.PROVIDER_URL,"remote://localhost:4447");
	jndiProperties.put(Context.SECURITY_PRINCIPAL, "abc");
	jndiProperties.put(Context.SECURITY_CREDENTIALS, "test");

[jaikiran]

Add

jndiProperties.put("jboss.naming.client.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT", "false");

so that the password is passed in plain text (for JAAS login module).

[szhigunov]

That did not help. Password is still coming to my JAAS module as something like a655be3c-dece-4bcf-8480-35d75d890c49. At the same time user name is fine. I want to add that I have not done any changes to the configuration of remoting subsystem.

[dlofthouse]

What does the realm definition currently associated with the Remoting connection currently look that?

The realm needs to be configured to delegate to JAAS.

[szhigunov]

It is as came with the distribution:

	<security-realm name="ApplicationRealm">
	<authentication>
	<local default-user="$local" allowed-users="*"/>
	<properties path="application-users.properties" relative-to="jboss.server.config.dir"/>
	</authentication>
	<authorization>
	<properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
	</authorization>
	</security-realm>

	<subsystem xmlns="urn:jboss:domain:remoting:1.1">
	<connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"/>
	</subsystem>

[szhigunov]

Thanks to the replies, I got it working. Packaged my login code as JBoss module and configured remoting to use it for the authentication. SASL_POLICY_NOPLAINTEXT option was required on the client side as Jakirian pointed out.

	<security-realm name="ApplicationRealm">
	<authentication>
	<jaas name="MyDomain"/>
	</authentication>
	</security-realm>

Just want to confirm, is it the recommended way? The other thing I noticed, is that EJB client fails to connect (times out) if I introduce 5sec sleep in my login module. Is there a way to configure that time out behavior?

Thanks, for your help.

[jaikiran]

Before we go further with the discussion, I just want to make sure that you are intentionally using remote-naming instead of the EJB client API approach for remote EJB invocations. Take a look at this for the difference https://docs.jboss.org/author/display/AS71/Remote+EJB+invocations+via+JNDI+-+EJB+client+API+or+remote-naming+project

[szhigunov]

I am using remote naming because of the following requirements:

1. Client communicates with multiple servers which all run the same EAR.
2. Client gets remote connection info at runtime - no property file with the list of servers (like jboss-ejb-client.properties) on the client side.
3. Client needs full control on which remote server to call (all of them run the same EAR with the same JNDI names). There is an application level load balancing and other reasons.

In terms of comparing JNDI vs EJB client i want to confirm that the difference is only on the client side, right? The server deployment is identical, including security, which as I understood from this discussion is server level securing of the remoting subsystem (will apply to all apps).

I read the article you pointed to before, it is really helpful. One question I have about it is the example of how EJB client api improves performance by avoiding remote call at the point of lookup. All apps I have seen cache remote JNDI proxy in some way. So it is not really a factor.

[jaikiran]

Sergey Zhigunov wrote:

I read the article you pointed to before, it is really helpful. One question I have about it is the example of how EJB client api improves performance by avoiding remote call at the point of lookup. All apps I have seen cache remote JNDI proxy in some way. So it is not really a factor.

It's not only about performance. The "late" lookup optimization in EJB client API allows users to lookup the EJBs even when the server isn't up. This can't be done with remote-naming. So when using EJB client API, the lookups can be done before hand. Of course it depends on the applications on how good that feature is for them.

[jaikiran]

Sergey Zhigunov wrote:

In terms of comparing JNDI vs EJB client i want to confirm that the difference is only on the client side, right? The server deployment is identical, including security, which as I understood from this discussion is server level securing of the remoting subsystem (will apply to all apps).

That's correct.