-
1. Re: Security Regressions in EJB3 TestSuite
alrubinger Mar 29, 2008 11:29 PM (in response to 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? -
2. Re: Security Regressions in EJB3 TestSuite
alrubinger Mar 29, 2008 11:30 PM (in response to 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 -
3. Re: Security Regressions in EJB3 TestSuite
anil.saldhana Mar 29, 2008 11:49 PM (in response to alrubinger)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. -
4. Re: Security Regressions in EJB3 TestSuite
alrubinger Mar 30, 2008 12:02 AM (in response to 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 -
5. Re: Security Regressions in EJB3 TestSuite
anil.saldhana Mar 30, 2008 12:07 AM (in response to alrubinger)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. -
6. Re: Security Regressions in EJB3 TestSuite
alrubinger Mar 30, 2008 1:07 AM (in response to alrubinger)I couldn't find replacements for the following:
SecurityAssociation.getPrincipal(); SecurityAssociation.getCallerPrincipal();
...are there?
S,
ALR -
7. Re: Security Regressions in EJB3 TestSuite
alrubinger Mar 30, 2008 2:41 AM (in response to alrubinger)Hmm...maybe:
SecurityContextAssociation.getSecurityContext().getUtil().getUserPrincipal();
S,
ALR -
8. Re: Security Regressions in EJB3 TestSuite
anil.saldhana Mar 30, 2008 11:27 AM (in response to alrubinger)"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. :) -
9. Re: Security Regressions in EJB3 TestSuite
alrubinger Mar 30, 2008 12:54 PM (in response to alrubinger)"anil.saldhana@jboss.com" wrote:
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 -
10. Re: Security Regressions in EJB3 TestSuite
anil.saldhana Mar 30, 2008 9:43 PM (in response to alrubinger)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?
-
11. Re: Security Regressions in EJB3 TestSuite
alrubinger Mar 31, 2008 12:16 AM (in response to 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 -
12. Re: Security Regressions in EJB3 TestSuite
wolfc Mar 31, 2008 3:11 AM (in response to alrubinger)"anil.saldhana@jboss.com" wrote:
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.)"anil.saldhana@jboss.com" wrote:
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! -
13. Re: Security Regressions in EJB3 TestSuite
alrubinger Mar 31, 2008 9:22 AM (in response to alrubinger) -
14. Re: Security Regressions in EJB3 TestSuite
alrubinger Mar 31, 2008 9:25 AM (in response to 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