How to disable the SecurityClient login in Jboss 5.1

[amathewjboss1]

Hi,

   We are using JBoss 5.1 / JDK 1.6. We are having a clsutered environment and hence we do remote EJB calls from the client. Currently we have the following code before a client does the JNDI lookup:

SecurityClient securityClient = SecurityClientFactory.getSecurityClient();

securityClient.setSimple(username, password);

securityClient.login();

Due to the above code, some of the client call is having issues in calling the remote EJB call. So I was wondering is there any way I can disable this security login step for Jboss 5.1?

Thank you

Anil Mathew

[jaikiran]

Anil Mathew wrote:

Due to the above code, some of the client call is having issues in calling the remote EJB call.

What's the issue?

Anil Mathew wrote:

So I was wondering is there any way I can disable this security login step for Jboss 5.1?

What exactly do you mean disabling the login step? If the EJB is secured, you have to pass along the credentials in order to access the bean, which happens via a login in this case.

[amathewjboss1]

Thanks for the response. Sorry, i should've made the issue more clear.

The issue is that we have 15 web server (running on apache/tomcat) talking to 3 nodes of app server which is running on JBoss 5.1. Out of this 15 web servers, we have issue in 2 of the web servers when trying to invoke a remote EJB call. After digging deeper into the issue, i could see having "jbosssx-client.jar" in the tomcat lib directory(tomcat/common/lib) is the issue.  But we need this jar for the below code, else we get the runtime error.

SecurityClient securityClient = SecurityClientFactory.getSecurityClient();

securityClient.setSimple(username, password);

securityClient.login();

So i wanted to remove the above code from our application. We call this code when ever a client tries to invoke a remote call. The reason i added this code was when we upgraded the AS to JBoss 5.1 it was giving authentication security error when a client tries to invoke a remote EJB bean.

In answering your second question - "What exactly do you mean disabling the login step?"

Below is what we have in our server/all.pvo/conf/login-config.xml file:

  <application-policy name="client-login">
    <authentication>
      <login-module code="org.jboss.security.ClientLoginModule"
        flag="required">
         <!-- Any existing security context will be restored on logout -->
         <module-option name="usersProperties">users.properties</module-option>
         <module-option name="rolesProperties">roles.properties</module-option>
         <module-option name="restore-login-identity">true</module-option>
      </login-module>
    </authentication>
  </application-policy>

   and in the users.properties we have the username=password and the above securityClient.setSimple(username, password) code will set the same username/password and hence it is authenticated.

  I was under the impression that for JBoss 5.1, we need to make the EJB always secured using the securityClient code and login-config.xml set up. So is there a way i can bypass this security login process in JBoss 5.1 (in other words don't make always EJB secured) ?

Sorry about the big email. Hope i answered your questions.

Thanks

Anil Mathew

[wolfgangknauf]

Hi,

what error message do you see on those two web servers?

Is this your previous post about the security problems when upgrading to AS 5.1? http://community.jboss.org/thread/154021

Seems this one was never "closed".

I think you can use your EJbs without security when you remove the security domain declarations (either in "jboss.xml" or as annotations on your EJBs).

Best regards

Wolfgang

[amathewjboss1]

Thank You so much for the reply.

In answering your question, the error message we are seeing is "connection refused" and this happens after the client calls the remote EJB call. Like i mentioned above, as soon as i removed the "jbosssx-client.jar" from tomcat lib path, the call is successful. But for JBoss 5.1, we need this jar in the path as long as we have the security login from client.

I looked at the jboss.xml and i really don't have any security domain declarations. But in the ejb-jar.xml i do have the below definitions for each EJB home:

    <security-role>
      <role-name>principal_for_system</role-name>
    </security-role>
    <security-role>
      <role-name>principal_for_guest</role-name>
    </security-role>

    <!-- METHOD PERMISSONS -->

    <method-permission>
      <description />
      <role-name>principal_for_system</role-name>
      <role-name>principal_for_guest</role-name>
      <method>
        <ejb-name>Home</ejb-name>
        <method-name>*</method-name>
      </method>
    </method-permission>

I am still digging more so that i can bypass the security login process from client (like i mentioned in earlier post).

Also anwsering your other question, http://community.jboss.org/thread/154021 is the post i created during my JBoss 5.1 upgrade process and the issue was resolved using the security login code which i mentioned above. During that time with the security login code, all my client to remote call was failing.

Thanks

Anil Mathew

[wolfgangknauf]

Hi,

that's a bit strange, your security should not have worked at all without a security domain ;-).

"jboss.xml" in the EJB project should look like this:

{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jboss PUBLIC
    "-//JBoss//DTD JBOSS 5.0//EN"
    "http://www.jboss.org/j2ee/dtd/jboss_5_0.dtd">
<jboss>
    <security-domain>yoursecuritydomain</security-domain>
</jboss>
{code}

If using EJB 3 beans, you might also use the annotation "@org.jboss.ejb3.annotation.SecurityDomain(value="yoursecuritydomain")"

For using your login config "client-login", the security domain should be "client-login".

Do you have a "jndi.properties" file on your clients (for configuring the JBoss client connection)? What is its content?

Best regards

Wolfgang

[amathewjboss1]

Thanks again for your time.

We don't have a jndi.properties file, but we do have our custom property files which will be loaded by bootstrap during the start up and that has the below entries:

java.naming.factory.url.pkgs=jboss.naming:org.jnp.interfaces
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.provider.url=appserver1.domain.com:1100,appserver2.domain.com:1100
jnp.disableDiscovery=true

The above properties will get loaded by the web server (client) during the startup and later these property values will be used by the client for JNDI lookup/invoke a EJB remote bean.

Now i am thinking due to the below setup in ejb-jar.xml, the security is been enforced for the EJB.

<security-role>
      <role-name>principal_for_system</role-name>
    </security-role>
    <security-role>
      <role-name>principal_for_guest</role-name>
    </security-role>

But what i am confused now is that how the below code is linked to the above ejb-jar.xml:

SecurityClient securityClient = SecurityClientFactory.getSecurityClient();

securityClient.setSimple(username, password);

securityClient.login();

Thanks

Anil Mathew

[wolfgangknauf]

Hi,

I will try to sum up the full security process, as it seems there might be some misunderstanding beetween us.

To secure your EJBs, you have to do three steps:

a) declare security roles and method permissions (either by using "@RolesAllowed" annotation or by using the "method-permission" element in ejb-jar.xml

b) declare a security domain (JBoss specific)

c) configure this security domain by using "login-config.xml" or by using a "xxx-jboss-beans.xml" file.

