Documentation Contents
[Published in the Proceedings of the 15th Annual Computer Security Applications Conference, Phoenix, AZ, December 1999]


        USER AUTHENTICATION AND AUTHORIZATION IN THE JAVA(TM) PLATFORM

    Charlie Lai, Li Gong, Larry Koved, Anthony Nadalin, and Roland Schemers

                        charlie.lai,li.gong@sun.com
                        Sun Microsystems, Inc.

                        koved,drsecure@us.ibm.com
                        International Business Machines, Inc.

                        schemers@onebox.com
                        onebox.com

Abstract

        Java(TM) security technology originally focused on creating a
        safe environment in which to run potentially untrusted code downloaded
        from the public network.  With the latest release of the Java(TM)
        Platform (the Java(TM) 2 Software Development Kit, v 1.2),
        fine-grained access controls can be placed upon critical resources
        with regard to the identity of the running applets and applications,
        which are distinguished by where the code came from and who signed it.
        However, the Java platform still lacks the means to enforce access
        controls based on the identity of the user who runs the code.
        In this paper, we describe the design and implementation of the
        Java(TM) Authentication and Authorization Service (JAAS),
        a framework and programming interface that augments the Java(TM)
        platform with both user-based authentication and access control
        capabilities.

Introduction

        The Java(TM) technology [8,12] emerged in 1995 with a prominently
        stated goal of providing a safe programming environment.  This means
        that Java security must provide a secure, readily-built platform
        on which to run Java enabled applications.  It also means that
        Java security must provide adequate and extensive security tools and
        services implemented in Java technology that enable independent
        software vendors (ISVs) to build a wider range of security-sensitive
        applications, for example, in the enterprise world.

        The latest release of the Java platform (Java 2) introduces a
        new security architecture [7] that uses a security policy to decide
        the granting of individual access permissions to running code
        (according to the code's characteristics, e.g., where the code is
        coming from and whether it is digitally signed and if so by whom).
        Future attempts to access protected resources will invoke security
        checks that compare the granted permissions with the permissions
        needed for the attempted access.  If the former includes the latter,
        access is permitted; otherwise, access is denied.

        Such a code-centric style of access control is unusual in that
        traditional security measures, most commonly found in sophisticated
        operating systems, are user-centric in that they apply control on the
        basis of who is running an application and not on the basis of which
        application is running.  One major rationale behind code-centric
        access control is that when a user uses a web browser to surf the net
        and runs executable content (e.g., mobile code written in Java) as
        needed, the user variable remains essentially constant.  On the other
        hand, the user may trust one piece of mobile code more than others and
        would like to run this code with more privileges.  Thus it is in fact
        natural to control the security of mobile code in a code-centric
        style.

        Nevertheless, it is obvious that Java is becoming widely used in a
        multi-user environment.  For example, an enterprise application or
        a public Internet terminal must deal with different users, either
        concurrently or sequentially, and must grant these users different
        privileges based on their identities.  The Java Authentication and
        Authorization Service (JAAS) is designed to provide a framework and
        standard programming interface for authenticating users and for
        assigning privileges.  Together with Java 2, an application can
        provide code-centric access control, user-centric access control,
        or a combination of both.

        The rest of the paper is organized as follows.  Sections 2 and 3
        introduce the basic concepts used by JAAS.  Section 4 describes the
        authentication model implemented by JAAS.  Section 5 describes the
        authorization framework for JAAS, and is broken up into several
        subsections.  Section 5.1 defines the JAAS user-based security policy,
        Section 5.2 covers the JAAS access control implementation,
        and Section 5.3 discusses scalability issues regarding the
        security policy.  Section 6 discusses the issue of logging into the
        Java virtual machine.  Section 7 follows with a summary.

