IBM Skip to main content
Search for:   within 
      Search help  
     IBM home  |  Products & services  |  Support & downloads   |  My account

developerWorks > Java technology
J2EE pathfinder: Java security with JAAS and JSSE
Discuss77 KBe-mail it!
Overview of JAAS and JSSE
Authentication with JAAS
Authorization with JAAS
Secure transport with JSSE
About the author
Rate this article
Related content:
J2EE pathfinder series
Java security tutorial: Authentication and Authorization
Using JSSE for secure socket communication
IBM Developer Kits for the Java platform (downloads)
dW newsletters
dW Subscription
(CDs and downloads)
A short introduction to the J2EE Web application security architecture

Level: Introductory

Kyle Gabhart ( security with JAAS and JSSE)
Consultant, Gabhart Communications
25 November 2003

Column iconIn this installment of J2EE pathfinder, enterprise Java developer and educator Kyle Gabhart introduces the Java Authentication and Authorization Service (JAAS) and the Java Secure Socket Extension (JSSE). Follow along to find out how these two APIs combine to provide the core functions of the J2EE Web application security framework: authentication, authorization, and transport-level security. Share your thoughts on this article with the author and other readers in the accompanying discussion forum. (You can also click Discuss at the top or bottom of the article to access the forum.)

From the early days of the so-called Java sandbox to the robust, full-featured security architecture introduced with JDK 1.4, security has always been an essential component of the Java platform. In getting from there to here, the designers of the Java language have received plenty of community input on what does and does not a secure Java application (or enterprise environment) make; and they've also pulled a trick or two on their own.

Suffice it to say that with the introduction of the J2EE Web application security architecture, we're reaping the rewards of nearly 10 years of trial and error, and it shows. The J2EE security framework consists of three APIs: the Java Authentication and Authorization Service (JAAS), Java Secure Socket Extension (JSSE), and Java Cryptography (JCE). While JCE is an interesting and important API, it's not quite so central to our interests as the "big three" of secure Web application development: authentication, authorization, and transport. So in this month's column we'll focus on the JAAS and JSSE.

Overview of JAAS and JSSE
JAAS provides a flexible, declarative mechanism for authenticating users and verifying their ability to access secure resources. JSSE defines an all-Java mechanism for securing Web traffic over a Secure Socket Layer (SSL). By combining these two technologies, we can give our applications the ability to:

  • Verify that a user is who he or she claims to be (authentication)
  • Ensure that he or she is permitted access to the requested resource (authorization)
  • Conduct the entire exchange over a secure network connection (transport)

Now, let's take a look at the individual components underlying all this functionality.

Authentication with JAAS
JAAS is built on a security architecture known as PAM (Pluggable Authentication Module). PAM's architecture is modular, which means it's designed to support the seamless exchange of one security protocol component for another by swapping out modules. Well-defined interfaces within the framework allow for the inclusion of multiple authentication technologies and authentication mechanisms without changing or interfering with any of the existing login services. The PAM architecture, and thus JAAS, is able to integrate a broad range of authentication technologies, including RSA, DCE, Kerberos, and S/Key. Additionally, the framework is compatible with smartcard-based authentication systems and LDAP authentication.

As is the case with so many of the Java 2 platform technologies, the JAAS API defines a clean abstraction between application code and the physical implementation that will execute the business logic. The abstraction layer is what allows for the run-time substitution of login modules without recompiling existing application code. Specifically, applications write to the LoginContext API, while authentication technology providers write to the LoginModule interface. At run time, the LoginContext will read a configuration file to determine which login module(s) should be used to authenticate users accessing a particular application.

The authentication scheme used by JAAS is grounded in two very important entities: principals and subjects. The person or service that is actually being authenticated is referred to as the subject. A principal is a unique entity such as the name of an individual or group, an account number, a social security number, or similar unique identifier. In order to uniquely identify a subject (which is a crucial component of authentication), one or more principals must be associated with that subject. Finally, a subject may own security-related attributes, known as credentials. A credential can be anything from simple password to a complex cryptographic key.

