-
1. Re: Security for remote but not for local EJB?
severityone Mar 21, 2005 5:16 AM (in response to severityone)After searching some more, I stumbled upon the reference to 'unauthenticatedPrincipal'. I installed a new version of XDoclet and had this line added to jboss.xml.
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE jboss PUBLIC "-//JBoss//DTD JBOSS 3.0//EN" "http://www.jboss.org/j2ee/dtd/jboss_3_0.dtd"> <jboss> <security-domain>java:/jaas/appnetauth</security-domain> <unauthenticated-principal>nobody</unauthenticated-principal> <enterprise-beans> <!-- To add beans that you have deployment descriptor info for, add a file to your XDoclet merge directory called jboss-beans.xml that contains the <session></session>, <entity></entity> and <message-driven></message-driven> markup for those beans. --> <session> <ejb-name>ejb/directory/Directory</ejb-name> <jndi-name>ejb/directory/DirectoryBean</jndi-name> <local-jndi-name>ejb/directory/DirectoryLocalBean</local-jndi-name> </session> </enterprise-beans> <resource-managers> </resource-managers> <!-- | for container settings, you can merge in jboss-container.xml | this can contain <invoker-proxy-bindings/> and <container-configurations/> --> </jboss>
However, I still get an error that the client is not authenticated and that the principal is null:11:10:42,298 ERROR [Engine] ----- Root Cause ----- javax.servlet.ServletException: class vodafonemalta.directory.web.QueryBean : javax.ejb.EJBException: checkSecurityAssociation; CausedByException is: Authentication exception, principal=null at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:536) at org.apache.jsp.index_jsp._jspService(index_jsp.java:180) ...
I'll continue looking, but I'd appreciate any help. The issue is quite pressing because of my holiday that starts less than two days from now...
Thanks again,
- Peter -
2. Re: Security for remote but not for local EJB?
starksm64 Mar 21, 2005 10:00 AM (in response to severityone)Read the unauthenticatedIdentity option on the jboss login modules. This combined with unchecked method permissions on the local interfaces will allow for unrestricted local access and secured remote access.
-
3. Re: Security for remote but not for local EJB?
severityone Mar 21, 2005 12:11 PM (in response to severityone)Hi Scott,
Thanks for your reply. However, I'm missing some essential bit of information to understand the problem. I've read about unauthenticatedIdentity and unauthenticatedPrincipal, but tweaking with these has not led to solving the issue: I keep getting the checkSecurityAssociation ... principal=null exception.
Here's the relevant part of my login.conf:<application-policy name="appnetauth" flag="required" unauthenticatedIdentity="nobody"> <authentication> <login-module code="mt.com.vodafone.appnet.jaas.JBossAppnetLoginModule" flag="required"> <module-option name="appNetURL">https://192.168.4.133/appnet/RequestProcessor</module-option> <module-option name="appNetReference">DIRECTORY</module-option> <module-option name="isApplicationClient">true</module-option> </login-module> </authentication> </application-policy> <!-- The default login configuration used by any security domain that does not have a application-policy entry with a matching name --> <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" unauthenticatedIdentity="nobody" /> </authentication> </application-policy>
I feel a bit silly putting that 'unauthenticatedIdentity' option in my own login module configuration, but as I said, I'm at a loss.
This is the relevant part of the ejb-jar.xml file:<method-permission > <description>[CDATA[description not supported yet by ejbdoclet]]</description> <unchecked/> <method > <description>[CDATA[Invoked when a client makes a connection to the EJB container and this bean gets created.]]</description> <ejb-name>ejb/directory/Directory</ejb-name> <method-intf>LocalHome</method-intf> <method-name>create</method-name> <method-params> </method-params> </method> </method-permission> <method-permission > <description>[CDATA[description not supported yet by ejbdoclet]]</description> <unchecked/> <method > <description>[CDATA[Invoked when a client makes a connection to the EJB container and this bean gets created.]]</description> <ejb-name>ejb/directory/Directory</ejb-name> <method-intf>Home</method-intf> <method-name>create</method-name> <method-params> </method-params> </method> </method-permission>
So the create() methods of both the local and remote interfaces are unchecked (a result of using XDoclet). The JBoss version is 3.2.1, which is running fine (following the credo "if it ain't broke, don't fix it").
Thanks again,
- Peter -
4. Re: Security for remote but not for local EJB?
severityone Mar 21, 2005 12:35 PM (in response to severityone)OK, that piece of XML is totally incorrect, but this
<application-policy name="appnetauth"> <authentication> <login-module code="mt.com.vodafone.appnet.jaas.JBossAppnetLoginModule" flag="required"> <module-option name="appNetURL">https://192.168.4.133/appnet/RequestProcessor</module-option> <module-option name="appNetReference">DIRECTORY</module-option> <module-option name="isApplicationClient">true</module-option> <module-option name="unauthenticatedIdentity">nobody</module-option> </login-module> </authentication> </application-policy> <!-- The default login configuration used by any security domain that does not have a application-policy entry with a matching name --> <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">nobody</module-option> </login-module> </authentication> </application-policy>
doesn't work either. Could you please guide me into the right direction? It must be something obvious that I'm missing, but I'm failing to see it.
Thanks,
- Peter -
5. Re: Security for remote but not for local EJB?
severityone Mar 22, 2005 9:40 AM (in response to severityone)Well, I've just reverted to the old way of working, where web applications have to login as well. Almost a week of searching on the web and in forums has only yielded scattered information that didn't prove to work.
Thanks, for everyone who may have given this issue some thought. But the lack of proper documentation is becoming a liability for us.
- Peter -
6. Re: Security for remote but not for local EJB?
kanth_seenu May 22, 2007 7:13 AM (in response to severityone)I am facing the same issue currently, I am using 4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339) version of JBOSS. Is there any configurable parameter to achieve this. I tried the solution given by Scott above and got the below exception
java.lang.SecurityException: Insufficient method permissions ....... requiredRoles=[], principalRoles=[DEV_ADD, S .....
I removed the role for the method for which I don't need any JAAS support.