The problem surrounds just the start() method (and possibly other lifecycle methods). @RunAs dosn't work, complains that the security context is missing when calling into a method with required permissions. Furthermore, examining the unauthenticated principal shows the principal for the "other" security domain, no matter what is specified as @SecurityDomain. Last of all, there is no transaction context - any attempt to update a database from an EntityManager within the start() method fails with "javax.persistence.TransactionRequiredException: EntityManager must be access within a transaction".

The original description of this bug follows - it is just one part of the larger problem. It looks like AOP interceptors aren't being applied to the start() methods of service beans, whereas this worked in JBoss 4.

The behavior of security domains on @Service beans has changed from 4.2 to 5.0.1. @RunAs no longer works. This seems to make it impossible for a @Service to call a secured bean.

Take two @Services, one ClientService and one ServerService. Here's the ServerService, note that it requires the "admin" role:

@Service(objectName="test:service=Server")
@SecurityDomain("foo")
@RolesAllowed("admin")
public class ServerService implements ServerManagement, Server
{
public void serve()

}

The client tries to call the server:

@Service(objectName="test:service=Client")
@SecurityDomain("foo")
@RunAs("admin")
public class ClientService implements ClientManagement
{
@EJB Server server;

public void start()

}

This generates exceptions "No security context set". Alternatively, if the Server is a stateless session ejb, the exception is "Caller unauthorized". This same code works in 4.2.

If it will help I can attach a simple test project but since the error occurs on deployment (service start), I don't know how to create a unit test.