[jboss-jira] [JBoss JIRA] (SECURITY-746) EJB SecurityContextInterceptor attempts JAAS login which doesn't work for JASPIC authentications

[arjan tijms (JIRA)]

arjan tijms created SECURITY-746:
------------------------------------

             Summary: EJB SecurityContextInterceptor attempts JAAS login which doesn't work for JASPIC authentications
                 Key: SECURITY-746
                 URL: https://issues.jboss.org/browse/SECURITY-746
             Project: PicketBox 
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: arjan tijms
            Assignee: Anil Saldhana


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}}:

{code}
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);
                }
{code}

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

{noformat}
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)
{noformat}

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.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira