This presentation is part of the Authentication Overview Self-Study Course.

Transcript

Let’s look at how container-managed security is architected and what steps are involved in the authentication. 

There are two types of clients that may access the system:

1. Users (web clients coming in through browser access)
2. Applications (EJB clients)

We want to take a closer look at how human users access the system and are authenticated.

The application server can be configured to authenticate a user in one of three ways:

1. Basic HTTP authentication
2. Form based authentication
3. Authentication with client-side certificates

In basic HTTP authentication, the server returns the 401 response code to the browser if the user tries to access a protected resource.  The browser pops up the well-known grey dialog box prompting the user for a user name and password.

Form-based authentication allows applications to present site-specific login forms instead of the basic authentication prompt.  The J2EE Servlet 2.2 specification does not define a mechanism for logging out. Many application server vendors extend J2EE by also providing a form-logout mechanism.

When using certificate based authentication, users need to explicitly prove their identities only to a certificate authority (CA).  A CA is a trusted third party; users and components of an IT system agree to trust the CA to perform the necessary authentication for them.  (The user actually authenticates with the Web Server; the web server plug-in forwards the client certificate to the app server, which extracts information from the certificate and looks up the user in the registry.)

In the authentication schemes described so far, the Application Server [or the web server] authenticates the user.  There is also a way to integrate IM systems such as Tivoli, SiteMinder, or others with the application server.  When this option is employed, the web authenticator hands off the user provided credentials to a module that interfaces with the IM solution.  When the IM was able to successfully authenticate the user, the application server forwards the request to the target URL.  With this option all security policies (protected resources, authorization profiles, etc.) are managed by the EIM.

How is container-managed security configured?  How can resources be protected and user roles enforced?  Declarative security, part of the J2EE security specification, provides a possible answer.  It prescribes a declarative language for security constraints enforced by the application server.  These constraints are contained in the web application’s web.xml file.

Declarative security describes four types of elements within a single security constraint:

1. The web resource collection element defines the URL and method of access of a protected resource.  In the example all HTTP GET and POST requests to URL's starting with /PRServletContainerAuth are protected.
2. The auth-constraint element describes the privileges a user must have to access the web resource.  Note:  These roles must also be defined in the application server.
3. The user data constraint element allows you to specify whether the HTTP transport should be secure [i.e., use secure sockets-layer (SSL) encryption].
4. The login-config element defines the authentication method (BASIC, FORM or CLIENT-CERT) that the application server is to use for the application.  It also defines the name of the realm that will be passed to the web browser or Certificate Authority to be used to construct the login prompt.