2  Subjects and Principals

        Users often depend on computing services to assist them in performing
        work.  Furthermore services themselves might subsequently interact
        with other services.  JAAS uses the term, subject, to refer to any
        user of a computing service [9,17].  Both users and computing services,
        therefore, represent subjects.  To identify the subjects with which it
        interacts, a computing service typically relies on names.  However,
        subjects might not have the same name for each service and, in fact,
        may even have a different name for each individual service.
        The term, principal, represents a name associated with a
        subject [11,17].  Since subjects may have multiple names
        (potentially one for each service with which it interacts),
        a subject comprises a set of principals.  See Figure 1.

            public interface Principal {
                public String getName();
            }

            public final class Subject {
                public Set getPrincipals() { }
            }
                        
                Figure 1: Subject Class and Principals

        Principals can become associated with a subject upon successful
        authentication to a service.  Authentication represents
        the process by which one subject verifies the identity of another,
        and must be performed in a secure fashion; otherwise a perpetrator may
        impersonate others to gain access to a system.  Authentication
        typically involves the subject demonstrating some form of evidence to
        prove its identity.  Such evidence may be information only the subject
        would likely know or have (a password or fingerprint), or it may be
        information only the subject could produce (signed data using a
        private key).

        A service's reliance on named principals usually derives from
        the fact that it implements a conventional access control model of
        security [10].  This model allows a service to define a set of
        protected resources as well as the conditions under which
        named principals may access those resources.  Recent studies
        (PolicyMaker [4] and SPKI [5]) have focused on the limitations of using 
        conventional names in large distributed systems for access control,
        and note that public keys, instead, provide a more practical and
        scalable name representation.  JAAS, and SPKI as well, do not impose
        any restrictions on principal names.  Localized environments that have
        limited namespaces, or that do not rely on public key cryptography,
        may define principals that have conventional names.
        Large-scale distributed systems may use principals that allow
        the principal name to be a public key (encoded as a hex string,
        as in PolicyMaker).

3  Credentials

        Some services may want to associate other security-related attributes
        and data with a subject in addition to principals.  JAAS refers to
        such generic security-related attributes as credentials.  A credential
        may contain information used to authenticate the subject to new
        services.  Such credentials include passwords, Kerberos tickets [16],
        and public key certificates (X.509 [9], PGP [21], etc.),
        and are used in environments that support single sign-on.
        Credentials might also contain data that simply enables
        the subject to perform certain activities.  Cryptographic keys, for
        example, represent credentials that enable the subject to sign or
        encrypt data.  JAAS credentials may be any type of object.  Therefore,
        existing credential implementations (java.security.cert.Certificate,
        for example) can be easily incorporated into JAAS.  Third-party
        credential implementations may also be plugged into the JAAS
        framework.

        JAAS credential implementations do not necessarily have to contain
        the actual security-related data; they might simply reference the data.
        This occurs when the data must physically reside on a separate server,
        or even possibly in hardware (private keys on a smart card,
        for instance).  Also, JAAS does not impose any restrictions
        regarding credential delegation to third parties.  Rather it allows
        each credential implementation to specify its own delegation protocol
        (as Kerberos does), or leaves delegation decisions up to the
        applications.

        JAAS divides each subject's credentials into two sets.  One set contains
        the subject's public credentials (public key certificates, Kerberos
        tickets, etc).  The second set stores the subject's private credentials
        (private keys, encryption keys, passwords, etc).  To access a subject's
        public credentials, no permissions are required.  However, access
        to a subject's private credential set is security checked.
        See Figure 2.

            public final class Subject {
                ...
                public Set getPublicCredentials() { }  // not security checked
                public Set getPrivateCredentials() { } // security checked
            }
                        
                Figure 2: Subject Class and Credentials

