J2SE 1.5, includes a lot of enhancements to cryptography, XML
security, Public Key Infrastructure (PKI), Kerberos, ...

User authentication and access control are important security
measures for most Java applications, especially J2EE applications.
The Java Authentication and Authorization Service (JAAS), the core
API of J2SE 1.4 and 1.5, represents the new security standard. It
provides a pluggable and flexible framework that allows developers
to incorporate different security mechanisms and various security
sources.

With the upcoming release of J2SE 1.5, which includes a lot of
enhancements to cryptography, XML security, Public Key
Infrastructure (PKI), Kerberos, and the federating identity, the
JAAS will play a more important role in J2EE security
implementations.

Overview of JAAS Authentication:
Authentication is the process of verifying that a user has the right
to use identities established by the enterprise user registry. The
authentication mechanism of JAAS is built on a set of pluggable
modules (see Figure 1). JAAS allows different authentication models
to be plugged in at runtime. The client applications always interact
with JAAS through the LoginContext object.


_________________
| LoginContext |
|_________________|
|
_________________
| LoginModule |
|_________________|
| ____________________
| | NameCallback |
| |____________________|
_________________ / ____________________
| CallbackHandler |_| PasswordCallback |
|_________________| |____________________|
\ ____________________
| TextOutputCallback |
|____________________|

Figure 1 Modules of authentication in JAAS

The authentication process typically involves the following steps:
1. Create a LoginContext object. The LoginContext looks up the
configuration file to determine which LoginModule to use. Also,
optionally, you can pass a CallbackHandler to the LoginContext.
2. Perform authentication by calling the login method of
LoginContext, which loads the predefined LoginModule to check if the
user can be authenticated.
3. Associate principals and credentials with the Subject if the
user is authenticated.
4. Or throw a LoginException in case login failed.
5. Use the logout method of LoginContext to log out.

The login in JAAS is a two-phase process. The first phase is
the "login" phase (as described in step 2). The only task in this
phase is authentication. Once the process successfully passes this
phase, the authentication process enters the "commit" phase (step 3)
in which the commit method of LoginModule is called to associate the
relevant principals and credentials with the Subject.

A Subject in JAAS represents an authenticated entity, such as a
person or device. It contains a set of principals and security-
related attributes such as a password and cryptographic keys. In the
JAAS architecture, the Subject, along with the Permission, plays an
important role in the authorization process.

Of all the authentication modules, the LoginModule is the interface
to a particular authentication mechanism. Although the LoginModule
never gets called directly by the client application, it provides a
particular type of authentication via a pluggable module, which
implements the authentication algorithm and determines how the
actual authentication is performed. Sun provides a few default
LoginModule implementations, such as JndiLoginModule,
Krb2LoginModule, UnixLoginModule, and NTLoginModule under the
package of sun.com.security.auth.module. Since the JAAS login
architecture is extensible, you can pretty much "plug in" any
LoginModule just by specifying which LoginModule to use in the
configuration file. An example of a configuration file looks like
this:

MySample {
com.sample.module.MyLoginModule required debug=true;
};


Here MySample is the name of the login context, which is passed into
the LoginContext constructor when you create a new LoginContext to
start the authentication process, followed by the configuration
block. The block informs JAAS about the loginModule that should be
used to perform authentication during the login. In addition to the
LoginModule, any options to that LoginModule can also be specified
here.

During the login step, the CallbackHandler is used by LoginModule to
communicate with the user to obtain authentication information. The
CallbackHandler handles three types of Callbacks: NameCallback,
which prompts the user for a user name; PasswordCallback, which
prompts for a password; and TextOutputCallback, which reports any
error, warning, or other messages sent to the user.

Authorization
Authorization is the process of determining whether an authenticated
user is permitted to perform some actions, such as accessing a
resource. The process is policy-based since JAAS is built on the
existing Java security model. The policy configuration file
essentially contains a list of entries, such as "keystore"
and/or "grant". The grant entry includes all the permissions granted
for the authenticated codes or principals to do the security-
sensitive operations, for instance, accessing a particular Web page
or local file. JAAS supports principal-based policy entry.
Permissions can be granted in the policy to specific principals.

The basic format of a grant entry looks like this:

grant Codebase "codebase_URL" Signedby "signer_name,"
Principal principal_class_name "principal_name",
Principal principal_class_name "principal_name",
S {
permission permission_class_name "target_name", "action",
permission permission_class_name "target_name", "action",
S
}

The "action" may be required or can be omitted depending on the
permission type.
In the JAAS architecture, the Policy object represents the system
security policy for a Java application environment and there's only
one Policy object in effect at any time according to the Java 2 SDK
document. The default implementation of Policy is
sun.security.provider.PolicyFile, in which the policies are
specified within one or more policy configuration files.

Once the user is authenticated, the authorization takes place via
the Subject.doAs method, or the static doAsPrivileged method from
Subject class. The doAs method dynamically associates the subject
with the current AccessControlContext and then invokes the run
method to execute the action, which causes the security checks. The
permission check process goes through the following steps
illustrated in Figure 2:

______________________
| Subject |
|______________________|
|
______________________ _______________
| Permission | | Policy file |
|______________________| |_______________|
| |
______________________ ________________________
| SecurityManager | | LoginContext |
|______________________| |________________________|
| |
______________________ ________________________
| AccessController | | PermissionCollection |
|______________________| |________________________|
| |
______________________ ________________________
| AccessControlContext |____| ProtectedDomain |
|______________________| |________________________|

Figure 1 Modules of authentication in JAAS

1. Invoke Subject.doAs (or doAsPrivileged).
2. Call SecurityManager.checkPermission or other check methods to
check the permission.
3. The SecurityManager delegates the check to the AccessController.
4. The AccessController ensures the relevant AccessControlContext
contains sufficient permissions for the action to be taken.
5. The SecurityManager updates the current AccessControlContext
with the permissions granted to the subject via the Policy from the
policy file.

If the required permission to a specific principal is granted, the
operation will be allowed. Otherwise, an AccessControlException will
be thrown.

Like the LoginModule, the Policy is also a pluggable module. You can
hook up other Policy implementations by
changing "policy.provider=sun.security.provider.PolicyFile" in the
java.security properties file to a value of the Policy class you
want to use.

JAAS is built on top of the existing Java security model, which is
CodeSource-based, and the plaintext format policy file
implementation. This may not be enough for the enterprise
application. You may want to use custom security repositories with
JAAS, such as LDAP (lightweight directory access protocol),
database, or another file system. It can be done by writing your own
customized modules, thanks to the JAAS pluggable feature. However,
this would require a good understanding of the modules and processes
involved in JAAS, and you need to do a lot of coding to override the
proper classes and take care of both the configure and policy files.

The Resource: Java Developer Journal & Professional Java Enterprise
Security book by Wrox pub.