Document Information


Part I Introduction

1.  Overview

2.  Using the Tutorial Examples

Part II The Web Tier

3.  Getting Started with Web Applications

4.  JavaServer Faces Technology

5.  Introduction to Facelets

6.  Expression Language

7.  Using JavaServer Faces Technology in Web Pages

8.  Using Converters, Listeners, and Validators

9.  Developing with JavaServer Faces Technology

10.  JavaServer Faces Technology: Advanced Concepts

11.  Using Ajax with JavaServer Faces Technology

12.  Composite Components: Advanced Topics and Example

13.  Creating Custom UI Components and Other Custom Objects

14.  Configuring JavaServer Faces Applications

15.  Java Servlet Technology

16.  Uploading Files with Java Servlet Technology

17.  Internationalizing and Localizing Web Applications

Part III Web Services

18.  Introduction to Web Services

19.  Building Web Services with JAX-WS

20.  Building RESTful Web Services with JAX-RS

21.  JAX-RS: Advanced Topics and Example

Part IV Enterprise Beans

22.  Enterprise Beans

23.  Getting Started with Enterprise Beans

24.  Running the Enterprise Bean Examples

25.  A Message-Driven Bean Example

26.  Using the Embedded Enterprise Bean Container

27.  Using Asynchronous Method Invocation in Session Beans

Part V Contexts and Dependency Injection for the Java EE Platform

28.  Introduction to Contexts and Dependency Injection for the Java EE Platform

29.  Running the Basic Contexts and Dependency Injection Examples

30.  Contexts and Dependency Injection for the Java EE Platform: Advanced Topics

31.  Running the Advanced Contexts and Dependency Injection Examples

Part VI Persistence

32.  Introduction to the Java Persistence API

33.  Running the Persistence Examples

34.  The Java Persistence Query Language

35.  Using the Criteria API to Create Queries

36.  Creating and Using String-Based Criteria Queries

37.  Controlling Concurrent Access to Entity Data with Locking

38.  Using a Second-Level Cache with Java Persistence API Applications

Part VII Security

39.  Introduction to Security in the Java EE Platform

40.  Getting Started Securing Web Applications

41.  Getting Started Securing Enterprise Applications

42.  Java EE Security: Advanced Topics

Working with Digital Certificates

Creating a Server Certificate

To Use keytool to Create a Server Certificate

Adding Users to the Certificate Realm

Using a Different Server Certificate with the GlassFish Server

To Specify a Different Server Certificate

Using Form-Based Login in JavaServer Faces Web Applications

Using j_security_check in JavaServer Faces Forms

Using a Managed Bean for Authentication in JavaServer Faces Applications

Using the JDBC Realm for User Authentication

To Configure a JDBC Authentication Realm

Securing HTTP Resources

Securing Application Clients

Using Login Modules

Using Programmatic Login

Securing Enterprise Information Systems Applications

Container-Managed Sign-On

Component-Managed Sign-On

Configuring Resource Adapter Security

To Map an Application Principal to EIS Principals

Configuring Security Using Deployment Descriptors

Specifying Security for Basic Authentication in the Deployment Descriptor

Specifying Non-Default Principal-to-Role Mapping in the Deployment Descriptor

Further Information about Security

Part VIII Java EE Supporting Technologies

43.  Introduction to Java EE Supporting Technologies

44.  Transactions

45.  Resources and Resource Adapters

46.  The Resource Adapter Example

47.  Java Message Service Concepts

48.  Java Message Service Examples

49.  Bean Validation: Advanced Topics

50.  Using Java EE Interceptors

Part IX Case Studies

51.  Duke's Bookstore Case Study Example

52.  Duke's Tutoring Case Study Example

53.  Duke's Forest Case Study Example



Authentication Mechanisms

This section discusses the client authentication and mutual authentication mechanisms.

Client Authentication

With client authentication, the web server authenticates the client by using the client’s public key certificate. Client authentication is a more secure method of authentication than either basic or form-based authentication. It uses HTTP over SSL (HTTPS), in which the server authenticates the client using the client’s public key certificate. SSL technology provides data encryption, server authentication, message integrity, and optional client authentication for a TCP/IP connection. You can think of a public key certificate as the digital equivalent of a passport. The certificate is issued by a trusted organization, a certificate authority (CA), and provides identification for the bearer.

Before using client authentication, make sure the client has a valid public key certificate. For more information on creating and using public key certificates, read Working with Digital Certificates.

The following example shows how to declare client authentication in your deployment descriptor:


Mutual Authentication

With mutual authentication, the server and the client authenticate each other. Mutual authentication is of two types:

When using certificate-based mutual authentication, the following actions occur.

  1. A client requests access to a protected resource.

  2. The web server presents its certificate to the client.

  3. The client verifies the server’s certificate.

  4. If successful, the client sends its certificate to the server.

  5. The server verifies the client’s credentials.

  6. If successful, the server grants access to the protected resource requested by the client.

Figure 42-1 shows what occurs during certificate-based mutual authentication.