4  Pluggable and Stackable Authentication

        Depending on the security parameters of a particular service,
        different kinds of proof may be required for authentication.
        The JAAS authentication framework is based on PAM [18,20],
        and therefore supports an architecture that allows system
        administrators to plug in the appropriate authentication
        services to meet their security requirements.  The architecture
        also enables applications to remain independent from the underlying
        authentication services.  Hence as new authentication services become
        available or as current services are updated, system administrators
        can easily plug them in without having to modify or recompile existing
        applications.

        The JAAS LoginContext class represents a Java implementation of the
        PAM framework.  The LoginContext consults a configuration that
        determines the authentication service, or LoginModule, that gets
        plugged in under that application (See Figure 3).
        The syntax and details of the configuration are defined by PAM.

            public final class LoginContext {
                public LoginContext(String name) { }
                public void login() { }         // two phase process
                public void logout() { }
                public Subject getSubject() { } // get the authenticated Subject
            }

            public interface LoginModule {
                boolean login();   // 1st authentication phase
                boolean commit();  // 2nd authentication phase
                boolean abort();
                boolean logout();
            }
                Figure 3: LoginContext Class and LoginModule Interface

        JAAS, like PAM, supports the notion of stacked LoginModules.
        To guarantee that either all LoginModules succeed or none succeed,
        the LoginContext performs the authentication steps in two phases.
        In the first phase, or the 'login' phase, the LoginContext invokes the
        configured LoginModules and instructs each to attempt the
        authentication only.  If all the necessary LoginModules successfully
        pass this phase, the LoginContext then enters the second phase and
        invokes the configured LoginModules again, instructing each to formally
        'commit' the authentication process.  During this phase each
        LoginModule associates the relevant authenticated principals and
        credentials with the subject.  If either the first phase or the
        second phase fails, the LoginContext invokes the configured
        LoginModules and instructs each to 'abort' the entire authentication
        attempt.  Each LoginModule then cleans up any relevant state they had
        associated with the authentication attempt.

        In addition to JAAS, the Generic Security Services Application
        Programmer's Interface (GSS-API) and Simple Authentication and
        Security Layer Application Programmer's Interface (SASL) [13,14]
        define frameworks that provide support for pluggable authentication.
        However, the GSS and SASL authentication frameworks
        are designed specifically for network communication protocols and,
        as such, provide additional support for securing network communications
        after authentication has completed.  While JAAS does accommodate
        general network-based authentication protocols (including
        Needham-Schroeder and EKE [15,2]) it also focuses on addressing the
        need to support pluggable authentication in stand-alone non-connection
        oriented environments.

5  Authorization

        Once authentication has successfully completed, JAAS provides
        the ability to enforce access controls upon the principals associated
        with the authenticated subject.  The JAAS principal-based access
        controls (access controls based on who runs code) supplement the
        existing Java 2 codesource-based access controls
        (access controls based on where code came from and who signed it).

5.1  Principal-Based Access Control

        As stated earlier, services typically implement the access control
        model of security, which defines a set of protected resources,
        as well as the conditions under which named principals
        may access those resources.  JAAS also follows this model,
        and defines a security policy to specify what resources are accessible
        to authorized principals.  The JAAS policy extends the existing
        default Java 2 security policy, and in fact, the two policies, together,
        form a single logical access control policy for the entire Java runtime.

        Figure 4 depicts an example codesource-based policy entry
        currently supported by the default policy provided with Java 2.
        This entry grants code loaded from 'foo.com', and signed by 'foo',
        permission to read all files in the 'cdrom' directory and its
        subdirectories.  Since no principal information is included
        with this policy entry, the code will always be able to read files
        from the 'cdrom' directory, regardless of who executes it.

            // Java 2 codesource-based policy
            grant Codebase "http://foo.com", Signedby "foo" {
                permission java.io.FilePermission "/cdrom/-", "read";
            }

                Figure 4: Codesource-Based Policy Entry

        Figure 5 depicts an example principal-based policy entry
        supported by JAAS.  This example entry grants code loaded from
        'bar.com', signed by 'bar', and executed by 'duke',
        permission to read only those files located in the '/cdrom/duke'
        directory.  To be executed by 'duke', the subject affiliated with the
        current access control context (see Section 5.2) must have an associated
        principal of class, 'bar.Principal', whose 'getName' method returns,
        'duke'.  Note that if the code from 'bar.com', signed by 'bar',
        ran stand-alone (it was not executed by 'duke'),
        or if the code was executed by any principal other than 'duke',
        then it would not be granted the FilePermission.
        Also note that if the JAAS policy entry did not specify
        the Codebase or Signedby information, then the entry's FilePermission
        would be granted to any code running as 'duke'.

            // JAAS principal-based policy
            grant Codebase "http://bar.com, Signedby "bar",
                  Principal bar.Principal "duke" {
                permission java.io.FilePermission "/cdrom/duke/-", "read";
            }

                Figure 5: Principal-Based Policy Entry

        JAAS treats roles and groups simply as named principals [10].
        Therefore access control can be imposed upon roles and groups just
        as they are with any other type of principal.
        See Figure 6.

            // an administrator role can access user passwords
            grant Principal foo.Role "administrator" {
                permission java.io.FilePermission "/passwords/-", "read, write";
            }

            // a basketball team (group) can read its directory
            grant Principal foo.Team "SlamDunk" {
                permission java.io.FilePermission "/teams/SlamDunk/-", "read";
            }

                Figure 6: Role-Based and Group-Based Policy Entries

        For flexibility, the JAAS policy also permits the
        Principal class specified in a grant entry to
        be a PrincipalComparator (the class implements the PrincipalComparator
        interface).  The permissions for such entries are granted to any subject
        that the PrincipalComparator implies.  See Figure 7.

            public interface PrincipalComparator {
                boolean implies(Subject subject);
            }
            
            // regular users can access a temporary working directory
            grant Principal bar.Role "user" {
                permission java.io.FilePermission "/tmp/-", "read, write";
            }

                Figure 7: PrincipalComparator Interface and Example Policy Entry

        Figure 7 demonstrates how PrincipalComparators can be used
        to support role hierarchies [19].  In this example
        assume that an administrator role is senior to a user role and, as such,
        administrators inherit all the permissions granted to regular users.
        To accommodate this hierarchy, 'bar.Role' must simply implement
        the PrincipalComparator interface, and its implies method must
        return, true, if the provided subject has an associated
        "administrator" role principal.  Note that although the JAAS policy
        supports role hierarchies via the PrincipalComparator interface,
        administrators are not limited by it.  JAAS can accommodate
        alternative role-based access control mechanisms (such as that deined 
        in [6]), as long as the alternative access controls can be expressed
        either through the existing Java 2 policy or the new JAAS policy.

