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

EJB SecurityContextInterceptor attempts JAAS login which doesn't work for JASPIC authentications ------------------------------------------------------------------------------------------------ Key: WFLY-4625 URL: https://issues.jboss.org/browse/WFLY-4625 Project: WildFly Issue Type: Feature Request Reporter: arjan tijms Assignee: Stefan Guilhen Labels: authentication, ejb, jaspi, jaspic, security, security-context Fix For: 9.0.0.CR2, 10.0.0.Alpha2 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. Note that this depends on SECURITY-744 and SECURITY-745, since otherwise there is no valid security context at all.