I now remember where the problem lied. I didn't setup the roles through the users/groups file. So I settled on the RunAs which seemed more appropriate at the time to use throughout the system.
Either way, I have a question regarding this. What plug points can I override to get a quick and dirty "role authenticator". I want to simply specify a role name and have openejb do all it's authorizations on this role name. This should all be purely programmatic. I am having a look at the docs, and so far it seems like a JACC provider is the only way to have it purely programmatic, but that seems like overkill. Quintin Beukes On Fri, Sep 25, 2009 at 9:22 AM, Quintin Beukes <[email protected]> wrote: > Hmm. I did try that, but it kept failing. I guess that was because I > specified a realm and it tried to actually authenticate it. That will > work much better for my tests. > > Quintin Beukes > > > > On Fri, Sep 25, 2009 at 7:08 AM, David Blevins <[email protected]> wrote: >> >> On Sep 21, 2009, at 4:57 AM, Quintin Beukes wrote: >> >>> Hey, >>> >>> On the OpenEJB site there is an example for testing EJB security by >>> creating a dedicated EJB with a RunAs annotation, to have that EJB >>> execute as the specified role, and thus emulate what it would be like >>> when that user executes. This is fine for just quickly testing if your >>> roles work. >>> >>> But what if your EJB security is strict on some methods, and the only >>> way to execute it is as a given role. Or more you want to test the >>> functionality of a method as different users. >>> >>> And to add to this, what if you're using JTA? >>> >>> Then once you enter the unit test EJB, you will be starting a CMT, and >>> your unit test won't run things exactly as it would, had you executed >>> the same calls from a remote client for instance. The reason for this >>> is because the RunAs EJB wraps the transactions of the EJBs you are >>> calling, and the result can be undefined, and definitely not accurate >>> to real world situations. You're most likely to notice this when you >>> start using multiple persistence units and EJB jars, like I just did a >>> few moments ago. >> >> Check out the 'testing-security-2' example. Here's the meat of that: >> >> http://svn.apache.org/repos/asf/openejb/tags/openejb-3.1.1/examples/testing-security-2/src/test/java/org/superbiz/injection/secure/MovieTest.java >> >> That would be identical to how a user would login from a remote client. >> Also has no transactions. >> >> >>> A possible solution would be to add >>> "@TransactionAttribute(TransactionAttributeType.NEVER)" as another >>> annotation to your test EJB, so it ends up something like this: >>> @Stateless >>> @RunAs("VDS Admin") >>> @TransactionAttribute(TransactionAttributeType.NEVER) >>> public class VdsAdminBean implements >>> { >>> } >> >> That or NOT_SUPPORTED or SUPPORTS would work as well for ensuring the >> security bean doesn't start a transaction. But, right, if you're really >> wanting to test things as a specific user (rather than role) the approach in >> 'testing-security-2' is really the way to go. >> >> -David >> >> >