5.2  Access Control Implementation

        The Java 2 runtime enforces access controls via the
        java.lang.SecurityManager, and is consulted any time untrusted code
        attempts to perform a sensitive operation (accesses to the local file
        system, for example).  To determine whether the code has sufficient
        permissions, the SecurityManager implementation delegates
        responsibility to the java.security.AccessController,
        which first obtains an image of the current AccessControlContext,
        and then ensures that the retrieved AccessControlContext contains
        sufficient permissions for the operation to be permitted.

        JAAS supplements this architecture by providing the method,
        Subject.doAs, to dynamically associate an authenticated subject
        with the current AccessControlContext.  Hence, as subsequent access
        control checks are made, the AccessController can base its decisions
        upon both the executing code itself, and upon the principals
        associated with the subject.  See Figure 8.

            public final class Subject {
                ...
                // associate the subject with the current
                // AccessControlContext and execute the action
                public static Object doAs(Subject s,
                                java.security.PrivilegedAction action) { }
            }

                Figure 8: Subject doAs Method

        To illustrate a usage scenario for the doAs method,
        consider when a service authenticates a remote subject,
        and then performs some work on behalf of that subject.  For security
        reasons, the server should run in an AccessControlContext bound
        by the subject's permissions.  Using JAAS, the server can ensure
        this by preparing the work to be performed as a
        java.security.PrivilegedAction, and then by invoking the doAs method,
        providing both the authenticated subject, as well as the prepared
        PrivilegedAction.  The doAs implementation associates the subject with
        the current AccessControlContext and then executes the action.
        When security checks occur during execution, the Java 2 SecurityManager
        queries the JAAS policy, updates the current AccessControlContext
        with the permissions granted to the subject and the executing
        codesource, and then performs its regular permission checks.
        When the action finally completes, the doAs method simply removes
        the subject from the current AccessControlContext,
        and returns the result back to the caller.

        To associate a subject with the current AccessControlContext,
        the doAs method uses an internal JAAS implementation of the
        java.security.DomainCombiner interface, newly introduced in
        version 1.3 of the Java 2 SDK.  It is through the JAAS DomainCombiner
        that the existing Java 2 SecurityManager can be instructed to query
        the JAAS policy without requiring modifications to the SecurityManager
        itself.  Details of the interaction between the Java 2 SecurityManager
        and DomainCombiners are documented in the javadocs for the
        java.security.DomainCombiner interface.
        
