I seem to have managed to solve my problem. With a simple session bean set up as described in Richard Monson-Haefel's EJB book, I was unable to call any methods on the home interface (guest not allowed). I looked closer at the orion-primer session bean (which works) and noticed that there is a typo in the ejb-jar.xml deployment descriptor; the <ejb-name> in <enterprise-beans><session> is "hello.ejb.Hello" and the <ejb-name> in <assembly-descriptor><method-permission> is "hello.Hello" - not the same. Aha! There are no actual permissions assigned on the bean. By commenting out the entire <method-permission> block, I can make anonymous method calls just fine. If I try to explicitly grant permission to the role "users" (which is mapped to the "users" group, to which I added the "anonymous" user), I am denied. The two things that puzzle me now are: Is it proper/standard to grant universal permission to everyone if the <assembly-descriptor><method-permission> block is nonexistant? I can't seem to find anything in the EJB spec which says one way or another. What defines the user/group of the unauthenticated client? The stock principals.xml implies that it is a user named "anonymous", but this doesn't seem to work. Is this a bug? Do I win a doughnut? Jeff Schnitzer [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> --- Original Message --- Hi folks. I'm struggling with Orion's security model in an attempt to get my first entity bean working. It seems that no matter what configuration setting I tweak, I cannot successfully call a method on my bean's home interface. I always receive the exception: com.evermind.server.rmi.OrionRemoteException: guest is not allowed to call this EJB method, check your security settings (method-permission in ejb-jar.xml and security-role-mapping in orion-application.xml). The funny thing is that this is just about as vanilla a case as you can imagine. I'm calling the bean from a servlet, and I desire no authentication whatsoever. I want merely to anonymously call a method on the home interface. Here are a couple questions to which the answers might provide me much enlightenment: * Who is this "guest" person? In the default master principals.xml, there is a user called "anonymous" whose description implies that this will be the user automatically assigned to any unauthenticated user. Should that be "guest" so that I can assign a group (and thus a security-role-mapping) to the unauthenticated user? Is the name special, or is there some other flag that I can't see? I've tried adding a user with the name "guest", etc. Nothing I have tried works. * What is the relationship between the master principals.xml in the config directory and the principals.xml in the application deployment directory? I know the deployment orion-application.xml file points to the deployment principals.xml, but does this override or supplement the master config? Does it make sense to change the <principals> in the orion-application.xml to point to the master config, or is that redundant? * What does the <namespace-access> block do in the orion-application.xml file? * Do I have the basic concept right? 1) a user derives their name from authentication, or if there is no authentication, they are assigned some name (presumably "guest") by default. 2) the "user" belongs to one or more groups, defined by one (or both?) of the principals.xml files. 3) the groups are mapped to security roles in the deployment orion-application.xml file using <security-role-mapping> tags. 4) the security roles are mapped to actual bean method permissions in the bean's deployment descriptor. Somewhere this chain is broken for me, and I'm at a loss to figure out where. If it matters, the bean is an EJB 2.0 entity bean. The deployment descriptor defines a security role "users" which has wildcard(*) permission to the bean. The ear file's application.xml also defines this role. The default deployment orion-application.xml has the <security-role-mapping> of role "users" to group "users". The master principals.xml has both "anonymous" and "guest" as users which belong to the "users" group. Both the atm and news demos work fine. I presume it is because they explicitly authenticate somewhere in code, but I haven't been able to figure out how or why. Help? :-) Thanks, Jeff Schnitzer [EMAIL PROTECTED]
