JRun Administrator's Guide
JRun Security

JRun security architecture

Security is an important aspect of any application. To address the security issues involved with Internet applications, remote applications, and enterprise applications, J2EE APIs define authentication and authorization mechanisms to control user access to application resources. Authentication and authorization are defined as follows:

• Authentication  Identifies the user, typically by requiring a user ID and password and matching them against an existing user store. However, you can extend the system to require customized authentication credentials.
• Authorization  Identifies which resources the user is allowed to access. J2EE authorization is based on the role or roles assigned to each user. In order for a user to access a secure resource, that user must be assigned to a role that is authorized to access the resource. Examples of roles include manager, developer, and customer.

  Note:   You cannot nest roles. That is, a role cannot be defined as a valid user for a role.

The JRun authentication mechanism is a clustered service. What this means is that a user who is authenticated on one JRun server in a cluster is automatically authenticated on all servers in the cluster.

J2EE security usage areas

To handle all aspects of an authentication and authorization system, J2EE security covers multiple areas, each of which is handled by different roles:

• Role definition and programmatic security  The application developer defines the roles that apply at the web application or EJB level. The application developer can optionally implement programmatic security, as required by the application. For more information, see JRun Programmer's Guide. Declarative security is recommended over programmatic security for most J2EE applications.
• Client coding  The application developer ensures that web application and EJB clients pass the required credentials (typically a user ID and password) at the appropriate time. Web application clients prompt for user ID and password. EJB clients either use credentials from the calling web application component or pass user ID and password as properties to the InitialContext constructor. JMS clients can specify user ID and password in the jrun-resources.xml file. For more information, see JRun Programmer's Guide.
• Role resolution and declarative security  The application assembler resolves and links programmer-defined roles with system roles. The application assembler also specifies declarative security in the web and EJB deployment descriptors. For more information, see JRun Assembly and Deployment Guide.
• Security architecture and user-store management  The administrator controls the user store, coordinates global role definition, and customizes JRun security to match the site-specific security environment. The following sections describe the tasks performed by the administrator and other topics related to security administration.

JAAS overview

Earlier J2EE specifications did not specify a standard mechanism for integrating applications with existing security systems and user stores, leaving this integration mechanism to be handled in a proprietary manner by each application server vendor. J2EE 1.3, however, requires that application servers use the Java Authentication and Authorization Service (JAAS) as the security framework. JAAS is a set of packages that enables JRun to authenticate users and enforce access controls in a modular fashion.

JAAS was originally an optional package in the Java 1.3 SDK and is integrated into the Java 1.4 SDK.

JAAS provides a Plug and Play mechanism that enables you to customize the system to integrate with existing authentication user stores, such as LDAP or a relational database. You can find detailed JAAS information at http://java.sun.com.

JAAS allows authentication to be performed in a pluggable fashion. That is, you can substitute a customized login module and JRun will automatically call that login module's login method when performing authentication. For more information, see "Extending JRun security".

It is important to remember that JAAS is not solely a J2EE technology. You can use it for any Java program and, by default, JAAS authorization uses policy files. However, most J2EE application servers (including JRun) do not use policy files for authorization. JRun handles authorization by extending the JAAS authentication mechanism. When the JRun security manager receives an authorization request, it calls the login module's login method, passing the username and a Collection object containing the set of permissible roles. The login method then determines whether the authenticated user is a member of an authorized role.

JRun default security implementation

The JRun security architecture uses JAAS-based login modules to perform authentication and authorization using user and role stores that are tightly bound to the login module. A login module implements the javax.security.auth.spi.LoginModule interface. You code the logic in the login module, and JRun uses the JAAS API to call the login module at the appropriate times.

JRun provides a default login module that accesses an XML-format user and role store. It also provides a user manager service to manage users and roles.

The JMC uses this system to control user access, and you can use it in web applications, EJBs, and other components, as appropriate. For more information, see "Using the default JRun security mechanism".

Extending JRun security

Many sites have a pre-existing security infrastructure that defines users and their roles. Use one of the following options to integrate with your existing infrastructure:

• JRun-supplied login module  Use one of the login modules that ships with JRun. For more information, see "Integrating with an existing security mechanism".
• Customized login module  You can create a site-specific login module to use the existing security infrastructure for authentication and authorization. For more information, see "Using a customized security implementation".

You can optionally implement a site-specific user manager for dynamic user store update. However, in most cases, customized security implementations do not require this functionality. For more information, see "Defining a custom user manager".

Send me an e-mail when comments are added to this page | Comment Report

Current page: http://livedocs.adobe.com/jrun/4/JRun_Administrators_Guide/authentic2.htm

Add Comment