JAAS provides APIs that authenticate and authorize users. The Subject::doAs APIs extend the Security Manager’s code-based access-control model to also take into account the user, or Subject, that is running the code. Different mechanisms such as GSSAPI and Kerberos can use the credentials in a Subject for authorization decisions. The Java Platform, by default, obtains credentials from the private or public credential sets associated with the Subject in the current thread’s access-control context via the Subject::getSubject(AccessControlContext) API.

A typical flow using JAAS, GSSAPI, and Kerberos is as follows: An application calls Subject::doAs with two parameters, namely a Subject containing credentials previously obtained via a JAAS login, and a PrivilegedAction or PrivilegedExceptionAction that executes a GSSAPI operation such as GSSManager::createCredential(), GSSContext::acceptSecContext(), or GSSContext::initSecContext(). An underlying Kerberos provider then accesses the Subject by calling Subject::getSubject(AccessControlContext) and retrieves or populates Kerberos credentials related to the subject. The application then uses these credentials for subsequent GSSAPI operations.

In effect, Subject::doAs is used as a mechanism to transport credentials across API boundaries by attaching them to the thread’s AccessControlContext, serving a purpose similar to a ThreadLocal. These credentials can be used for purposes other than code-based access control without enabling the Security Manager. However, they depend on APIs tightly related to the Security Manager, such as AccessController and DomainCombiner.

We should continue to support this important use case if the Security Manager is deprecated for removal. Decoupling this behavior from the Security Manager APIs and defining new APIs may be the best way forward.