On the client side, you just have to perform a "login", as you already did. I think your login config is OK.

As for your question "how is the client provided login information linked to the EJB security config?": I am not really sure about this. But I assume that JBoss queries each login module when the login is performed, and the login module which knows the login/password will define the roles of the user. Later, when accessing a secured EJB, it is checked whether the user has one of the allowed roles.

Hope this helps

Wolfgang

[amathewjboss1]

Thank You so much and your detailed reply really helps.

I am pretty sure we should always have the step 1 which you mentioned above and removing that (from ejb-jar.xml) is not a good practice as all our method calls are open and won't have any security.

The step2 which you mentioned is where I need to dig more. Like you mentioned this step is JBoss (version) specific and was not there with JBoss 4.x.

Again thanks for all your thoughts and answers.

Anil Mathew

[wolfgangknauf]

About step 2 (configuring security in JBoss): "login-config.xml" is deprecated, for JBoss 5, the suggested way is using a "xxx-jboss-beans.xml" file in your application. See here: http://server.dzone.com/articles/security-features-jboss-510

Best regards

Wolfgang

[amathewjboss1]

I spend lot of time and I am totally stumped on this. I really think we have a bug on Jboss 5.1. Again all I am trying to do is don't use the "security domain" security feature when a client invokes a EJB. In other words I don't want the client to set the username/password using

securityClient.setSimple(username, password) code.

Below is my setup:

ejb-jar.xml:

    <security-role>
      <role-name>principal_for_system</role-name>
    </security-role>
    <security-role>
      <role-name>principal_for_guest</role-name>
    </security-role>

   <method-permission>
      <description />
      <role-name>principal_for_system</role-name>
      <role-name>principal_for_guest</role-name>
      <method>
        <ejb-name>myejbhome</ejb-name>
        <method-name>*</method-name>
      </method>
    </method-permission>

jboss.xml => This file don't have any <security-domain> definition.

login-config.xml => No changes done on this file and I could see it has the below application-policy definition.

  <application-policy name="client-login">
    <authentication>
      <login-module code="org.jboss.security.ClientLoginModule"
        flag="required">
         <!-- Any existing security context will be restored on logout -->
         <module-option name="restore-login-identity">true</module-option>
      </login-module>
    </authentication>
  </application-policy>

With the above setup, when my client (servlet) calls a EJB API, I am getting the below error:

14:08:57,837 ERROR [SecurityInterceptor] Error in Security Interceptor
java.lang.SecurityException: Denied: caller with subject=Subject:
        Principal: guest
        Principal: Roles(members:john,guest,j2ee)
and security context post-mapping roles=Roles(john,guest,j2ee,)