Section 5.3  Scalability of the Access Control Policy

        The JAAS principal-based access control policy was intentionally
        designed to be consistent with the existing codesource-based policy
        in the Java 2 platform.  The default policy implementations provided
        with both Java 2 and JAAS reside in a local file, and assume that all
        policy decisions can be defined and made locally.  Obviously,
        this design does not scale beyond small localized environments.
        KeyNote [3] and SPKI both address the limitations of such
        access control designs, and discuss alternative solutions that
        enable the delegation of policy responsibilities to certified
        3rd parties.  By delegating policy-making responsibilities,
        access control policies can easily scale to serve larger systems.

        To improve scalability, both the Java 2 and JAAS file-based policy
        implementations can be replaced with alternative implementations
        that support delegation.  This is achieved by specifying the
        alternative implementations in the 'java.security' properties file
        located in the lib/security subdirectory from where the Java runtime
        environment was installed.  The designs of potential alternative
        implementations are beyond the scope of this paper.

Section 6  Logging in to the Java Virtual Machine

        With support from the JAAS framework, the Java virtual machine (VM)
        can be augmented to provide a general login facility for users.
        This would enable the VM itself to impose access controls based on who
        logged in.  In fact, [1] investigates and describes the constructs
        necessary to support a multi-user environment within a VM.
        In such an environment, individual users log into the VM and are
        each given an execution shell in which to launch commands and
        applications (similar to UNIX).  The VM imposes access controls
        based on the identity of the user, and special UserPermissions
        may be granted to code running as a particular user to permit access
        to particular resources.

        JAAS can serve as the underlying authentication architecture
        for such a system.  Also, the environment described in [1]
        focuses on user-based authentication and access control from
        the point of view of the Java virtual machine.  The JAAS framework
        supplements this environment by providing the support necessary for
        developers to build the same user-based authentication and
        access control capabilities into their own applications.

Section 7  Summary and Future Directions

        In this paper, we have outlined the design and implementation of the
        Java(TM) Authentication and Authorization Service (JAAS),
        a framework and programming interface that augments the
        Java(TM) platform with both pluggable authentication and
        principal-based access control capabilities, without requiring
        modifications to the Java 2 core.  Although individual pluggable
        LoginModules can be written in native code, the basic JAAS framework
        can be written entirely in Java.  A prototype implementation of the
        framework has been developed, and is currently packaged as a
        Java 2 standard extension consisting of approximately 25 classes
        partitioned into four packages.

        As Java technology is used to construct not just a single desktop but
        a full-fledged distributed system, a whole new range of distributed
        systems security issues (such as those we touched upon in the
        Introduction chapter) must be tackled.  For example, additional
        mechanisms are needed to make RMI secure in the presence of hostile
        network attacks.  For Jini, service registration and location must be
        securely managed if the environment contains coexisting but
        potentially mutually hostile parties.  There is a full set of
        higher-level concepts and services that must be secured, such
        as transactions for electronic commerce.  There are also many
        lower-level security protocols that we can leverage on, such as
        the network security protocols Kerberos and IPv6.  JAAS is a critical
        building block for all these issues.

Section 8  Acknowledgements

        We are grateful to Bob Scheifler for his comments and feedback on
        the JAAS architecture.  We also thank Bruce Rich, Kent Soper,
        Anat Sarig, Maryann Hondo, and David Edelsohn for their work in
        helping to define JAAS' functional requirements, and for their
        assistance in testing and documenting JAAS' features.
        Whitfield Diffie, Gary Ellison, Rosanna Lee, Jan Luehe, Peter Neumann,
        Jeff Nisewanger, Jerome Saltzer, Fred Schneider, Michael Schroeder,
        Scott Seligman, and Rob Weltman all contributed to early JAAS designs.
        Maxine Erlund provided management support for the JAAS project.
        Sriramulu Lakkaraju and Narendra Patil wrote product tests for JAAS.
        Scott Hommel helped edit this paper.

