Home TOC

Search Feedback

Authentication

Describe the relationship between authentication and resource protection in the web tier and the EJB tier. Talk about lazy authentication in the web tier. If a resource is protected by an authorization constraint, authentication will be forced. The EJB tier semantics are different, although I'm not exactly sure how to say so this quickly. Very important: pound home the declarative message; subsections under Authentication should that tell the reader what to "declare" with respect to authentication (such as the login mechanism in the web tier). Be careful to differentiate configuration from declaration.

Authentication is the mechanism by which callers and service providers prove to one another that they are acting on behalf of specific users or systems. When the proof is bidirectional, it is referred to as mutual authentication. Authentication establishes the call identities and proves that the participants are authentic instances of these identities. An entity that participates in a call without establishing or proving an identity (that is, anonymously), is called unauthenticated.

When calls are made from a client program being run by a user, the caller identity is likely to be that of the user. When the caller is an application component acting as an intermediary in a call chain that originated with a user, the identity may be associated with that of the user. In this case, the component impersonates the user. Alternatively, one application component may call another with an identity of its own and unrelated to that of its caller.

Authentication is carried out in two phases:

1. Service-independent authentication that requires knowledge of some secret is performed to establish an authentication context that encapsulates the identity and is able to create proofs of identity, called authenticators.
2. The authentication context is then used to authenticate with other called or calling entities.

Controlling access to the authentication context, and thus the ability to authenticate as the associated identity, becomes the basis of authentication. The following policies and mechanisms can be used for controlling access to an authentication context:

• Once the user performs an initial authentication, all processes started by the user inherit access to the authentication context.
• When a component is authenticated, access to the authentication context may be available to other related or trusted components, such as those that are part of the same application.
• When a component is expected to impersonate its caller, the caller may delegate its authentication context to the called component.

J2EE Users, Realms, and Groups

A J2EE user is similar to an operating system user. Typically, both types of users represent people. However, these two types of users are not the same. The J2EE authentication service has no knowledge of the user and password you provide when you log on to the operating system. The J2EE authentication service is not connected to the security mechanism of the operating system. The two security services manage users that belong to different realms.

A realm is a collection of users that are controlled by the same authentication policy. The J2EE authentication service governs users in two realms: certificate and default.

Certificates are used with the HTTPS protocol to authenticate web browser clients. To verify the identity of a user in the certificate realm, the authentication service verifies a X509 certificate. For step-by-step instructions, see Setting Up a Server Certificate. The common name field of the X509 certificate is used as the principal name.

In most cases, the J2EE authentication service verifies user identity by checking the default realm. This realm is used for the authentication of all clients except for web browser clients that use the HTTPS protocol and certificates.

A J2EE user of the default realm may belong to J2EE group. (A user in the certificate realm may not.) A group is a category of users, classified by common traits such as job title or customer profile. For example, most customers of an e-commerce application might belong to the CUSTOMER group, but the big spenders would belong to the PREFERRED group. Categorizing users into groups makes it easier to control the access of large numbers of users. A later section, Authorization, discusses controlling user access to enterprise beans.

Managing J2EE Users and Groups

The realmtool utility is a command-line program that ships with the J2EE SDK. You can use this utility to add to and remove users from the default and certificate realms.

To display all users in the default realm, type this command:

realmtool -list default 

To add a user to the default realm, specify the -add flag. The following command adds a user named rover who is protected by the password red, and includes rover in the customer and preferred groups:

realmtool -add rover red customer,preferred 

To add a user to the certificate realm, you import a file containing the X509 certificate that identifies the user:

realmtool -import certificate-file 

To remove a user, you specify the -remove flag. For example, to remove a user named tjones from the default realm, you would type the following command:

realmtool -remove default tjones 

To add a group to the default realm, you specify the -addGroup flag. The following command adds the customer group:

realmtool -addGroup customer 

You cannot add a group to the certificate realm.

To remove a group from the default realm, you specify the -removeGroup flag:

realmtool -removeGroup customer 

Authentication Mechanisms

In a typical J2EE application, a user goes through a client container to interact with enterprise resources in the web or EJB tiers. Resources that are available to the user may be protected or unprotected. Protected resources are distinguished by the presence of authorization rules, rules that restrict access to a subset of non-anonymous identities. To access a protected resource, a user needs to present a non-anonymous credential so its identity can be evaluated against the resource authorization policy. If a trust relationship between the client and resource containers does not exist, the credential must be accompanied by an authenticator that confirms its validity. This section describes authentication mechanisms that the J2EE platform supports and explains how to use deploytool to configure those mechanisms.

Web-Tier Authentication

You can protect a collection of web resources (web components, HTML documents, image files, compressed archives, and so on) by specifying an authorization constraint (described in Controlling Access to Web Resources) for the collection. If an anonymous user tries to access a protected web resource, the web container will prompt that user for a password to authenticate with the web container. The request will only be accepted by the web container after the user identity has been proven to the web container and that identity has been shown to be one of the identities granted permission to access the resource. Caller authentication that is performed on the first access to a protected resource is called lazy authentication.

