Never mind. I got it.
I've got a nicely running JUnit runner now using the system property
for specifying a custom login module. This isn't documented, so I had
to find it in the source. I knew about the property, but wasn't sure
if OpenEJB honored custom values in it.
It now even supports testing security, and is nicely extensible. I put
it in an openejb-junit maven project, with package
org.apache.openejb.junit. This way I can provide for extending it for
our own purposes. I use spring in our tests, and am planning on making
another openejb-junit-spring, which builds on this module adding
configuration ability via Spring. This allows you to wire your tests
in weird and wicket ways - like overriding some EJB injections with
"fake EJBs" or whatever you feel like.
To summarise. You can (optionally) specify a class level context
configuration, and then have all tests use this config, and then you
can override it in methods to have that method use different
configurations. Leaving the class level blank, you can just specify
each method with it's own configuration. Configuration supports hard
options, like "securityRole", or raw properites, which can be read
from a configured file (or a default), or they can be specified in the
annotation.
I'll send it along tomorrow (or later today as it's 4:41 AM - I must
have had some other kind of fun?). I first have to fix up the license
headers in the source files, as my IDE adds our company headers by
default, so I just need to remove these.
There is quite a bit of work left, including cleaning up the JUnit
tests for testing configuration (I went crazy on these and am doing
redundant asserts) and thinking about how to integrate the security
tests with custom login modules (where people specify their own login
configuration, as the current method works with one OR the other).
@RunWith(OpenEjbRunner.class)
@ContextConfig(
propertiesFile="/META-INF/test-config.properties",
securityRole="MyRole"
)
@LocalClient
public class TestEjbSecurity
{
@Test
@ContextConfig(
properties={
@Property("override-some-property=with-a-method-level-value")
},
securityRole="And run as a different role"
)
public void testDifferentSecurityAspect()
{
}
}
Quintin Beukes
On Sun, Sep 27, 2009 at 3:44 AM, Quintin Beukes <[email protected]> wrote:
> 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
>>>
>>>
>>
>
