Post
Ask Question

Implementing EJB Security

Introduction

 
Different applications and environments have different security requirements. To help categorize the security needs of your application better, you need to look at some of the basic underlying principles on which security is based for most applications.
 

Physically Separated Tiers

 
An important part of the implementation of the security infrastructure is the physical separation of the data, application, and web servers. These servers all run on different tiers, and it is best if all three tiers are implemented on different physical machines. The Web server is typically on a machine that has dedicated internet access. This tier is usually the gatekeeper for client requests from outside the organization’s network. Client applications running on remote machines access the web server via the internet to request access to the application tier.
 
The application server is usually on a physical machine separate from the machine housing the web server. The application tier typically cannot be accessed directly by remote clients from the internet. These days, many vendors provide implementations where the Web Server is incorporated into the EJB server. While these implementations provide faster performance and easier maintenance for system administrators, they are a potential security risk. Since both the web server and application server are housed together, if a hacker gains access to the webserver, it will be easier for the application server to be exposed as well, as it is also running on the machine that has direct internet access.
 
The data server runs on a separate that may also be running ERP systems. The data server is the repository of the entire system. The data server should be well-protected within the organization’s network. Precautions, such as encrypting the information stored in the database via systems, are one way of countering potential information breaches. Such encryption systems should be run on separate machines that are not connected to the internet. This will mean a slight loss in performance, but will lead to increase in protection for the data.
 
Figure 1 below illustrates a physical network topology for a typical EJB application. The Web-tier between both the firewalls is most in danger from intruders and hackers.
 
Implementing EJB Security 
Figure1: EJB Application Network Topology
 

User-level Access Based on Username/Password

 
Another common way to implement security in EJB systems is to authenticate users using a username and password. This method relies on maintaining security by allowing the username and password to be the only two pieces of information provided by the end-user. Applications use digital certificates to protect the user’s authentication details. Digital certificates use the Secure Socket Layer (SSL) to protect data sent via web browsers. SSL makes use of an SSL-compatible variant of the HTTP protocol, called the HTTPs protocol.
 
Usually, certificates are installed only on the web server and not on the clients machine. If the client also has a certificate and provide it as a means of authentication. It is known as a case of mutual authentication, as each party can authentication the other. This is more common in B2B applications than in B2C applications.
 

Different vendors

 
EJB developers can select products from different vendors while building their EJB application environment. Interoperability is one of the main goals of EJB architectures and the EJB and J2EE specifications provide strict guidelines for interoperability between different components in the EJB application. Achieving interoperability between security products in the same application however, throws many challenges. You may find it difficult to use different security products, which follow the same security specification, together, unless they have been developed by the vendors in collaboration.
 
This problem is often overcome by using the SSL as a standard for security interactions between system tiers. As J2EE uses RMI/IIOP to communicate between clients and containers. IIOP can be stacked on top of SSL.
 

Sensitive and Non-Sensitive Data

 
The choice of security measures being implemented also depends on the kind of data being exchanged , and what parties it is being exchanged between. Applications often implement secure modes such as HTTPS only when sensitive data is being transmitted. This can be data such as credit-card numbers or username/passwords.
 
The choice of when to use what security mode is made during the design of the system. Designers choose what data to secure and how to security is, only after looking at the degree of sensitivity and vulnerability of data being transferred.
 

J2EE Security Architecture

 
The J2EE security architecture specifications are based on certain security requirements as well as non-requirements.
 
Requirements
 
The J2EE security architecture of the J2EE specifications are based on certain security requirements.
 
Flexibility
 
The security mechanisms and declarations of applications should not be used to impose any security policy, but only to help in implementation of over-all security policies specific to the particular J2EE installation.
 
Transparency
 
The security policies of the J2EE implementation need not be visible to the Bean providers who write the beans.
 
Demarcation
 
There is complete demarcation of responsibilities between the deployer and the system administrator . The deployer establishes the authentication and access control on the J2EE implementation and the system administrator manages the same.
 
Portability
 
The J2EE security architecture must not compromise Java policy on application portability. J2EE applications that need access to information available in the security environment, make use of APIs for interacting with container/server information. Only those applications that restrict their interactions to the provides APIs manage to retain portability.
 
Compatibility
 