When you try to access a protected web-tier resource, the web container activates the authentication mechanism that has been defined. J2EE web containers are required to support HTTP basic authentication, form-based authentication, and HTTPS mutual authentication, and are encouraged, but are not required, to support HTTP digest authentication.

In basic authentication, the web server authenticates a principal using the user name and password obtained from the web client. In digest authentication a web client authenticates to a web server by sending the server a message digest along with its HTTP request message. The digest is computed by employing a one-way hash algorithm to a concatenation of the HTTP request message and the client's password. The digest is typically much smaller than the HTTP request, and doesn't contain the password.

Form-based authentication lets developers customize the authentication user interface presented by an HTTP browser. Like HTTP basic authentication, form-based authentication is not secure, since the content of the user dialog is sent as plain text, and the target server is not authenticated. In single-signon environments, discretion must be exercised in customizing an application's authentication interface. It may be preferable to provide a single enterprise-wide custom user authentication interface, rather than implementing a set of application-specific interfaces.

With mutual authentication, the client and server use X.509 certificates to establish their identity. Mutual authentication occurs over a channel that is protected by SSL. Hybrid mechanisms that feature either HTTP basic authentication, form-based authentication, or HTTP digest authentication over SSL are also supported.

Configuring A Web Component's Authentication Mechanism

To configure the authentication mechanism that a web component will use:

1. Select the web component in the tree view. The Web Component inspector will be displayed.
2. Select the Security tab.
3. Choose one of the following authentication mechanisms from the User Authentication Method pulldown menu:
   • Basic
   • Form Based
   • Client Certificate
   • None
   • If you chose Basic authentication, you must enter Default in the Realm name field.
   • If you chose Form Based authentication, you must fill in the Login Page and Error Page fields.

Using Hybrid Authentication to Enhance Confidentiality

Passwords are not protected for confidentiality with HTTP basic or form-based authentication. To overcome this limitation, you can run these authentication protocols over an SSL-protected session and ensure that all message content, including client authenticators, are protected for confidentiality.

To configure HTTP basic or form-based authentication over SSL:

1. Select the web component in the tree view. The Web Component inspector will be displayed.
2. From the Security tabbed pane, make sure that Basic or Form Based have been selected in the User Authentication Method menu pulldown.
3. Click on the Add button in the Security constraint section.
4. Click on the Security constraint that was added.
5. Select CONFIDENTIAL in the Network Security Requirement menu pulldown.

Controlling Access to J2EE Resources

In a typical J2EE application, a client goes through its container to interact with enterprise resources in the web or EJB tiers. Protected and unprotected resources may be available to the user. Protected resources are distinguished by the presence of authorization rules that restrict access to some subset of non-anonymous identities. To access a protected resource, a user must present a non-anonymous credential so its identity can be evaluated against the resource authorization policy. In other words, caller authentication is required any time a caller tries to access a protected component.

Controlling Access to Web Resources

To control access to a web resource, you use the deploytool to specify a security constraint:

1. Select the web component in the tree view.
2. Select the Security tabbed pane.
3. Click the Add button in the Security Constraints section of the screen.
4. Click the Edit button adjacent to the Web Resource Collection field to add a web resource collection to the security constraint. the web resource collection describes a URL pattern and HTTP method pair that refer to the resources that need to be protected.
5. Click the Edit button adjacent to the Authorized Roles field to add an authorization constraint to the security constraint. You specify the set of roles that can access the web resource collection.
6. From the Transport Guarantee menu, select the user data constraint, either None, Integral, or Confidential. This setting indicates with what degree of protection the resource can be accessed.

Controlling Access to Enterprise Beans

If you defined security roles for an enterprise bean, you can also specify the methods of the remote and home interface that each security role is allowed to invoke. This is done in the form of method-permission elements. Ultimately, it is the assignment of users to roles that determines if a resource is protected. When the roles required to access the enterprise bean are assigned only to authenticated users, the bean is protected.

Unprotected Resources

Many applications feature unprotected web-tier content, available to any caller without authentication. Some applications also feature unprotected enterprise beans. In either tier, unprotected resources are characterized by the absence of a requirement that their caller be authenticated. In the web tier, unrestricted access is provided simply by leaving out an authentication rule. In the EJB tier, unrestricted access is accomplished by mapping at least one role, which is permitted access to the resource, to the universal set of users independent of authentication.

Client Authentication

The J2EE authentication service controls access from all types of bean clients: J2EE application clients, stand-alone Java applications, and web components.

When a J2EE application client starts running, its container pops open a window that requests the J2EE user name and password. If you run the J2EE application client described in Running the J2EE Application Client you'll see this log-on window in action. The authentication service verifies that the user name and password from the log-on window exist in the default realm. After authentication, the user's security context is associated with any call that the client makes to enterprise beans deployed in the J2EE server.

Many applications do not require authentication. For example, an online product catalog would not force customers to log on if they are merely browsing. Also, when you first start developing an application, you may find it convenient to allow an unauthenticated and anonymous user named guest to access the application's components.

