8 Replies Latest reply on Sep 22, 2006 12:31 PM by anil.saldhana

    Custom Principal Propagation Related

    anil.saldhana

      I have a usecase where there is a clear mismatch on what is put on the SecurityAssociation thread local principal stack and what you really want.

      Usecase:
      * User logs into a web application with form auth.
      * JBoss Security Mgr creates a SimplePrincipal of the username and passes to the Jaas framework.
      * A login module creates a custom view of the username via a Custom Principal and into the shared state map.
      * ClientLoginModule populates the SA threadlocal stack with the custom principal.
      * Now that the form authentication is fine, the JBossSecurityMgrRealm populates the SA stack with subjectcontext.

      Now in the servlet, the user makes a call on an ejb (no jaas login). This time the security interceptor in the proxy picks up the principal on the SA stack (which happens to be the SimplePrincipal) and not the custom principal which is the view of the custom login module.

      I think this case falls through the crack for providing end-to-end security.

      Workaround:
      a) Have an explicit jaas login in the servlet such that the ClientLoginModule places the custom principal again on the SA stack. Issue is that there needs to be a way for the password to be obtained.
      b) Provide an additional option on the JBossSecurityMgrRealm to plug in a custom principal class, such that this principal class gets pushed on the SA stack rather than the simple principal.

      I like option b)

      Any other thoughts?

        • 1. Re: Custom Principal Propagation Related
          starksm64

          For propagation the ClientLoginModule needs to push the identity that was authenticated. When was the custom principal created? Describe the full workflow from incoming request to propagation to the ejb.

          The JBossSecurityMgrRealm cannot be involved in creating principals as its the security interceptor running in the context of the authentication request that has the knowledge and correct classpath.

          • 2. Re: Custom Principal Propagation Related
            anil.saldhana

            Workflow:

            1)User logs into webapp.
            2) JBossSecurityMgrRealm gets called with userid=aaa,password=hello
            3) JBossSecurityRealm.authenticate(username,pass)
            {
            //Create a simple principal to be passed to jaas
            SimplePrincipal sp = new SimplePrincipal(aaa);
            //Get the security manager
            securityMgr.isValid(sp,"hello");
            /** Note in the isValid call, the jaas framework gets called and custom LM creates a custom principal. ClientLM pushes it on the SA stack. The SA stack has the custom principal on the stack.
            **/
            //Ok
            SecurityAssociation.push(sp, hello);
            }

            4) Request lands at the servlet.
            5) In the servlet, there is call on an ejb (There is no explicit jaas login here)
            6) In the proxy, the SecurityInterceptor picks up the latest principal from the SA stack (that happens to be the last call on the SA done by the SecurityMgrRealm)
            7) The ejb is unhappy that it did not get the custom principal and chokes with a CCE.

            This usecase is when the web and the ejb components are in the same VM.

            • 3. Re: Custom Principal Propagation Related
              anil.saldhana

              The mismatch occurs because
              Step 1:
              the jaas auth happens at the beginning of the workflow and the Client Login Module would have placed the custom principal on the stack.
              Step 2:
              Since the authentication goes through fine, the JBossSecurityMgrRealm pushes its view of the username (a SimplePrincipal) on to the stack for use.

              • 4. Re: Custom Principal Propagation Related
                starksm64

                Why isn't the custom principal triggering reauthentication in the ejb container? The realm authenticated the simple principal and this is what should be cached. The custom principal is a derived identity for application consumption only.

                Are there two security domains involved here?

                • 5. Re: Custom Principal Propagation Related
                  anil.saldhana

                  One security domain.

                  There would be a reauth if the custom principal was ever picked up. It is sitting there on the SA stack. The Simple Principal got propagated.

                  The solution is to provide an option for the user to plug-in a custom principal class into the JBossSecurityMgrRealm.

                  • 6. Re: Custom Principal Propagation Related
                    starksm64

                    So the issue is how the ejb container getCallerPrincipal is behaving. Let's get the testcase into the testsuite so I can drill down into why the custom principal is not seen. I would suspect its a conflict between run-as behavior and the ClientLoginModule pushed principal.

                    • 7. Re: Custom Principal Propagation Related
                      anil.saldhana

                      http://jira.jboss.com/jira/browse/JBAS-3687

                      I am not able to reproduce the issue with a test case.

                      • 8. Re: Custom Principal Propagation Related
                        anil.saldhana

                        I would like to end this discussion as there is no evidence of an issue with custom principal propagation from both outside the VM as well as inside the application server.

                        Few things to remember:
                        * A custom principal that is created by a login module is its view of the authenticated user.
                        * Have the security domain between the layers involved in the propagation to be the same or have atleast one of the modules to be the custom principal creating login module.