Java Authentication and Authorization Service

The Java Authentication and Authorisation Service(JAAS) is an API developed by Sun and included as standard in JDK1.4 which forms part of Sun's Java Security Architecture. JAAS is a Java implementation of PAM which offers two services - the authentication of users (called Subjects) and the authorisation of authenticated Subjects to access restricted code.

JAAS has become, with JDK1.4, the official Sun standard API for user authentication and authorisation. A key selling point of JAAS is its pluggable nature, because it conforms to the PAM architecture it means that front-ends and back-ends can be plugged in and out simply by modifying configuration. This allows developers to build flexible, extensible systems that do not have to be modified if security settings change.

JAAS Glossary

• Authentication - the action of determining the identity of a system user.
• Authorisation - the action of determining whether an authenticated Subject has been allowed access to a restricted resource.
• CallbackHandler - because JAAS is based on PAM it uses a callback handler to facilitate communication between the front-end and back-end modules for authentication.
• Credential - an authenticated user is granted credentials by the module(s) that authenticated him/her, these credentials do not form part of the core JAAS functionality, but may be used by the system to determine how the user may behave.
• LoginContext - a LoginContext holds the state around an instance of a user sign-on.
• LoginModule - Login Modules are classes that perform the actual authentication of users. These can be plugged into and out of a system at run-time.
• Subject - an instance of an authenticated user
• Policy - in JAAS the authorisation policy determines who is allowed to access what system resources.
• Principal - one identity of a Subject. For example a user might have the Principal 'James Brown' (his name) and '1234-8765-9999-0000' (his employee number)
• PrivilegedAction - an action (piece of code) which is restricted by a JAAS authorisation policy

User Authentication
The first purpose for which JAAS can be used is authentication - the ability to securely determine who the user is that is trying to access an application, applet, bean or servlet. To do this the JAAS provides a front-end into existing sign-on technologies such as Kerberos and LDAP and also allows the developer to plug custom authentication modules (called LoginModules) into the authentication process.

The JAAS also allows for the chaining of authentication modules, i.e. the system administrator can, for a particular login type, specify one or more login modules which have to authenitcate the user in turn before the user is given access to the system. Along with authentication chaining, JAAS offers conditional authentication where one authentication module may indicate that it will allow the user access to the system only if another authentication module agrees.

Communication between the front-end data collecting classes and back-end authentication modules is facilitated by means of a set of callbacks. This is done to conform to the PAM architecture.

The result of an authentication of a user is a Subject representing the user which contains one or more Principals.

The JAAS comes with several pre-built authentication modules which may be plugged into an application, these include:

• Java Naming and Directory Interface (JNDI)
• Unix Operating Environment
• Windows NT
• Kerberos
• Keystore

Third party pre-built authentication modules are also available for (amongst others) LDAP and and Lotus Domino.

User Authorisation

The JAAS authorisation architecture extends the Java Security architecture which restricts the privileges of code depending on where the code originates from. JAAS extends this by also restricting the privileges of code depending on who is running it.

The restrictions placed on code and users is determined by a JAAS policy file which describes restricted functional areas and the Principals that may access them. These restricted functional areas may be restrictions on reading and writing files, restrictions on accessing network resources, restrictions on accessing system properties and restrictions on accessing individual classes.

When an authenticated user want to perform a Privileged Action the JAAS architecture checks the restrictions placed on that user's Principals before executing it. This allows for very fine-grained control of users' actions within a system and allows system administrators to determine what resources each user is allowed to access.

Comments on JAAS
JAAS is undeniably flexible and extensible, but it does seem a little fudged together in places. The architecture is comprehensive in its view of determining the validity of a user and the privileges assigned to that user, but the way that these elements come together could have been more elegant.

On the upside the out-of-the-box support for JNDI, Kerberos, LDAP and the like is fantastic and JAAS makes the dream of having a single sign-on quite easy to do. The level of granularity that the authorisation scheme allows is also very useful (if intensive to maintain) and the fact that it does not have to be done programatically by the application can lead to cleaner, more easily maintainable system innards while retaining robust security.

Plums:

• an extensible, standardised interface into a myriad of sign-on technologies
• transparent authenitcation chaining
• run-time authentication and authorisation configuration
• class level

Gripes:

• The fact that Credentials do not natively form part of the authorisation process means that the authorisation functionality is essentially duplicated because the application can either use credentials or priviledged actions for authorisation.
• The use of the PAM callback scheme is not clean and could have been implemented much more elegantly using a modern OO architecture.