During deployment, you specify whether or not a web component is a protected resource. If the web component is unprotected, anyone may access it from their browser. If an unprotected web component accesses an enterprise bean, the authentication service assigns it a certificate for the guest user. Any subsequent calls to enterprise beans are associated with the guest user.

Auto-Registration of Users

Many e-commerce applications have been designed to make it as easy as possible for a user to become a customer. Instead of waiting for an administrator to set up a user's account, many e-commerce applications enable users to set up their own accounts without any administrative intervention. A user usually needs to provide his or her identity and location, agree to some contractual obligations, provide credit card information for payment, and establish a password to protect the account. After completing the registration dialog, the user can access the protected resources of the site.

The J2EE platform does not specify mechanisms to support auto-registration. Therefore, these mechanisms are specific to the container implementation.

Web resources that provide the user interface for auto-registration must be protected. This is done by setting the transport-guarantee of these resources to CONFIDENTIAL.

Web Client Authentication

This section will describe how to declare the web tier authentication mechanisms.

Data Protection

TBD. This section will describe how to use SSL to provide data protection. It will talk about declaring data protection in the web tiers and explain the relationship between data protection and authentication.

Developing a Custom Web Tier User Authentication Interface

TBD. After briefly describing the form-based login authentication mechanism, this section will describe how to create a custom web-tier user authentication interface and explain how to install the interface.

Application Client Authentication

TBD. This section will describe the declarative aspects of application client authentication.

This section will also explain how to configure a JAAS login module in an application client.

Application client authentication to the web tier will be shown, but the section will concentrate on application client authentication to the EJB tier.

Setting Component Security Identities

TBD. This section will explain the configuration and declaration aspects of using run-as-specified-identity and RunAs caller.

Capturing a Security Context (Servlet)

TBD. This section will describe how to set up a servlet security context for subsequent EJB invocations. This is done by using the session object, and recording the session id in the servlet, so that you can use it.

Container Authentication

TBD. This section will describe how a container authenticates to its clients with the J2EE SDK for a web server using SSL and an EJB server using CSIV2/SSL.

Setting Up a Server Certificate

Certificates are used with the HTTPS protocol to authenticate web browser clients. The HTTPS service of the J2EE server will not run unless a server certificate has been installed. To set up a J2EE server certificate, follow these steps:

1. Generate a key pair and a self-signed certificate.

The keytool utility enables you to create the certificate. The keytool utility that ships with the J2EE SDK has the same syntax as the one that ships with the Java 2 Standard Edition. However, the J2EE SDK version programmatically adds a Java Cryptographic Extension provider that has implementations of RSA algorithms. This provider enables you to import RSA signed certificates.

To generate the certificate, run the keytool utility as follows, substituting <certificate-alias> with the alias of your certificate:

keytool -genkey -keyalg RSA -alias <certificate-alias> 

2. The keytool utility prompts you for the following information:
   1. keystore password - The default value of this password is changeit. You can change the password by editing the config/auth.properties file.
   2. first and last name - Enter the fully-qualified name of your server. This fully-qualified name includes the host name and the domain name.
   3. organizational unit - Enter the appropriate value.
   4. organization - Enter the appropriate value.
   5. city or locality - Enter the appropriate value.
   6. state or province - Enter the unabbreviated name.
   7. two-letter country code - For the USA, the two-letter country code is US.
   8. key password for alias - Do not enter a password. Press Return.
3. Import the certificate.
   
   If your certificate will be signed by a Certification Authority (CA) other than Verisign, you must import the CA certificate. Otherwise, you may skip this step. (Even if your certificate will be signed by verisign Test CA, you must import it.)
   
   To import the certificate, perform these tasks:
   1. Request the CA certificate from your CA. Store the certificate in a file.
   2. To install the CA certificate in the Java 2 Platform, Standard Edition, run the keytool utility as follows. (You must have the required permissions to modify the $JAVA_HOME/jre/lib/security/cacerts file.)

      keytool -import -trustcacerts -alis <ca-cert-alias> -file <ca-cert-filename> 
      

4. Generate a Certificate Signing Request (CSR).

   keytool -certreq -sigalg MD5withRSA -alias <cert-alias> -file <csr-filename> 
   

5. Send the contents of the <csr-filename> for signing

If you are using Verisign CA, go to http://digitalid.verisign.com/. Verisign will send the signed certificate in email. Store this certificate in a file.

6. Import the signed certificate that you recieved in email into the server:

   keytool -import -alias <cert-alias> -file <signed-cert-file> 
   

Configuring EJB Target Security Requirements

TBD. This section will describe how to configure EJB target security requirements in relation to authentication and message protection.

Configuring Resource Signon (Connectors)

TBD. This section will describe how to plug a connector into a container, for the J2EE SDK. It will explain how to declare the use of the container in the EJB deployment descriptor. The section will also describe how to do bean-managed programmatic resource sign on via the connector.

Home TOC

Search Feedback