|
Page 1 of 3
arly on, Java security focused on resisting executable content threats -- security risks caused by malicious or poorly programmed code. In this series's previous articles, we saw how Java security evolved to provide security based on the code's origination and who had signed it. Java security has since evolved further.
Java security evolution and concepts: Read the whole series!
In this article, the fourth and last in the series, I will cover Java's optional security packages, which focus on resisting distributed system threats. I will show how to use a strong encryption framework, even outside the US thanks to recent favorable changes in
US export control laws. I'll also discuss Pluggable Authentication Modules (PAM) for custom authentication, as well as communicating with confidentiality and integrity using the Secure Socket Layer (SSL).
Further, we'll see simple code samples and follow through with the example we looked at in Part 3. We will enhance that example to also read from an SSL socket, not necessarily from the same system to which it made an HTTP connection.
The optional packages we will discuss comprise:
- Java Authentication and Authorization Service (JAAS): A framework for user-based authentication
- Java Cryptography Extension (JCE): A framework for using strong ciphers on a global basis
- Java Secure Socket Extension (JSSE): An extension for SSL and Transport Layer Security (TLS) support
See "Sidebar 1: Install the Optional Java Security Packages" for general guidelines to install JAAS, JCE, and JSSE. This security series does not intend to provide a comprehensive guide to computer security. Computer security is a multifaceted issue touching several disciplines, departments, and cultures. Investments in technologies should be followed up with investments in personnel training, strict policy enforcement, and periodic review of the overall security policy.
So, let's get to it.
Note: This article features a running Java applet designed to demonstrate applet security issues. Read below for more details.
Java Authentication and Authorization Service (JAAS)
In the earlier articles we examined Java security as focused on the CodeSource property, which is a combination of where the code originated (URL) and who signed it (certificates). This CodeSource-based access control lacks the ability to enforce access based on who is running the code. JAAS supplements the Java 2 security architecture by providing a framework to do so, as illustrated in Figure 1.
We will examine JAAS's common classes, as well as classes from its two main components: authentication and authorization.
JAAS authentication
JAAS authentication is performed in a pluggable fashion -- illustrated in Figure 2 -- permitting Java applications to remain independent from underlying authentication technologies. Applications enable the authentication process by instantiating a LoginContext object, which in turn references a Configuration to determine the authentication technology, or LoginModule, to perform the authentication. Typical LoginModules may prompt for and verify a username and password. More sophisticated authentication schemes may read and verify a voice or a fingerprint, for example. Later we will examine how multiple authentication schemes can also provide for stack-based authentication.
|
Figure 2. JAAS: Pluggable authentication. (Source: Sun Microsystems)
|
Modules can be configured via configuration files. A sample entry might look like:
Login1 {
sample.SampleLoginModule required debug=true;
};
In this case, only one module performs the authentication. An attempt by Login1 to authenticate a Subject will succeed if and only if the SampleLoginModule succeeds.
In the code above, required represents a LoginModuleControlFlag. Let's look at required and its fellow LoginModuleControlFlags in more detail:
- required: In this case, the login module must succeed. Regardless of whether it succeeds or fails, however, authentication still proceeds down the login module list.
- requisite: The login module must succeed. If login succeeds, authentication continues down. However, if it fails, control returns immediately to the application.
- sufficient: The module doesn't have to succeed. If it does succeed, control immediately returns to the application.
- optional: This login module doesn't have to succeed. Whether it succeeds or fails, authentication still proceeds down the login module list.
Stacked authentication can be achieved by a configuration policy containing multiple modules. Here's an example:
Login2 {
sample.SampleLoginModule required;
com.sun.security.auth.module.NTLoginModule sufficient;
com.foo.SmartCard requisite debug=true;
com.foo.Kerberos optional debug=true;
};
Overall authentication is governed by the individual modules and their LoginModuleControlFlag entry, as illustrated in Table 1. In the figure, p indicates pass, f indicates fail, and * indicates don't care entries.
|
Module
|
Criterion
|
Pass/Fail
|
|
SampleLoginModule
|
Required
|
p p p p f f f f
|
|
NTLoginModule
|
Sufficient
|
p f f f p f f f
|
|
SmartCard
|
Requisite
|
* p p f * p p f
|
|
Kerberos
|
Optional
|
* p f * * p f *
|
|
Overall
authentication
|
|
p p p f f f f f
|
|
Table 1. Overall authentication for a stack-based authentication policy
|
JAAS authorization
Once the user executing the code has been authenticated, the JAAS authorization component works in conjunction with the existing Java 2 CodeSource-based access control model. JAAS policy extends the Java 2 policy with the relevant Subject-based information. Therefore, permissions recognized and understood in Java 2 (java.io.FilePermission and java.net.SocketPermission, for example) are equally understood and recognized by JAAS. Although the JAAS security policy physically resides separately from the existing Java 2 security policy, the two policies should be treated as one logical policy.
A policy file syntax -- an extension to the Java 2 policy file -- looks like:
grant signedBy "alias", codeBase "URL",
principal principalClass "principalName",
principal principalClass "principalName",
... {
permission Type "name "action",
signedBy "alias";
permission Type "name "action",
signedBy "alias";
....
};
Here's an example entry:
grant CodeBase "http://foo.com",
Signedby "foo",
Principal com.sun.security.auth.NTPrincipal "admin" {
permission java.io.FilePermission "c:/user/admin", "read, write";
};
Notice that the policy file entries include a Principal entry, the basis for user-based authentication.
JAAS classes
The JAAS classes and interfaces reside in the following packages:
- javax.security.auth
- javax.security.auth.callback
- javax.security.auth.login
- javax.security.auth.spi
The classes and interfaces can be categorized as:
- Common classes:
- Subject
- Principal
- Credential
|