10 Replies Latest reply on Dec 14, 2006 8:59 AM by sts

    Unexpected Security Identity Propagation Switch

    soon_shin

      Environment:
      JBoss 4.0.2

      Problem Definition:

      I have a web application utilizing JAAS (form based authentication, DatabaseServerLoginModule), Struts, Session Beans and Entity Beans. This configuration is working successfully, but I have noticed an unexpected switch in the Principal that is associated with the EJB invocation layer when more than one call to a session bean is made from the web tier (Struts Action) within one request.

      Permissions & Security Identity

      Web Tier - User Credentials

      - id=joe
      - password=pw
      - role=administratorRole


      Session Bean (fooSessionBean)
      - Permissions: administratorRole, internalRole
      - Security Identity (run-as): internalRole


      Entity Bean (fooEntityBean)
      - Permission: internalRole
      - Security Identity (run-as): internalRole


      Note: fooSessionBean.bar() calls fooEntityBean.bar()

      Scenario

      1) User logs in via form authentication (j_security_check)

      2) User clicks on link that invokes an action that results in 2 calls to fooSessionBean.bar().

      2a) First call to fooSessionBean.bar() is successful.

      2b) Second call to fooSessionBean.bar() fails.

      javax.security.auth.login.FailedLoginException: No matching username found in Principals


      I set a breakpoint in the JaasSecurityManager.isValid(..) (line 251) and noticed that this method is called on the 'second' invocation of the fooSessionBean.bar() where the
      principal = [roles=[internalRole],principal=anonymous]
      credential = null


      It appears as if the security-identity (run-as) defined for fooSessionBean is replacing the original principal credentials of the user that logged in during the first call to fooSessionBean.bar().

      Questions

      1. Has anyone else run into this problem? Suggestions?
      2. Is there a way to configure JBoss, so that the second call uses the same/original principal credentials that were used in the first call?

      Thanks in advance.