3 Replies Latest reply on Mar 20, 2006 12:31 PM by starksm64

    Duration of container getCallerPrincipal

    starksm64

      Related to: http://jira.jboss.com/jira/browse/JBAS-2947 is an issue that I thought had already been addressed, but still has an issue with running under a security manager. The org.jboss.test.cmp2.audit.test.AuditUnitTestCase passes without a security manager, but fails when run with it security manager. The difference I'm seeing is that the SecurityActions.getCallerPrincipal() value in getCallerPrincipalInternal returns null in the after completion usage when there is no security manager, but is the incoming caller when there is a security manager. Somewhere there must be a security permission problem that is resulting in the inconsistency.

      I had already made a change for the audit usecase when there was no security manager to look to the call principal. It looks like when the context setPrincipal call is made, the beanPrincipal should be initialized to the 'getCallerPrincipalInternal' to preserve the value until the call stack unwinds past the SecurityInterceptor. Before making such a change I want to track down the current difference in behavior.

        • 1. Re: Duration of container getCallerPrincipal
          starksm64

          The difference in behavior is due to the difference in client-login configuration between the jacc and jacc-securitymgr:

          jacc login-config.xml/client-login

           <application-policy name="client-login">
           <authentication>
           <login-module code="org.jboss.security.ClientLoginModule" flag="required">
           </login-module>
           </authentication>
           </application-policy>
          


          jacc-securitymgr login-config.xml/client-login
           <application-policy name = "client-login">
           <authentication>
           <login-module code = "org.jboss.security.ClientLoginModule"
           flag = "required">
           <!-- Any existing security context will be restored on logout -->
           <module-option name="restore-login-identity">true</module-option>
           </login-module>
           </authentication>
           </application-policy>
          


          This is due to the create-config macro picking up the test-configs/jacc overrides only for the jacc config run. There really should be a base-testconfig to allow for reuse of the test-configs with different server config targets.


          • 2. Re: Duration of container getCallerPrincipal
            anil.saldhana

            Apart from the test configuration changes, Scott, you made changes to Enterprise Context wrt beanPrincipal. Could you add in a few lines to this thread so that your changes are recorded in this discussion?

            • 3. Re: Duration of container getCallerPrincipal
              starksm64

              The beanPrincipal which defines the getCallerPrincipal result is set everytime the request principal is set via the setPrincipal call. This ensures there no time of use dependency on the getCallerPrincipal method anywhere along the interceptor stack after the SecurityInterceptor.