Welcome!

Java IoT Authors: Yeshim Deniz, Zakia Bouachraoui, Liz McMillan, Elizabeth White, William Schmarzo

Related Topics: Java IoT, Recurring Revenue

Java IoT: Article

Whatever Happened to JAAS?

JAAS has come a long way since it was an option for JDK 1.3.1

Introduced in 1995, Java has firmly established itself as a mature mainstream programming language for enterprises. The Java platform security model has evolved over the years to meet new requirements, and today enterprise Java developers have a large number of APIs and services to choose from to fulfill their security needs.

Originally touted as a secure runtime environment for downloadable executables (applets), Java platform security received a lot of attention early on and the rather inflexible security model was quickly identified as a weakness in the system. With the Java 2 Platform, Enterprise Edition (J2EE), Sun revamped the Java platform security model and introduced a fine-grained, flexible, and extensible security model for code-based security. This new model has largely been a success but it was restricted to code-based security. This makes sense for browser-based deployment environments but is not as relevant for server-side deployments. To address this gap, Java Authentication and Authorization Service (JAAS) was introduced as an optional package for Java Development Kit (JDK) 1.3.1, and subsequently integrated into JDK 1.4.

Sun officially announced Java Platform, Enterprise Edition (Java EE) 1.0 in 2000. Just as Java became the mainstream programming language of choice, Java EE has been widely adopted as the primary application platform for enterprises. But the security needs of enterprise applications are quite different from those of downloadable executable code, so Java EE defined its own security model that is declarative, consistent, and portable across Java EE implementations.

JAAS was included officially as part of the Java EE 1.3 specification. Unfortunately, Java EE 1.3 did not attempt to resolve the differences between the Java EE security model and JAAS, which made it more difficult to deploy off-the-shelf JAAS login modules in some vendors' implementations.

State of Java EE Security
In this section, we'll provide a brief overview of the main players in the Java EE security landscape.

Java EE Declarative Security
Java EE defines a declarative and portable security model that applies to both Web and Enterprise JavaBeans (EJB) modules and applications. The main goal of the declarative security model is to decouple security concerns from business application logic, so enterprise application developers can focus on the main business functions and services provided by the applications without worrying about
security.

The Java EE declarative security model applies to the servlet container and the EJB container. The servlet container security model is based on URL patterns, whereas the EJB security model is method-based.

For security-aware applications, Java EE also defines a programmatic API to handle more advanced security needs.

JAAS
Introduced as an option for JDK 1.3.1 and incorporated into J2EE 1.4, today JAAS has been quite widely adopted by commercial and open source vendors as the primary pluggable authentication framework for SE and EE applications alike.

JAAS defines a framework for subject-based authentication and authorization in a pluggable manner, decoupling applications from underlying security implementations.

Key components of JAAS include:

  • The definition of subject (javax.security.auth.Subject)
  • An authentication API (javax.security.auth.login.LoginContext) that supports pluggable and stacked authentications
  • An authentication SPI (javax.security.auth.spi.LoginModule) for pluggable authentication mechanisms
  • A configuration contract for configuring and associating login modules with applications
  • A typesafe callback contract (javax.security.auth.callback) for services to communicate with applications
  • The definition of SubjectDomainCombiner (javax.security.auth.SubjectDomainCombiner) for dynamically updating the protection domains with the principals from the subject, for integration with the J2EE security model

Figure 1 illustrates the JAAS authentication architecture.

The JAAS authentication framework has been stable since JAAS 1.0 - there were some very minor changes (the introduction of a LoginContext constructor that takes a configuration as an argument for dynamic configuration of login modules, for example), but in general applications written on top of JAAS 1.0 (JDK 1.3.1) continue to work without modification today (JDK 6.0). Perhaps more remarkable, login modules written to the JAAS 1.0 SPI can be plugged into today's applications, which reflects well on the overall design of the API.

Figure 2 illustrates the typical authentication call sequence.

