According to JASPIC 1.1.2 an authentication context can manage multiple auth modules:
An authentication context is responsible for constructing, initializing, and coordinating the invocation of one or more encapsulated authentication modules.
If the context implementation supports the configuration of multiple authentication modules within a context (for example, as sufficient alternatives), the context coordinates the invocation of the authentication modules on behalf of both the message processing runtime and the authentication modules.
JASPIC 220.127.116.11 gives some more details:
If a context encapsulates multiple authentication modules, the context must embody the control logic to determine which modules of the context are to be invoked and in what order.
Contexts which encapsulate alternative sufficient modules must ensure that the same message values are passed to each invoked alternative of the context. If a context invokes multiple authentication modules, the context must combine the AuthStatus values returned by the invoked authentication modules to establish the AuthStatus value returned by the context to the messaging runtime.
The context implementation must define the logic for combining the returned AuthStatus values.
This gives a framework to work with, but it does not specify the exact semantics of how the handling of multiple modules (stacking) should take place. Each implementation is free to do this largely in an implementation specific way. This makes it hard to cary over a configuration of modules from one server to the other.
In order to improve portability and as a possible precursor to a standardized declarative way to configure auth modules, I would like to request to standardize a specific way of handling multiple auth modules and demanding the runtime to make an authentication context available that implements this.
Possibly the JAAS/PAM semantics of Required, Requisite, Sufficient and Optional could be formally specified for use with JASPIC. (the existing specification already hints to supporting the Sufficient semantics)