References

   [1]  D. Balfanz and L. Gong.  Experience with Secure Multi-Processing
        in Java.  In Proceedings of ICDCS, Amsterdam, The Netherlands, May 1998.

   [2]  S. Bellovin and M. Merritt.  Encrypted Key Exchange: Password-Based
        Protocols Secure Against Dictionary Attacks.  In Proceedings of the
        IEEE Symposium on Research in Security and Privacy, pages 72-84,
        Oakland, California, May 1992.

   [3]  M. Blaze, J. Feigenbaum, and J. Lacy.  Decentralized Trust Management.
        In Proceedings of the IEEE Conference on Security and Privacy,
        Oakland, California, May 1996.

   [4]  M. Blaze, J. Feigenbaum, and A. Keromytis.  KeyNote: Trust Management
        for Public-Key Infrastructures.  Security Protocols International
        Workshop, England, 1998.

   [5]  C.M. Ellison, B. Frantz, B. Lampson, R. Rivest, B.M. Thomas, and
        T. Ylonen.  SPKI Certificate Theory.  Internet Draft,
        Internet Engineering Task Force, November 1998.

   [6]  L. Giuri and F.U. Bordoni.  Role-Based Access Control in Java.
        In Proceedings of the 3rd ACM Workshop on Role-Based Access Control,
        Fairfax, Virginia, 1998.

   [7]  L. Gong, M. Mueller, H. Prafullchandra, and R. Schemers.
        Going Beyond the Sandbox: An Overview of the New Security Architecture
        in the Java(TM) Development Kit 1.2.  In Proceedings of the USENIX
        Symposium on Internet Technologies and Systems, pages 103-112,
        Monterey, California, December 1997.

   [8]  J. Gosling, Bill Joy, and Guy Steele.  The Java Language Specification.
        Addison-Wesley, Menlo Park, California, August 1996.

   [9]  R. Housley, W. Ford, T. Polk, and D. Solo.  Internet X.509 Public Key
        Infrastructure Certificate and CRL Profile.  Request for Comments 2459,
        Internet Engineering Task Force, January 1999.

   [10] B. Lampson.  Protection.  ACM Operating Systems Review,
        8(1):18-24, January 1974.

   [11] B. Lampson, M. Abadi, M. Burrows, and E. Wobber.  Authentication in
        Distributed Systems: Theory and Practice.  ACM Transactions on Computer
        Systems, 10(4):265-310, November 1992.

   [12] T. Lindholm and F. Yellin.  The Java Virtual Machine Specification.
        Addison-Wesley, Menlo Park, California, 1997.

   [13] J. Linn.  Generic Security Service Application Program Interface,
        Version 2.  Request for Comments 2078, Internet Engineering Task Force,
        January 1997.

   [14] J. Myers.  Simple Authentication and Security Layer (SASL).
        Request for Comments 2222, Internet Engineering Task Force,
        October 1997.

   [15] R.M. Needham and M.D. Schroeder.  Using Encryption for Authentication
        in Large Networks of Computers.  Communications of the ACM,
        21(12):993-999, December 1978.

   [16] B.C. Neuman and T. Ts'o.  Kerberos: An Authentication Service for
        Computer Networks.  IEEE Communications, 32(9):33-38, September 1994.

   [17] T. Ryutov and B.C. Neuman.  Access Control Framework for Distributed
        Applications.  Internet Draft, Internet Engineering Task Force,
        November 1998.

   [18] V. Samar and C. Lai.  Making Login Services Independent from
        Authentication Technologies.  In Proceedings of the SunSoft
        Developer's Conference, March 1996.

   [19] R.S Sandhu, E.J. Coyne, H.L. Feinstein, and C.E. Youman.  Role-Based
        Access Control Models.  IEEE Computer, 29(2):38-47, February 1996.

   [20] www.opengroup.org.  X/Open Single Sign-On Service (XSSO) - Pluggable
        Authentication.  Preliminary Specification P702, The Open Group,
        June 1997.

   [21] P. Zimmerman.  PGP User's Guide.  MIT Press, Cambridge, 1994.


Oracle and/or its affiliates Copyright © 1993, 2015, Oracle and/or its affiliates. All rights reserved.
Contact Us