Question

As I understand javax.security.auth is an API for authentication and authorization.

I understand that security should be implemented by the container provider and the bean-provider can just use it in his bean my simple annotations (@javax.annotation.security.RolesAllowed, @PermitAll etc) as recommended by the JSR.

My Question: This simply means that security cannot be tested without deploying in the container. Is there a way to use an external 3rd implementation of javax.security which can in someway be injected into the bean from the test from which security can also be propagated and tested?

This is almost a similar approach using which we inject a JPA implementation or a external transaction manager from a unit test into a bean for testing it.

P.S: I just want to check if this is possible and if it is possible, it might open ways to some other development. I understand that this testing can be done easily by deploying the bean in an Embedded container like OpenEJB or Arquillian.

Answer 1

There’s quite a lot of plumbing involved in all of this. Trickier parts are:

• Processing the annotations and respecting the non-inheritance and overriding rules (not referring to xml overriding)
• Ensuring annotations are not getting misused or applied incorrectly
• Respecting xml and overriding the annotation data
• Mapping “roles allowed” with declared “roles” (there’s a level of indirection)
• Adding all metadata as properly formatted permission strings to the JACC provider
• Handling login via properly configured JAAS LoginModule
• Some creative code to integrate the JAAS with JACC (there’s no standard way to do that)
• Tracking your Subject via doAs calls or ThreadLocal
• Proxying all your objects so you can do the auth checks before methods are actually invoked
• Changing the security context for method annotated with @RunAs and ensuring the RunAs role is a declared role
• Dealing with EJBContext.getCallerPrincipal() (a Subject has many Principal objects, so you have to pick one to return and ensure you can pick the same one consistently)
• Wiring EJBContext.isCallerInRole(String) to the JACC provider
• Making sure you use the right exception classes when you handle login failure, authorization failure, and various other conditions

So that’s what a container does. The work that JAAS and JACC do are really quite small. Certainly not as detail oriented at least.

None of this can really be “injected” as you might have hoped. Security is effectively an around advice.

On the surface things like annotation-based security look very simple. However, when you explore all the combinations, caveats and conditions it really adds up. I remember all those details above because I got them all wrong when I first had to implement them. 🙂 Thank goodness for TCKs.

I wouldn’t advise attempting to make your own security testing framework.

If you do have a particular way that you’d like to see your testing happen, the smartest thing would be to just get involved with OpenEJB or Arquillian.

All of the coolest features in OpenEJB came from users aches and pains and people describing to us “it hurts when I do this.” We love it. It’s a great source of features, a great way to get new contributors, and a fantastic way to prove ideas that might be good for bringing into the spec (like the Embedded EJBContainer API in EJB 3.1).

I can’t stress enough how important it is to participate in the innovation rather than attempting to bypass it. If something doesn’t meet your needs, demand better.

That last statement is more directed at the world in general 🙂