Applications begin the authentication process by instantiating a LoginContext object. The LoginContext queries a configuration to determine the authentication technology (or technologies) and corresponding LoginModule(s) to be used in performing the authentication. A very simple LoginModule may prompt for and verify a username and password. A more advanced one might validate identity using an existing operating-system login identity. Theoretically, a JAAS LoginModule could even be built to interface with a fingerprint reader or retina scanner.

Authorization with JAAS
Authentication is only half the battle in the Java security framework. Once a user's identity has been confirmed, his or her access rights must be examined. Only after the appropriate rights have been confirmed will the user be granted access to secured systems or resources.

To put this another way, once a user or service has been authenticated, a Subject object is created to represent the authenticated entity. This object is then passed by JAAS to any authorization components that have been established to guard access to sensitive systems or resources.

To determine authorization, the Java 2 Security Manager is supplied with the Subject and its Principals, as well as the privileged action the Subject wants to perform (reading/writing to the file system, database access, and so on.). The Security Manager consults a policy file which associates Principals and permissions. If one of the Subject's Principals has permission to perform the specified action, then the Subject is authorized and the action is allowed; otherwise the action is denied and a SecurityException is thrown.

A one-two security punch
For a comprehensive, hands-on look at the Java security model, see Brad Rubin's two-part tutorial:

Part 1: Crypto basics
Part 2: Authentication and authorization

Secure transport with JSSE
Thanks to JAAS we are able to identify users who access our system and restrict their access to the parts of the system they're authorized to use. While JAAS is a solid first step toward a secure Web application, application security isn't complete without secure transport.

At this point, we're still transmitting secure information (including authentication information) in plain text -- that is, HTTP, TCP/IP, FTP, and so on. So we need to make sure that, while in transit, the data isn't accessible to unauthorized parties. We also need to be sure, on arrival, that the data hasn't been modified during transit, whether intentionally or unintentionally. For both of these functions we can leverage the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols.

SSL and TLS are not Java-specific protocols, but rather network-layer protocols designed to maintain the integrity and privacy of traffic across a socket. The Java Secure Socket Extension (JSSE) enables secure Internet communications with SSL/TLS. It provides an application framework -- a Java version of the SSL and TLS protocols -- complete with the full range of functionality including data encryption, server authentication, message integrity, and more. Using JSSE, we can define secure socket connections between a client and server running any application protocol, including HTTP, TCP/IP, FTP, or even Telnet. From a data-encryption standpoint, JSSE encompasses many of the same concepts and algorithms as those in the JCE. More importantly though, it automatically applies them as necessary beneath a simple stream socket API.

To leverage the JSSE API, we only need to do a few simple things. First, we need to obtain a JSSE provider (see Resources). Second, we need to obtain sockets from one of the JSSE socket factories, rather than directly from the class. Client-side code retrieves sockets from the SSLSocketFactory, while server-side code retrieves sockets from the SSLServerSocketFactory. By retrieving our sockets from these factories, we are able to leverage the framework provided by the JSSE provider, rather than simply creating standard, unsecured sockets as the package allows us to do.

For more details on JSSE, see Resources.

The Java platform is known for its rock-solid application security. With each passing year the Java security framework becomes more flexible and robust, and the addition of JAAS and JSSE suggests that the legacy will continue.

This month, we took a quick peek at the technologies for securing a Java Web application. JAAS provides a modular mechanism for authenticating users and controlling access to resources. JSSE delivers a Java implementation of the SSL and TLS protocols supporting data integrity and privacy. Next month, we'll explore the brave new world of servlet filters. Until then, happy pathfinding!


About the author
Photo of Kyle GabhartKyle Gabhart is an independent consultant and subject matter expert with J2EE, XML, and Web services technologies. Kyle is a popular public speaker, recognized for his enthusiasm and dynamic analysis and presentation of emerging technologies. For information on his recent and upcoming presentations or industry publications, visit Kyle can be reached at

Discuss77 KBe-mail it!

What do you think of this document?
Killer! (5) Good stuff (4) So-so; not bad (3) Needs work (2) Lame! (1)

Send us your comments or click Discuss to share your comments with others.

developerWorks > Java technology
  About IBM  |  Privacy  |  Terms of use  |  Contact