All the J2EE security architecture requirements must be expressed unambiguously, which can make people aware whether the implementation is compatible or not.
 
Abstraction
 
J2EE components security settings are made in the deployment descriptors. The deployment descriptors help map security roles and access requirements to environment specific security roles, users and policies. A deployer may want to modify the security properties to be consistent with the deployment environment. The deployment descriptor should contain details about the parameters that can be changed and those that cannot be changed.
 
Independence
 
The required security behaviors should be implantable using a variety of popular security technologies.
 
Non- Requirements
 
There are certain security related features that are not required by the J2EE specifications:
  • The specifications do not mandate any specific security policy. The specifications allow the product providers to implement the security technology of their choice and administer the policies they require.
  • The specifications do not dictate a specific security technology , such as Kerberos, Network Information Service Plus (NIS+) and NT LAN Manager (NTLM)
  • The specification do not require that the selected security technology be implemented everywhere in the application.
  • The specification do not guarantee effective security of a J2EE product.
  • The specifications do not specify that the interactions between EJBs running on different, but compatible , J2EE products be secure.

Lazy Authentication

 
Authentication is processing-intensive and may require exchange of multiple messages across the network. You should implement only when required. This process is called lazy authentication. With lazy authentication, an end user is required to authenticate by providing necessary authentication data only when the user tries to access a secured resource.
 
Security Settings
 
To make an EJB application secure, you should make appropriate changes in the deployment descriptors.
 
Source code 1 and 2 illustrate the security setting in the deployment descriptors of an EJB application.
 
Code 1 is form ejb-jar.xml. In the session element of ejb-jar.xml file, the security role-name is set to master and role-link is set to BankMaster.
 
In the assembly-descriptor element, the principal with the role name, BankMaster is allowed to execute the updateCustomerInfo method of CustomerBean bean.
 
Source code
  1. <session>  
  2.     <display-name>CustomerSB</display-name>  
  3.     <ejb-name>CustomerBean</ejb-name>  
  4.     <home>com.data.CustomerRemoteHome</home>  
  5.     <remote>com.data.CustomerRemote</remote>  
  6.     <ejb-class>com.data.CustomerBean</ejb-class>  
  7.     <session-type>Stateless</session-type>  
  8.     <transaction-type>Container</transaction-type>  
  9.     <security-role-ref>  
  10.         <role-name>Master</role-name>  
  11.         <role-link>BankMaster</role-link>  
  12.     </security-role-ref>  
  13. </session>  
  14. <assembly-descriptor>  
  15.     <security-role>  
  16.         <role-name>BankMaster</role-name>  
  17.     </security-role>  
  18.     <method-permission>  
  19.         <role-name>BankMaster</role-name>  
  20.         <method>  
  21.             <ejb-name>CustomerBean</ejb-name>  
  22.             <method-name>UpdateCustomerInfo</method-name>  
  23.         </method>  
  24.     </method-permission>  
  25. </assembly-descriptor>  
Source Code
 
Is from the vendor-specific deployment descriptor, in which the principal name Wincent is mapped to the role-name, BankMaster and group-name, master.
  1. <security-role-mapping>  
  2.     <role-name>BankMaster</role-name>  
  3.     <principal-name>Wincent</principal-name>  
  4.     <group-name>master</group-name>  
  5. </security-role-mapping>  
Source code
  1. protected void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {  
  2.         response.setContentType("text/html;charset-UTF-8");  
  3.         PrintWriter out = response.getWriter();  
  4.         try {  
  5.             //Environment Settings  
  6.             Properties env = new Properties();  
  7.             env.put(InitialContext.SECURITY_PRINCIPAL, "Wincent");  
  8.             Context ic = new InitialContext(env);  
  9.             CustomerRemoteHome customerHome = null;  
  10.             CustomerRemoteHome customerHome = (CustomerRemoteHome) ic.lookup("ejb/CustomerBean");  

Summary

 
An application has differing security requirements based on sensitivity of data and environment. J2EE security architecture of the J2EE specifications are based on certain security requirements and non-requirements. In Lazy authentication, an end user is required to authenticate by providing necessary authentication data only when the user tries to access a secured resource. To make an EJB application secure, you should make appropriate changes in its deployment descriptors.


Similar Articles