Figure 42-1 Certificate-Based Mutual Authentication

Diagram of six steps in mutual authentication with certificates

In user name/password-based mutual authentication, the following actions occur.

  1. A client requests access to a protected resource.

  2. The web server presents its certificate to the client.

  3. The client verifies the server’s certificate.

  4. If successful, the client sends its user name and password to the server.

  5. The server verifies the client’s credentials.

  6. If the verification is successful, the server grants access to the protected resource requested by the client.

Figure 42-2 shows what occurs during user name/password-based mutual authentication.

Figure 42-2 User Name/Password-Based Mutual Authentication

Diagram of five steps in mutual authentication with user name and password

Enabling Mutual Authentication over SSL

This section discusses setting up client-side authentication. Enabling both server-side and client-side authentication is called mutual, or two-way, authentication. In client authentication, clients are required to submit certificates issued by a certificate authority that you choose to accept.

There are at least two ways to enable mutual authentication over SSL:

  • The preferred method is to set the method of authentication in the web.xml application deployment descriptor to CLIENT-CERT. This enforces mutual authentication by modifying the deployment descriptor of the given application. In this way, client authentication is enabled only for a specific resource controlled by the security constraint, and the check is performed only when the application requires client authentication.

  • A less commonly used method is to set the clientAuth property in the certificate realm to true if you want the SSL stack to require a valid certificate chain from the client before accepting a connection. A false value (which is the default) will not require a certificate chain unless the client requests a resource protected by a security constraint that uses CLIENT-CERT authentication. When you enable client authentication by setting the clientAuth property to true, client authentication will be required for all the requests going through the specified SSL port. If you turn clientAuth on, it is on all of the time, which can severely degrade performance.

When client authentication is enabled in both of these ways, client authentication will be performed twice.

Creating a Client Certificate for Mutual Authentication

If you have a certificate signed by a trusted Certificate Authority (CA) such as Verisign, and the GlassFish Server cacerts.jks file already contains a certificate verified by that CA, you do not need to complete this step. You need to install your certificate in the GlassFish Server certificate file only when your certificate is self-signed.

From the directory where you want to create the client certificate, run keytool as outlined here. When you press Enter, keytool prompts you to enter the server name, organizational unit, organization, locality, state, and country code.

You must enter the server name in response to keytool’s first prompt, in which it asks for first and last names. For testing purposes, this can be localhost. The host specified in the keystore must match the host identified in the variable specified in your tut-install/examples/bp-project/ file. If this example is to verify mutual authentication and you receive a runtime error stating that the HTTPS host name is wrong, re-create the client certificate, being sure to use the same host name you will use when running the example. For example, if your machine name is duke, then enter duke as the certificate CN or when prompted for first and last names. When accessing the application, enter a URL that points to the same location (for example, https://duke:8181/mutualauth/hello). This is necessary because during SSL handshake, the server verifies the client certificate by comparing the certificate name to the host name from which it originates.

To Create a Client Certificate and Keystore

To create a keystore named client_keystore.jks that contains a client certificate named client.cer, follow these steps.

  1. Create a backup copy of the server truststore file. To do this,
    1. Change to the directory containing the server’s keystore and truststore files, domain-dir\config.
    2. Copy cacerts.jks to cacerts.backup.jks.
    3. Copy keystore.jks to keystore.backup.jks.

      Do not put client certificates in the cacerts.jks file. Any certificate you add to the cacerts file effectively can be a trusted root for any and all certificate chains. After you have completed development, delete the development version of the cacerts file and replace it with the original copy.

  2. Generate the client certificate. Enter the following command from the directory where you want to generate the client certificate:
    java-home\bin\keytool -genkey -alias client-alias -keyalg RSA
    -keypass changeit -storepass changeit -keystore client_keystore.jks
  3. Export the generated client certificate into the file client.cer:
    java-home\bin\keytool -export -alias client-alias -storepass changeit
    -file client.cer -keystore client_keystore.jks
  4. Add the certificate to the truststore file domain-dir/config/cacerts.jks. Run keytool from the directory where you created the keystore and client certificate. Use the following parameters:
    java-home\bin\keytool -import -v -trustcacerts -alias client-alias
    -file client.cer -keystore domain-dir/config/cacerts.jks
    -keypass changeit -storepass changeit

    The keytool utility returns a message like this one:

    Owner: CN=localhost, OU=My Company, O=Software, L=Santa Clara, ST=CA, C=US
    Issuer: CN=localhost, OU=My Company, O=Software, L=Santa Clara, ST=CA, C=US
    Serial number: 3e39e66a
    Valid from: Tue Nov 27 12:22:47 EST 2012 until: Mon Feb 25 12:22:47 EST 2013
    Certificate fingerprints:
        MD5: 5A:B0:4C:88:4E:F8:EF:E9:E5:8B:53:BD:D0:AA:8E:5A
        Signature algorithm name: SHA1withRSA
        Version: 3
    Trust this certificate? [no]: yes
    Certificate was added to keystore
    [Storing cacerts.jks]
  5. Restart GlassFish Server.