Home » JAAS Security in Action

JAAS Security in Action

More than ever before, corporations are clamoring to evaluate their security architectures and identify any gaps. The Java platform, and specifically the J2EE platform, provides some of the most robust application-level security available today. The Java Authentication and Authorization Service (JAAS), which was introduced as an optional security package for the Java 2 SDK, Standard Edition, version 1.3, has been formally included as a part of the standard Java packages as of version 1.4.

This 10-Minute Solution provides a brief introduction to the JAAS (pronounced “Jazz”) architecture, API, and programming model. It covers both authentication and authorization with JAAS, providing full working code examples that demonstrate JAAS security in action.

How do I implement security, one of the most important aspects of today’s software applications, into my Java environment when most security implementations are inflexible, proprietary systems?

The Java Authentication and Authorization Service (JAAS) is a flexible, standardized API that supports runtime pluggability of security modules.What Is JAAS?
According to Sun’s Web site, “The Java Authentication and Authorization Service (JAAS) is a set of packages that enables services to authenticate and enforce access controls upon users. It implements a Java version of the standard Pluggable Authentication Module (PAM) framework, and supports user-based authorization.”

In practice, JAAS represents the new Java security standard, as it has formally been added to the JDK 1.4 code base. From an architectural standpoint, JAAS implements a Java version of the Pluggable Authentication Module (PAM) framework. First released in May 2000 by The PAM Forum, the framework is a modularized architecture designed to support the seamless exchange of one security protocol component for another. The framework allows multiple authentication technologies and/or authentication approaches to be added without changing or interfering with any of the existing login services. PAM can be used to integrate login services with various authentication technologies, such as RSA, DCE, Kerberos, S/Key, and even to support smart card-based authentication systems.

Authenticating with JAAS
JAAS authentication is deployed in a pluggable manner, using code modules that implement certain interfaces. This enables Java applications to remain decoupled from the underlying authentication technologies. Additional authentication protocols and updated authentication technologies can be plugged in at runtime without modifying the application or recompiling the source code.

The JAAS Authentication API is quite extensive. The key interfaces and classes that you need to familiarize yourself with are as follows:

Callback ? Implementations of this interface encapsulate information (usernames, passwords, error and warning messages) that is exchanged between security services and a CallbackHandler.

CallbackHandler ? An application implements a CallbackHandler and passes it to underlying security services to facilitate interaction between the security services and the application.

LoginContext ? The LoginContext class provides the basic methods used to authenticate Subjects in a neutral manner, decoupled from the underlying authentication technology.

LoginModule ? Authentication technology providers implement this interface to provide a particular type of authentication via a pluggable module.

Principal ? The Principal interface represents the abstract notion of a principal, which can be used to represent any unique entity (individual, corporation, organization, login id, social security number, etc.) that can be authenticated.

Subject ? A Subject object represents a grouping of related information for a single entity, such as a person. One or more Principals are bound to a subject. Each Principal represents one identity for the subject (name, social security #, etc.). A Subject also maintains security-related attributes (passwords and cryptographic keys, for example).

Authorization with JAAS
JAAS authorization is built on top of JAAS authentication. It augments the existing code-centric access controls that were introduced with the Java 2 platform (JDK 1.2.x) with new user-centric access controls. In this way, JAAS authorization allows you to grant permissions based not on just what code is running but also on who is running it.

After a user has been authenticated by JAAS, the authorization API associates the Subject (created to represent the authenticated entity) with an appropriate access control context. Whenever the Subject attempts a restricted operation (database access, local file access, etc.), the Java runtime consults the policy file to determine which Principal(s) may perform the operation. If the Subject in question contains the designated Principal, the Java runtime allows the operation. Otherwise, it throws an exception.

You don’t need to import additional packages to access the JAAS authorization features, because JAAS authorization is built on top of JAAS authentication. In addition to the classes and interfaces used in the authentication piece, one additional interface is of interest for the simple example in this Solution:

PrivilegedAction ? This interface defines only one member, a method named run(). It accepts no parameters and returns type Object. A class wanting to restrict access to one or more actions implements this interface and puts the calls to the restricted functions within its run() method.

See JAAS in Action
Included with this Solution is a downloadable zip file that contains all the source code and class files necessary to see JAAS authentication and authorization in action.

Authentication Files

SimpleAuth.java ? This file contains the main() method. It creates a LoginContext object by passing in a LoginModule configuration id (“JAAS_Module”) and an instance of the CallbackHandler interface. The LoginContext reads a configuration file, looking for the configuration ID. Upon finding a match, it instantiates the specified LoginModules. Each LoginModule is initialized with a Subject, a CallbackHandler, shared LoginModule state, and LoginModule-specific options. Finally, the login process is kicked off by calling the login() method on the LoginContext object (which is implemented by the LoginModule class).

SimpleJAAS.config ? This file associates configuration IDs (simple text string) with LoginModules and optional properties.

SimpleCallbackHandler.java ? This file implements the CallbackHandler interface and handles the callback events passed by the security service components.

SimpleLoginModule.java ? This file implements the LoginModule interface and interfaces between the user and the CallbackHandler to authenticate the user. It uses two arrays to maintain the set of possible usernames and passwords. The passwords are then compared by passing a PasswordCallback instance to the SimpleCallbackHandler and using the readPassword() method defined in the SimpleCallbackHandler class.

SimplePrincipal.java ? This file provides a bare-bones implementation of the Principal interface.

Authorization Files

SimpleAuthz.java ? This class is identical to the SimpleAuth.java class in all but one respect. After authenticating the user, it attempts a privileged action. To do this, the code obtains a reference to the current Subject and calls the doAsPrivileged() method from that object reference. We pass the Subject reference and an instance of the SimpleAction class into this method. The Java runtime then will take the supplied Subject reference and attempt to execute the privileged action defined within the run() method of the SimpleAction class.

SimpleAction.java ? This class implements the PrivilegedAction interface and defines a single method, run(). It attempts to perform a few actions that are restricted to privileged users (as defined by the policy file). If the Subject has the appropriate privileges to perform these actions, the method will execute without any trouble. Otherwise, it throws an exception.

SimpleJAAS.policy ? This file defines the activities for which permission has been granted and which code has permission to perform them (code-level access). These grant statements can further be narrowed to allow only a particular Principal (user-level access).

To test the application, run the provided script and indicate whether you want to test just authentication (‘run auth’) or authentication and authorization (‘run authz’). When prompted for a username and password, provide any of the following pairs:

guest, sesame

user1, pass1

user2, pass2

You will receive verbose output if the debug option in the config file debug property is set to ‘true’. The output will be limited if it is set to ‘false’.

About Our Editorial Process

At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

See our full editorial policy.