[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.