Note that the application developer is largely decoupled from underlying login module implementations - especially if the login module implementation only uses the standard callbacks.

When integrating JAAS authentication with Java EE implementations, however, a number of thorny issues arise.

  • Although JAAS uses subject to represent a user, Java EE uses principal. A subject can - and usually does - contain multiple (custom) principal instances, so there must be a mechanism whereby a container can determine the principal instance representing the caller or user.
  • The standard JAAS callbacks are useful and valuable for Java Platform, Standard Edition applications, but they do not cover typical enterprise deployment scenarios. For instance, there is no standard definition of HttpServletRequestCallback or HttpServletResponseCallback, so if a login module provider needs to access the HttpServletRequest object (say to retrieve a HTTP header value), the
    login module provider must resort to a vendor-specific API, compromising portability.

Java Specification Request 196
When this was written, Java Specification Request (JSR) 196 was slated to be included as part of Java EE 6.0.

Figure 3 depicts the JSR 196 generic message processing model and the four interaction points.

This generic model applies to any message-processing runtime that integrates with JSR 196. The reader is encouraged to peruse JSR 196 for more details.

As part of JSR 196, a servlet container profile is defined, clarifying how servlet container implementations can integrate with this contract. When this was written, this profile is under consideration as a Java EE 6.0 requirement.

JSR 196 defines a standard SPI for authentication providers. Therefore, the interfaces introduced by JSR 196 are primarily used by Java EE container vendors. Consequently, Java EE application developers are not directly affected by a container vendor's uptake of this SPI.

On the other hand, JSR 196 directly addresses a few long-standing problems in the JAAS/Java EE landscape, namely determining a standard way to obtain user principals and group principals.

JAAS, being a flexible, pluggable standard, allows any login module to define its own custom principal type(s) and populate the custom principal instance(s) into the subject. But because the custom principal type(s) are not known to the container, the container can only determine which principal represents the caller's identity by introducing CallerPrincipalCallback. JSR 196 addresses this issue. The ServerAuthModules can indicate to the container which principal instance represents the caller, and you can ensure that getUserPrincipal and getRemoteUser return the correct and expected value instead of leaving it to the mercy of the vendor's implementation details.

The need to obtain group principals is an equally fundamental issue. This is addressed by introduction of GroupPrincipalCallback in JSR 196.

Conclusion
JAAS has come a long way since it was an option for JDK 1.3.1. With the introduction of JSR 196 in Java EE 6.0, many of the thorny issues that exist today will finally be addressed. JAAS has certainly evolved, and it looks to be well positioned to have a place in the enterprise marketplace for years to come.

•   •   •

SOAP Box: The Talented Callback Handler
One of the most versatile components introduced by JAAS is the typesafe callback contract (javax.security.auth.callback). We assume the reader is already familiar with the commonly used NameCallback and PasswordCallback through which the security services (login modules) obtain user name and password information. However, the callback contract is actually a generic two-way communication model that can be applied in many circumstances, both security-related and not.

For instance, JSR 196 takes advantage of the callback contract by defining a CallerPrincipalCallback whereby a security service (such as ServerAuthModule) can communicate with the container (or application) that the principal instance represents, solving a long-standing issue. JSR 115 defines a similar callback contract (javax.security.jacc.PolicyContextHandler) that enables the container to communicate additional contextual information to the policy provider to support advanced security policies such as the instance-based security model. In fact, with the callback model, notions such as XACML-styled obligations can be supported as well, without affecting existing APIs.

Finally, JSR 196 creates a bridge to JAAS login modules, helping to preserve existing investments in JAAS. It also properly decouples JAAS login modules from any protocol-specific processing. In the past, attempts to create a JAAS login module to integrate with a single sign-on solution failed because there was no portable way to access the HttpRequest/Response objects. JSR196 solves that issue - not by making HttpRequest/Response objects available to JAAS login modules, but by cleanly separating the component that deals with protocol-specific processing from the component that deals with credential validation (the JAAS login module). We believe this is the right approach.

