JAAS (Java Authentication and Authorization Service) is a higher-level framework whose main purpose is to factor out authentication and authorization concerns from the rest of the application.  It provides an abstraction of the authentication and authorization process and exposes two concepts, the Subject and the Subject’s Principals, to the application. How the incoming request is authenticated and authorized is determined by what Pluggable Authentication Modules (PAM) JAAS has been configured to use.

As a quick aside – authentication is the process of verifying who the Subject says they are.  This is accomplished via a set of Credentials.  Authorization is the process of determining if an authenticated Subject has the right to access a given resource.

JAAS is a framework which seeks to abstract away the details of authenticating and authorizing entities which are calling your code.  The application simply configures the framework to use the desired authentication and authorization modules and asks the framework to authenticate and authorize users.  The framework behaves as desired and presents the user (the application) with a Subject as an abstraction of an authenticated user with enough information to perform programmatic authorization if needed.

For a given application, JAAS gets involved when the LoginContext.login method is called.  JAAS will create an empty Subject and pass this, along with the supplied Credentials, to all configured Login Modules (going to various LDAP servers, for instance) as part of the authentication process.  Along the way the Subject will have various Principals (representing LDAP groups, for instance) ready to be attached to it.  The overall success or failure of the login process is reported back to JAAS.  If successfully authenticated, the various Login Modules will commit their addition of Principals and/or credentials to the Subject and that Subject object will be available to the application through the LoginContext.

Configuring JAAS can be somewhat tricky.  For any given module, you specify (among other things) the Class that implements it and a flag which tells JAAS what to do with the results of the authentication operation.  The flag can be required, requisite, sufficient or optional.  Required means “if this fails, the user cannot be authenticated, but go ahead and run more modules”.  Requisite means “if this fails, the user cannot be authenticated and you can stop right here.”  Sufficient means “if this succeeds, then the user is authenticated and you can stop right here”.  Optional means “no matter what happens, keep going.”  Configurations with several modules with different values for this flag can be somewhat difficult to deal with.

JAAS is a fairly well known and broadly used framework, so the most likely place for vulnerabilities is in the configuration.  Due to the flexibility of the framework and the borderline, nondeterministic nature of how its flags and the sequence of declared modules affect the outcome, it is possible to configure JAAS to behave in a way that is unsecure without realizing it.  Also, the framework can be configured to use unsecure cryptographic primitives which would result in an unsecure application.

There is another framework, sort of a JAAS v2, called Shiro (also an Apache project).  This project adds cryptographic capabilities into the security framework and allows run-time  application permissions changes.

By Lee Harkness, Software Architect

Expertise you need. Results you deserve.