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.
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.
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:
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:
The core classes for authorization are
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.
JSP Related Interview Questions
|J2EE Interview Questions||Core Java Interview Questions|
|JDBC Interview Questions||Java Servlets Interview Questions|
|Hibernate Interview Questions||JavaServer Faces (JSF) Interview Questions|
|JSTL(JSP Standard Tag Library) Interview Questions||JBOSS Interview Questions|
|Log4j Interview Questions||NHibernate Interview Questions|
|Apache Struts 2 Interview Questions|
All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.