The above setup has no issue on JBoss 4.x, but fails on Jboss 5.1. I really don't understand why it should fail on Jboss 5.1 mainly when I don't have a <security_domain> definition on jboss.xml. This is the reason I am thinking it could be a bug?

Thank You

Anil Mathew

[wolfgangknauf]

I am not sure, but maybe JBoss falls back to use the security domain "other" (declared in "server\default\conf\login-config.xml) when your app does not declare a specific security domain.

Before digging deeper in JBoss code: how is the behaviour for JBoss 6? 5.1 is no longer supported, so the developers won't care for bugs of the old version.

Could you create a full small sample, including all sources? Then I might take a look at it - though I am also just a user ;-)

Best regards

Wolfgang

[amathewjboss1]

Thank You so much for your time and truly appreciated.

Regarding Jboss 6.0, I really can't think of that now. The reason I say that is we have a pretty big application and it took almost an year to migrate our application from Jboss 4.x to Jboss 5.1 and now it is stable in production. The reason we want to remove the securityClient.setSimple(username, password) code from the client is that we believe this "security login process" is causing some performance issues.

I looked at the "other" security domain in login-config.xml file. Below is how it looks:

  <application-policy name="other">
    <!-- A simple server login module, which can be used when the number
    of users is relatively small. It uses two properties files:
    users.properties, which holds users (key) and their password (value).
    roles.properties, which holds users (key) and a comma-separated list of
    their roles (value).
    The unauthenticatedIdentity property defines the name of the principal
    that will be used when a null username and password are presented as is
    the case for an unuathenticated web client or MDB. If you want to
    allow such users to be authenticated add the property, e.g.,
    unauthenticatedIdentity="nobody"
    -->
    <authentication>
      <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
        flag="required"/>
      <module-option name="unauthenticatedIdentity">guest</module-option>
    </authentication>
  </application-policy>

  In the above comment, it says "The unauthenticatedIdentity property defines the name of the principal that will be used when a null username and password are presented as is the case for an unuathenticated web client or MDB". Like you said it seems like jboss is falling to this section when we don't provide "security_domain" in jboss.xml. At this point i am not really sure what is the term "principal" mentioned in the comment and i may need to play with that more to see any luck on that.

Since my application is very big, i am not sure how will i create a full sample to send it to you, but i will try.

Thanks again

Anil Mathew

[jaikiran]

From the logs, it looks like it's a EJB2.x application and looking at the security interceptor for EJB2.x http://www.docjar.com/html/api/org/jboss/ejb/plugins/SecurityInterceptor.java.html, you will see that it falls back on the DEFAULT_EJB_APPLICATION_POLICY (=="other") in the absence of a security domain. I haven't looked into more details of that code, but you might want to see what's going on. I would have expected security interceptors to be skipped in the absence of a security domain.

[amathewjboss1]

Thank You Jaikiran and your thoughts helped me dig further. Like you mentioned it is a EJB2.x application.

Below is more from my stacktrace:

        at org.jboss.ejb.plugins.SecurityInterceptor.checkSecurityContext(SecurityInterceptor.java:368)
        at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:243)
        at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:205)
        at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:136)
        at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invokeHome(PreSecurityInterceptor.java:88)
        at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:132)
        at org.jboss.ejb.plugins.CleanShutdownInterceptor.invokeHome(CleanShutdownInterceptor.java:216)
        at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:107)
        at org.jboss.ejb.SessionContainer.internalInvokeHome(SessionContainer.java:639)
        at org.jboss.ejb.Container.invoke(Container.java:1046)
        at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invokeHome(BaseLocalProxyFactory.java:362)
        at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke(LocalHomeProxy.java:133)
        at $Proxy317.create(Unknown Source)

I looked at the "SecurityInterceptor.java" and the issue is the below line of code in the checkSecurityContext method:

  290         // If there is not a security manager then there is no authentication required
  291         Method m = mi.getMethod();
  292         boolean containerMethod = m == null || m.equals(ejbTimeout);
  293         if (containerMethod == true || securityManager == null || container == null)
  294         {
  295            // Allow for the propagation of caller info to other beans
  296            SecurityActions.pushSubjectContext(principal, credential, null);
  297            return;
  298         }

Since i don't have a "security domain" setup, I would expect the "securityManager" to be null. But in my case if it is not null. Looking further in SecurityInterceptor.java, I could see we get the securityManager from Container class.

ie. securityManager = container.getSecurityManager();

I would assume the reason the container (org.jboss.ejb.Container) is returning the "securityManager" due to JBoss XML configuration which I currently have. If I can narrow this down I am sure that will solve my issue. Any thoughts on this will really help me.

Thanks Again

Anil Mathew