Thanks for your info about 8.1.0.Final release. I upgraded.

My problem still exists though. I'll try to make it more clear:

I use a JAAS login configuration in my webapp, declared in standalone.xml. Wildfly plugs a JAASIdentityManagerImpl into my application.

Now my issues:

1.

public Account verify(Account account) in JAASIdentityManagerImpl

will reauthenticate the account (invoking the defined login modules, including a ldap bind in my case)

now verify will be called for every request.

This in itself is a huge performance issue I think.

btw. org.jboss.as.domain.http.server.security.RealmIdentityManager simple does

public Account verify(Account account) { return account; }

2.

to enable verify / reauthenticate, org.wildfly.extension.undertow.security.AccountImpl stores the credentials in cleartext during its lifetime.

This seems like a security security issue to me, especially if the Account is persisted as part of the sesssion, if sessions are not only stored in-memory

3.

JBoss Authentication allows to define a "CallerPrincipal" role group. If it exists, the first member of this group will replace the original username as the subjects identity

So "John" logging in with password "mypass" with a Role Group "CallerPrincipal" containing Principal "Mary" will result in the authenticated Account principal "Mary" with credentials "mypass"

I use this CallerPrincipal mapping to map from ldap username "John" to application username "Mary". That "Mary" was "John" is I think lost in the session stored Account.

Now here is where JAASIdentityManagerImpl.verify() not only becomes a performance issue, but is buggy: It does not take CallerPrincipal mapping into account.

Basically - in my example - on the very next request after login of "John", CachedAuthenticatedSessionMechanism calles JAASIdentityManagerImpl.verify() with Account "Mary" / "mypass"

verify invokes jaas login modules with "Mary" / "mypass" and login fails ("Mary" is not known, "John" was) and the authenticated session is invalidated.

4.

injection of org.wildfly.extension.undertow.security.JAASIdentityManagerImpl is hardcoded, I can't easily replace it a custom IdentityManager that does not reauthenticate on verify.

private void org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.handleIdentityManager(final DeploymentInfo deploymentInfo) {

     deploymentInfo.setIdentityManager(new JAASIdentityManagerImpl(sdc));

}

But after a bit of thinking, I made a workaround for this issues. I created a ServletExtension as documented in http://undertow.io/documentation/servlet/using-non-blocking-handlers-with-servlet.html

It takes the JAAS-IDM from deploymentInfo and wraps a delegate around that simply returns account in case of verify:

package wildfly.workaround;

import io.undertow.security.idm.Account;
import io.undertow.security.idm.Credential;
import io.undertow.security.idm.IdentityManager;
import io.undertow.servlet.api.DeploymentInfo;

import javax.servlet.ServletContext;

public class NonVerifyingIdentityManagerExtension implements io.undertow.servlet.ServletExtension {
  public static class NonVerifyingIdentityManagerDelegate implements IdentityManager {
    protected IdentityManager delegate;

    public NonVerifyingIdentityManagerDelegate(IdentityManager delegate) {
      super();
      this.delegate = delegate;
    }

    public Account verify(Account account) {
      return account;
    }

    public Account verify(String id, Credential credential) {
      return delegate.verify(id, credential);
    }

    public Account verify(Credential credential) {
      return delegate.verify(credential);
    }
   
  }

  public NonVerifyingIdentityManagerExtension() {
  }

  public void handleDeployment(DeploymentInfo deploymentInfo, ServletContext servletContext) {
    IdentityManager idm = deploymentInfo.getIdentityManager();
    idm = createNonIdentityManagerDelegate(idm);
    deploymentInfo.setIdentityManager(idm);
  }

  public IdentityManager createNonIdentityManagerDelegate(IdentityManager delegate) {
    return new NonVerifyingIdentityManagerDelegate(delegate);
  }
}