When this was written, Glassfish was the only major Java EE provider that supports JSR 196, but the servlet container profile was slated to be part of Java EE 6.0, so you can expect major Java EE vendors to support this contract as well.

•   •   •

SOAP Box: Why JSR 196?
The benefits of JSR 196 include:

  • It is sufficiently rich to enable implementations of complex authentication protocols
  • It is portable across component containers and servers
    -WORA capabilities for server-side authentication modules
    -Application-level binding supports application-level authentication configurations and mechanisms
    -Security-aware enterprise applications can remain portable
  • It properly delegates security processing to ServerAuthModules, which are registered/configured at the container level and can be associated with applications
  • It supports and preserves the existing declarative Java EE security model, auth-constraint processing, and the like
  • It defines a servlet container profile and a SOAP profile (with Java Message Service, Internet Inter-ORB Protocol, and the like) to be defined in the future

By supporting JSR196, Java EE vendors benefit by leveraging the available ServerAuthModule implementations for competitive advantages.

How about Servlet Filters? Servlet filter is a very useful mechanism, but servlet filters must be configured as part of the application (via web.xml) and are considered part of the application. In fact, by the time a servlet filter is invoked, the authentication has already happened and auth-constraints have already been processed. That does not mean we cannot use servlet filters for security needs, but there are some undesirable tradeoffs with this approach.

How about Spring Security? Spring is perhaps the most important de facto application framework in use today, and Spring security (formerly ACEGI security) is the main security framework provided by Spring. It takes advantage of Spring-styled configuration, aspect-oriented programming, and inversion of control technologies. Not surprisingly, Spring security uses a filter-based approach. Users must configure a series of filters as part of the application, and then Spring security effectively replaces Java EE container security. To compensate, Spring security provides its own security model based on URL patterns, and provides features typically found in servlet container implementations. The features offered by Spring security are indeed valuable and should not be underestimated - and aside from servlet filters, there are few other options available today. However, there are inevitably tradeoffs involved when this method is employed, and users should be aware of them. In fact, when JSR 196 becomes readily available, we expect some of the features implemented via servlet filters be folded into ServerAuthModule implementations.

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.

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
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...
Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: Driving Business Strategies with Data Science," is responsible for setting the strategy and defining the Big Data service offerings and capabilities for EMC Global Services Big Data Practice. As the CTO for the Big Data Practice, he is responsible for working with organizations to help them identify where and how to start their big data journeys. He's written several white papers, is an avid blogge...
Nicolas Fierro is CEO of MIMIR Blockchain Solutions. He is a programmer, technologist, and operations dev who has worked with Ethereum and blockchain since 2014. His knowledge in blockchain dates to when he performed dev ops services to the Ethereum Foundation as one the privileged few developers to work with the original core team in Switzerland.
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
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...
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...
Whenever a new technology hits the high points of hype, everyone starts talking about it like it will solve all their business problems. Blockchain is one of those technologies. According to Gartner's latest report on the hype cycle of emerging technologies, blockchain has just passed the peak of their hype cycle curve. If you read the news articles about it, one would think it has taken over the technology world. No disruptive technology is without its challenges and potential impediments t...
If a machine can invent, does this mean the end of the patent system as we know it? The patent system, both in the US and Europe, allows companies to protect their inventions and helps foster innovation. However, Artificial Intelligence (AI) could be set to disrupt the patent system as we know it. This talk will examine how AI may change the patent landscape in the years to come. Furthermore, ways in which companies can best protect their AI related inventions will be examined from both a US and...
Bill Schmarzo, Tech Chair of "Big Data | Analytics" of upcoming CloudEXPO | DXWorldEXPO New York (November 12-13, 2018, New York City) today announced the outline and schedule of the track. "The track has been designed in experience/degree order," said Schmarzo. "So, that folks who attend the entire track can leave the conference with some of the skills necessary to get their work done when they get back to their offices. It actually ties back to some work that I'm doing at the University of San...
When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...