Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8266592

Alternate Subject.doAs APIs that don't depend on Security Manager APIs

    XMLWordPrintable

    Details

    • Type: Enhancement
    • Status: Open
    • Priority: P3
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: security-libs
    • Labels:
      None

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              weijun Weijun Wang
              Reporter:
              mullan Sean Mullan
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated: