Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-4625

EJB SecurityContextInterceptor attempts JAAS login which doesn't work for JASPIC authentications

    Details

      Description

      After a user has successfully authenticated with JASPIC it's not possible to access any method in a secured EJB bean, irrespective of the actual security constraints.

      The problem is that when an EJB is "secured" an extra interceptor is added to the chain: org.jboss.as.ejb3.security.SecurityContextInterceptor.SecurityContextInterceptor.

      This interceptor calls org.jboss.as.security.service.SimpleSecurityManager.push, which tries to establish a new stacked security context by attempting a login to a JAAS login module associated with the security domain.

      However, when the caller authenticated via a JASPIC auth module, there isn't necessarily such a JAAS login module (the JASPIC auth module is not required to call a JAAS login module, and even if it did it may not be the JAAS login module JBoss knows about).

      The problematic part in SimpleSecurityManager:

      public void push(final String securityDomain, final String runAs, final String runAsPrincipal, final Set<String> extraRoles) {
              boolean contextPushed = false;
              boolean securityContextEstablished = false;
      
              final SecurityContext previous = SecurityContextAssociation.getSecurityContext();
              try {
                  contexts.push(previous);
                  contextPushed = true;
      
                  SecurityContext current = establishSecurityContext(securityDomain);
                  securityContextEstablished = true;
      
                  if (previous != null) {
                      current.setSubjectInfo(previous.getSubjectInfo());
                      current.setIncomingRunAs(previous.getOutgoingRunAs());
                  }
      
                  RunAs currentRunAs = current.getIncomingRunAs();
                  boolean trusted = currentRunAs != null && currentRunAs instanceof RunAsIdentity;
      
                  if (trusted == false) {
                    
                      boolean authenticated = false;
                      if (SecurityActions.remotingContextIsSet()) {
                          // ...
                      }
      
                      // If we have a trusted identity no need for a re-auth.                
                      if (authenticated == false) {
                          // THIS WILL EVENTUALLY ATTEMPT A JAAS LOGIN WHICH FAILS
                          authenticated = authenticate(current, null);
                      }
      

      The (condensed) stack that will lead to an exception is the following:

      javax.security.auth.login.FailedLoginException: PBOX000070: Password invalid/Password required
      
      org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(Principal, Object)
      org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(Principal, Object, Subject)
      org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(Principal, Object, Subject)
      org.jboss.as.security.service.SimpleSecurityManager.authenticate(SecurityContext, Subject)
      org.jboss.as.security.service.SimpleSecurityManager.push(String, String, String, Set<String>)
      org.jboss.as.ejb3.security.SecurityContextInterceptor.SecurityContextInterceptor(SecurityContextInterceptorHolder)
      

      Since the SimpleSecurityManager is already doing a check to see if the call is remote or not, I wonder if it could not simply accept the existing security context as-is for local calls (not even start a new context) or just consider the existing security context as trusted for local calls just like a RunAS identity.

      Note that this depends on SECURITY-744 and SECURITY-745, since otherwise there is no valid security context at all.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  sguilhen Stefan Guilhen
                  Reporter:
                  atijms Arjan Tijms
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  8 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: