Welcome!

Java IoT Authors: Yeshim Deniz, Pat Romanski, Liz McMillan, Elizabeth White, Zakia Bouachraoui

Related Topics: Java IoT

Java IoT: Article

JAAS in the Enterprise

An integration proposal

Since 2001 when Java Authentication and Authorization Service (JAAS) was formally included in the Java 2 Platform Enterprise Edition (J2EE) 1.3 platform specification, the J2EE community has been grappling with the issue of JAAS/J2EE integration. On the surface, JAAS seems to be an excellent complement to J2EE: JAAS defines a pluggable Application Programming Interface (API) for authentication modules and a fine-grained Subject-based authorization model, which are both lacking in the existing J2EE security model. Since JAAS is officially part of the J2EE platform specification, it's not unreasonable to expect that you can now leverage the JAAS framework to build portable enterprise applications that have advanced authentication and authorization requirements. Unfortunately, any Java architects or developers who go down this path for their applications will soon be confronted with the harsh reality: Instead of finding a landscape defined by an unified integration architecture, they'll discover a landscape littered with incompatible vendor-specific APIs and frameworks.

If JAAS and J2EE seem to fit well together, why is there such a fragmented landscape? What has contributed to this fragmentation, and more importantly, what lies ahead? In this article we'll explore the main security issues that architects and developers must consider when designing J2EE-based solutions for enterprise deployments. We'll also highlight some of the ongoing standards-based efforts that will make it easier to include advanced authentication and authorization capabilities in your enterprise applications. Finally, we'll offer some pragmatic strategies you can consider today, while waiting for the standards to catch up.

JAAS and J2SE
JAAS is designed to bring Subject-based authentication and authorization to the Java 2 platform. On the authentication side, JAAS is modeled after the Pluggable Authentication Module (PAM)-a popular API for defining authentication modules in a portable and extensible manner. On the authorization side, JAAS inherits the rich, fine-grained, and extensible security model defined in Java 2. When JAAS was first introduced as an optional package for JDK 1.3, there was, understandably, quite a bit of excitement: "Finally, a real security standard for the Java platform!" (Not that code-based security isn't important, but a lot of us were waiting for a user-based authentication and authorization model.)

Indeed, JAAS 1.0 did achieve a few significant wins for Java developers. It offered a standard way to develop authentication modules (via JAAS LoginModules - see Figure 1) and a flexible way for the authentication modules to gather information dynamically from the application (via CallbackHandler - see Figure 2). It also offered a way to integrate Subject-based authorization into the Java 2 platform without affecting the code-based security model.

Of course, being hard-nosed, pragmatic people, we were also realistic - or so we thought - in our expectations: "It's only Version 1.0 of this API, and it's released as an optional extension, to boot. It'll probably be a few years before it goes mainstream."

Not surprisingly, when JAAS 1.0 was introduced, there were a few issues. As an optional extension, the JAAS jar files weren't generally available as part of the regular JDK distribution. In addition, its add-on nature was reflected in the API design - instead of having one policy that dealt with both Subject- and code-based policies, we had to deal with two separate policies (each with its own API) and some obscure DomainCombiner logic that updates the protection domains based on these policies at runtime.

Fortunately for Java developers everywhere, these issues largely went away when JAAS was fully integrated into the core Java security architecture in JDK 1.4: JAAS was distributed as part of the regular JDK distribution, and the Java 2 security model is now the JAAS security model - one security model, one policy API. (Please refer to Java 2 Security Architecture ( http://java.sun.com/j2se/1.4.2/docs/guide/security/spec/security-spec.doc.html) for more details about JAAS/J2SE security model.)

JAAS and J2EE
Most Java developers would agree that if there were a Java development platform that could really benefit from a user-based authentication and authorization standard, it would be the J2EE platform, where security is paramount and user-based security, in particular, is essential to any enterprise-ready applications. Thus J2EE, unlike J2SE (Java 2 Platform Standard Edition), came with a rather sophisticated user-based security model since J2EE 1.0. With the introduction and subsequent integration of JAAS into the J2SE platform, the main question has now become: "How do we integrate JAAS into J2EE?" (This is a question Graham Hamilton posed to the Java security experts at a one-day Java security summit held in Boston shortly after JAAS 1.0 was introduced.)

On the surface, it appears that JAAS and J2EE complement each other very well. Although J2EE defines a declarative way to configure the authentication method to be used with a Web/EJB module, it doesn't define a pluggable authentication module API; JAAS (with its LoginModule API) nicely fills this void. And although J2EE authorization serves quite well the security needs of typical (security-unaware) Web-based and EJB-based applications, it's also a rather coarse-grained and inflexible model (the only privileges supported are URL-based and EJB method-based). The JAAS/Java2 permission-based model is extensible and can model arbitrarily complex and fine-grained authorization policies.

Given these considerations, it wasn't surprising that shortly after its introduction, JAAS 1.0 was included as part of the J2EE 1.3 platform specification. Unfortunately - perhaps due to time and resource constraints - there were no provisions in the J2EE 1.3 specification regarding how JAAS 1.0 was to be integrated into J2EE-compliant containers. In other words, it'd be up to each container vendor to figure out the right integration strategy. Inevitably, because different vendors decided to do this in different enough ways, the fact that JAAS 1.0 was officially part of J2EE 1.3 isn't very meaningful to Java developers - at least to those who care about developing portable J2EE applications.

  • Consider authentication: While it's possible to write a JAAS-based login module that works properly in a J2EE 1.3/1.4-compliant container, it'd be difficult - in fact, almost impossible - to write one JAAS login module that works equally well in all J2EE 1.3/1.4 containers.
  • Consider authorization: While it would be possible for a J2EE application to use the JAAS policy API and Java 2 permission model to handle fine-grained authorization policies, it'd be impossible for such an application to retrieve the JAAS Subject (representing the currently authenticated user) in a portable manner.
JAAS/J2EE Integrated: Secure Enterprise Applications
Before we get into too much detail, let's step back and ask ourselves: "What would a truly JAAS/J2EE integrated architecture look like?" Put it this way. If you were the project manager responsible for this integration project, what would be on your project's wish list?

First, let's consider authentication: JAAS has defined a portable, extensible API for authentication modules that lets you reuse a well-behaved LoginModule implementation in different contexts. What does this mean in a J2EE context? We believe a reasonable goal for a JAAS/J2EE integration architecture would be to let any JAAS-compliant login module be plugged into any J2EE-compliant container - without any modifications. In other words, you should be able to develop or buy/download an RDBMSLoginModule to use with your applications and expect it to work well in all J2EE-compliant application servers that might end up hosting your applications. Given certain reasonable constraints (for example, the RDBMSLoginModule shouldn't use any protocol-specific Callbacks), it should also work equally well for most of the managed resources (such as servlet/JSP, EJB, or MBeans) over a variety of connection protocols (such as HTTP, RMI/IIOP, or JMX/RMI).

Now, let's consider authorization. We believe a properly designed integration architecture should cover the following: First, the J2EE authorization model should work properly in a JAAS/J2EE context. In other words, using a JAAS LoginModule to handle authentication for your application doesn't mean you want to get rid of the nice declarative security constraints you've worked hard to exactly fit your application. Also, the managed component (such as Servlet/JPS, EJB, or MBeans) should be invoked in an execution context where the currently authenticated user (represented by a JAAS Subject instance) is readily available (via JAAS API) to the component. (In standard JAAS, this typically means the managed component is invoked within a Subject.doAs[Privileged] block.) Finally, the legacy J2EE authorization API (such as isCallerInRole/getCallerPrincipal) should work properly in a JAAS/J2EE context; this means that if your application is security-aware and uses isCallerInRole to do advanced role-based processing, your application should continue to work in a JAAS/J2EE-integrated environment.

So far, we've only outlined the basic requirements; these ensure that JAAS and J2EE play well with each other, and that the legacy applications or modules developed with either context in mind continue to work well in an integrated environment. A JAAS/J2EE integration framework that implements these requirements in a reasonable manner might be considered a solid investment, but probably not something worth jumping up and down about.

Yet these basic requirements do bring about a level of power and sophistication not seen before in J2EE security. For instance, by leveraging the integrated JAAS/J2EE architecture, you can finally build advanced enterprise applications that authenticate via a custom (application-specific) user repository (via standard JAAS LoginModules); leverage a coarse-grained J2EE authorization model for pre-dispatch authorization decisions; and leverage a customized, fine-grained JAAS permission model to protect application-specific resources. And you achieve all of these without sacrificing portability.

This is nothing to be sneezed at - and if you're like us, you're probably salivating at the possibilities this combination has opened up for your application architecture...

Not so fast. Yup - there's a catch.

The Current Landscape
Equipped with this modest list of requirements, we're ready to evaluate the current landscape. As an industry, how do we fare in this context? In a nutshell, not very good. In fact, if we use this basic requirement list as a scorecard, most vendors wouldn't do well at all.

More Stories By Raymond K. Ng

Raymond K. Ng has been a professional software developer for 15 years and has been involved in high-scale enterprise Java development since JDK 1.0. He currently serves as architect and development lead of Oracle Platform Security Services (OPSS) and serves on the JCP Expert Groups for JSR 115 (JACC) and JSR 196. Raymond is a Consulting Member of the Technical Staff at Oracle Corporation and is the holder of multiple patents.

More Stories By Ganesh Kirti

Ganesh Kirti is a Senior Software Development Manager at Oracle with 11 years of industry experience. He currently leads development of Java Platform Security in the Oracle Fusion Middlewrae group at Oracle. Ganesh has a wide range of engineering experience including developing Identity Management and SOA Security products.

Comments (1)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


IoT & Smart Cities Stories
Dion Hinchcliffe is an internationally recognized digital expert, bestselling book author, frequent keynote speaker, analyst, futurist, and transformation expert based in Washington, DC. He is currently Chief Strategy Officer at the industry-leading digital strategy and online community solutions firm, 7Summits.
Digital Transformation is much more than a buzzword. The radical shift to digital mechanisms for almost every process is evident across all industries and verticals. This is often especially true in financial services, where the legacy environment is many times unable to keep up with the rapidly shifting demands of the consumer. The constant pressure to provide complete, omnichannel delivery of customer-facing solutions to meet both regulatory and customer demands is putting enormous pressure on...
IoT is rapidly becoming mainstream as more and more investments are made into the platforms and technology. As this movement continues to expand and gain momentum it creates a massive wall of noise that can be difficult to sift through. Unfortunately, this inevitably makes IoT less approachable for people to get started with and can hamper efforts to integrate this key technology into your own portfolio. There are so many connected products already in place today with many hundreds more on the h...
The standardization of container runtimes and images has sparked the creation of an almost overwhelming number of new open source projects that build on and otherwise work with these specifications. Of course, there's Kubernetes, which orchestrates and manages collections of containers. It was one of the first and best-known examples of projects that make containers truly useful for production use. However, more recently, the container ecosystem has truly exploded. A service mesh like Istio addr...
Digital Transformation: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As automation and artificial intelligence (AI) power solution development and delivery, many businesses need to build backend cloud capabilities. Well-poised organizations, marketing smart devices with AI and BlockChain capabilities prepare to refine compliance and regulatory capabilities in 2018. Volumes of health, financial, technical and privacy data, along with tightening compliance requirements by...
Charles Araujo is an industry analyst, internationally recognized authority on the Digital Enterprise and author of The Quantum Age of IT: Why Everything You Know About IT is About to Change. As Principal Analyst with Intellyx, he writes, speaks and advises organizations on how to navigate through this time of disruption. He is also the founder of The Institute for Digital Transformation and a sought after keynote speaker. He has been a regular contributor to both InformationWeek and CIO Insight...
Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
To Really Work for Enterprises, MultiCloud Adoption Requires Far Better and Inclusive Cloud Monitoring and Cost Management … But How? Overwhelmingly, even as enterprises have adopted cloud computing and are expanding to multi-cloud computing, IT leaders remain concerned about how to monitor, manage and control costs across hybrid and multi-cloud deployments. It’s clear that traditional IT monitoring and management approaches, designed after all for on-premises data centers, are falling short in ...
In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...