0 Replies Latest reply on Nov 17, 2016 3:03 AM by vit.gorbunov

    Possible security context corruption with EJB async calls

    vit.gorbunov

      We've had unexpected authorization errors for some EJB async calls at production, because principal became null.

       

      During investigation we found the following defect.

      [WFLY-2016] Security context associated with EJB asynchronous invocations can potentially be corrupted over time by the …

      which was fixed by cloning JBossSecurityContext.

       

      But clone implementation in JBossSecurityContext had the following bug

      JBossSecurityContext error in clone() · Issue #29 · picketbox/picketbox · GitHub

       

      And even applied here fix doesn't seem correct to me. This clone method is not deep enough, e.g. SubjectInfo will be still shared.

       

      Unfortunately we couldn't reproduce the issue with arquillian test, but we applied custom clone method implementation anyway.

       

        private static SecurityContext cloneSecurityContext(SecurityContext originalSecurityContext)
        {
          final SecurityContext clonedSecurityContext;
          if (originalSecurityContext instanceof JBossSecurityContext)
            try {
              clonedSecurityContext = new JBossSecurityContext(originalSecurityContext.getSecurityDomain());
              SubjectInfo subjectInfo = originalSecurityContext.getSubjectInfo();
              JBossSecurityContextUtil securityContextUtil = new JBossSecurityContextUtil(clonedSecurityContext);
              securityContextUtil.createSubjectInfo(CredentialIdentityFactory.NULL_IDENTITY, subjectInfo.getAuthenticatedSubject());
              securityContextUtil.setIdentities(subjectInfo.getIdentities());
              securityContextUtil.setRoles(subjectInfo.getRoles());
              RunAs newIncomingRunAs = null;
              if(originalSecurityContext.getIncomingRunAs() instanceof RunAsIdentity)
                newIncomingRunAs = (RunAsIdentity)((RunAsIdentity) originalSecurityContext.getIncomingRunAs()).clone();
              clonedSecurityContext.setIncomingRunAs(newIncomingRunAs);
              RunAs newOutgoingRunAs = null;
              if(originalSecurityContext.getOutgoingRunAs() instanceof RunAsIdentity)
                newOutgoingRunAs = (RunAsIdentity)((RunAsIdentity) originalSecurityContext.getOutgoingRunAs()).clone();
              clonedSecurityContext.setOutgoingRunAs(newOutgoingRunAs);
            }
            catch (CloneNotSupportedException e) {
              throw new TechnicalRuntimeException(e);
            }
          else
            clonedSecurityContext = originalSecurityContext;
          return clonedSecurityContext;
        }
      

       

      After than problem disappeared.

      We have custom login module implementation as well, so maybe there is some problem on our level as well.

      But since Wildfly code is relying on cloning JBossSecurityContext - shouldn't this clone be deep?

       

      We were using jboss 7.2.0 then, and wildfly 8.2.1 now, but I checked the master branch for both wildfly and picketbox - seems that the code is the same.