Security Regressions in EJB3 TestSuite

[alrubinger]

This Thread's been moved from emails to the public domain. :)

"ALR" wrote:
We still have a whole slew of:

javax.ejb.EJBAccessException: Invalid User

...which I believe (Anil correct me if I'm wrong) were introduced around the time of the JACC layer removal.

Our TestSuite is in horrible shape, and we can't track regressions with these errors in place.

Is there hope of resolution before April 7th?

S,
ALR

[alrubinger]

"Anil" wrote:
ALR,

using the prescribed SecurityClient rather than the legacy SecurityAssociation usage in the unit test for "bank" brought the failing errors from 16 to 2.

Possible to convert all usage of SA in tests to the SecurityClient?

[alrubinger]

"ALR" wrote:
Sure, I'll change these up for all instances in the TestSuite (SecurityAssociation is deprecated anyway).

What's going on under the hood here? Can users still set plain properties in their Contexts to get this setup correctly, or is SecurityClient now required?

S,
ALR

[anil.saldhana]

SecurityClient client = SecurityClientFactory.getSecurityClient();
client.setSimple(principal,cred);
client.login();
...

client.logout();

That is the simplest usage of the SecurityClient interface. The deprecated SecurityAssociation usage in the ejb3 test suite is probably failing because the test suite is using an older library of JBossSX in the 2.0.x series. There have been a lot of things broken with the SecurityAssociation api (as I have migrated to a SecurityContext approach). I have still not taken care of all the SA fallouts.

But we try to discourage folks from using SecurityAssociation in the JBoss AS5 arena.

[alrubinger]

Cool. Found that syntax elsewhere. Any docs relating to SecurityClient? If not...

1) Can you use the same instance of the client for many Principals? (ie. re-call setSimple() and invoke again using the new context)
2) If so, must you call logout()... and login().. again?

S,
ALR

[anil.saldhana]

http://labs.jboss.com/file-access/default/members/jbosssecurity/freezone/releases/guide/2.0.1.GA/jbosssecurity.html#securityclient

It should be fine to change the principal/cred combo without logout. All it does is set the SecurityContext on the threadlocal.

[alrubinger]

I couldn't find replacements for the following:

SecurityAssociation.getPrincipal();
SecurityAssociation.getCallerPrincipal();

...are there?

S,
ALR

[alrubinger]

Hmm...maybe:

SecurityContextAssociation.getSecurityContext().getUtil().getUserPrincipal();

S,
ALR

[anil.saldhana]

"ALRubinger" wrote:
I couldn't find replacements for the following:

SecurityAssociation.getPrincipal();
SecurityAssociation.getCallerPrincipal();

...are there?

S,
ALR

Your tests should just be setting the principal/cred. Why are you trying to get the callerPrincipal from SecurityAssociation? What happened to ejbcontext.getCallerPrincipal? When will the spaghetti ejb3 layer look edible? :)

Regarding getting the latest principal on the securitycontext, the api that you quote looks good. But I still am at a loss as to why you are trying to retrieve the principal/caller principal in the tests. Please point me to the tests that are trying to do this. :)

[alrubinger]

But I still am at a loss as to why you are trying to retrieve the principal/caller principal in the tests. Please point me to the tests that are trying to do this. :)

org.jboss.ejb3.test.dd.web.servlets.SecureServlet.processRequest()
org.jboss.ejb3.test.security.unit.TimerRunAsTestCase.testSecurityAssociation()
org.jboss.ejb3.test.security.unit.TimerRunAsTestCase.testNoSecurityAssociationPrincipal()
org.jboss.ejb3.test.security.TimerTesterBean().timeoutHandler()

S,
ALR

[anil.saldhana]

ALR, I made a checkin with a change to the ejb3 auth interceptor. Can you verify the hudson run on Monday morning and update here with status?

[alrubinger]

I triggered the run at:

http://jboss.hudson.alrubinger.com/job/EJB3_Plugin_AS_TRUNK/88/

...which should isolate that commit fairly well. :)

S,
ALR

[wolfc]

Your tests should just be setting the principal/cred. Why are you trying to get the callerPrincipal from SecurityAssociation? What happened to ejbcontext.getCallerPrincipal? When will the spaghetti ejb3 layer look edible? :)

As soon as you stop mucking in ejb3-core and create a clean separation in ejb3-security. EJBContext.getCallerPrincipal() should delegate to the security component (either directly or via plugin).
The only question is whether it is possible to test ejb3-security stand alone. (It should only be a question of how.)

Regarding getting the latest principal on the securitycontext, the api that you quote looks good. But I still am at a loss as to why you are trying to retrieve the principal/caller principal in the tests. Please point me to the tests that are trying to do this. :)

I would rather see:

Hashtable<?, ?> environment = new Hashtable<?, ?>();
environment.put(InitialContext.SECURITY_PRINCIPAL, "me");
environment.put(InitialContext.SECURITY_CREDENTIALS, "creds"); // TODO: String?
InitialContext ctx = new InitialContext(environment);
...
ctx.close();

but that is a nice to have.

As to the 'why' in some tests, don't bother. As long as the test is valid it must work!

[alrubinger]

Anil, here are your deltas for http://fisheye.jboss.org/changelog/JBossAS/?cs=71454:

http://jboss.hudson.alrubinger.com/job/EJB3_Plugin_AS_TRUNK/88/testReport/org.jboss.ejb3.test.security.unit/

S,
ALR

[alrubinger]

"wolfc" wrote:
I would rather see:

Hashtable<?, ?> environment = new Hashtable<?, ?>();
environment.put(InitialContext.SECURITY_PRINCIPAL, "me");
environment.put(InitialContext.SECURITY_CREDENTIALS, "creds"); // TODO: String?
InitialContext ctx = new InitialContext(environment);
...
ctx.close();

Yes, Anil, this is what I meant by:

"ALRubinger" wrote:
Can users still set plain properties in their Contexts to get this setup correctly, or is SecurityClient now required?

Would this eliminate the need for the Client CP to have JBoss Security JARs?

S,
ALR