Security in J2EE Applications - JSP

So far in this chapter you have seen how to build security into a Web application, but what if that Web application is part of a much larger J2EE application? What if EJB resources, for example, are also required? Within EJBs the same security model is used, in the sense of principals and roles.

For EJBs, the access rights can be defined declaratively or programmatically. If you are defining access declaratively, additional entries are added to the EJB deployment descriptor ejb-jar.xml.

Security roles are defined and then used for EJBs in ejb-jar.xml as shown in Listing

Listing ejb-jar.xml

<ejb-jar><enterprise-beans><!--all the beans are defined here à</enterprise-beans><assembly-descriptor> <security-role><description>

This is a registered user who can make purchases from the site

If you look at Listing ,you will see that there is some similarity with the deployment entries in the various web.xml examples that you have seen in this chapter.The example shown builds on the J2EE application that was created in the previous chapter. Notice the role is defined within the assembly descriptor.This will map to a role that is defined within the application server, typically through a visual interface of some kind. Figure shows the user interface for the configuration of roles within the WebLogic 7 Application Server.

Web logic role configuration screen.

Web logic role configuration screen.

Look again at Listing .You can see the security roles being defined.To then relate those to specific EJB methods, you use the <method-permission> elements as shown. These are also located within the <assembly-descriptor> element.The roles used within these method-permissions must be declared within the <security-role> elements as in the example.

A helpful thing to consider is that when your Web applications are interacting with EJBs, the user information is made available to the EJB application.Therefore, the EJB container will have access to the principal object that the Web container is using to identify the user.This means that users that have authenticated themselves within the context of the Web application will also be authenticated for the EJB container as well. However, there is a slight complication.There is a difference between how a web container and an EJB container handle unauthenticated users.

Unauthenticated Users

In a Web application, the principal can be identified with a call to the HttpServletRequest.getUserPrincipal() method. If no user has authenticated, it returns null. However, if you call the equivalent method EJBContext. getCallerPrincipal(), it must return a Principal object.

This must not be null. The J2EE 1.4 specification does not specify how a J2EE server must address this issue, but there a number of options open to application server vendors, including the followingrecommended in the J2EE specification:

  1. Use the same principal throughout the application.
  2. Use a different principal for each server instance, or each session, or each application.
  3. Use the <run-as> element enabling the application deployer to specify the principal to be used.

The <run-as> element

The <run-as> element can be used in both web.xml and ejb-jar.xml deployment descriptors.This allows the principal to be set at deploy time for a particular Web or J2EE application. A <run-as> element contains a <role-name> as shown below.

If this servlet then invoked an EJB, the principal ‘fred’ will be passed on to the invoked EJB.You can also declare a <run-as> element for the EJB itself.This is done within a <security-identity> element which contains the <run-as> element.This can then be used in the declaration elements for entity, session, and message-driven beans. An example of an entity bean using <run-as> is shown below. Message-driven and session beans are also done in the same way:

This entity bean will now be accessed with the principal ‘wilma’ being used, which means that if called by a Web application from an unauthenticated user, the EJBContext.getCallerPrincipal() method will not return null.

Java Authentication and Authorization Service (JAAS)

Within J2EE 1.3–compliant application servers, there is also a security API called the Java Authentication and Authorization Service (JAAS).This API is an extension to the security APIs already available.This API essentially provides application developers with the ability to enforce access control based on who is running code.

The key benefit that this brings to J2EE applications is that the Java developer is no longer concerned with how the underlying authentication takes place. So, the user information may be coming from a Win2K domain, an LDAP directory, or an Oracle database. The Java application is shielded from the detail. The authentication is done by what are referred to as pluggable modules.These are also referred to as login modules, and will normally request a username and password. There are two core functions of JAAS:

  • Authentication
  • Authorization

The core classes for authorization are

  • Subject—the subject represents a user or users, plus any security-specific attributes referred to as credentials.
  • Principal—the principals represent the subject identities.You have seen these earlier in the chapter.
  • Credentials—these are the security-specific attributes, which are represented by Java classes that optionally implement either the Refreshable or the Destroyable interfaces.

For authentication there is a LoginContext, which contains references to the LoginModules that contain the actual logic for the authentication process. WebLogic 7 has full support for JAAS, and a URL containing more information on JAAS in WebLogic 7.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

JSP Topics