Often we think of security as a burden, a time-consuming process that requires us to jump through hoops just to get through a doorway or view a Web page on the company intranet. My first real appreciation for (or frustration with) security came a number of years ago. I was a PowerBuilder consultant in Minneapolis, helping the Federal Reserve Bank build its first-ever client/server application. Each day it was a hassle just to get past the security desk in the lobby, and the bombing of the World Trade Center in New York that year did nothing to ease the pain.
My next interesting security experience came last year on a project for the Department of Defense in Colorado Springs, Colorado. Our team was building a solution for the DOD in reply to a request for proposal they had made to update NORAD's command and control operations with new, distributed, component-based technologies.
On my first day at the site I was escorted to what looked like a bank vault, and I thought to myself, "Is this déjà vu or what"? A metal door about 1.5 feet thick stood between the outside world and me for the next three months. In fact, the development center was actually inside a SCIF (Secret Compartmental Information Facility). The government has several levels of security one you're probably familiar with is Top Secret. Yes, Top Secret is real, not just something out of "Mission Impossible" or the "X-Files." Information considered even more sensitive than Top Secret is held within SCIFs, where neither cell phones nor pagers are reliable, if they work at all. I was told the walls played music from the inside out to defend against listening devices. I couldn't resist imagining men in an unmarked van outside getting an earful of Bob Marley's "Buffalo Soldier" as they tried to listen in on our design sessions!
Security of information is important not only for the government, but also for companies seeking to protect sensitive information about their business or users. Security can take many forms: swipe cards, retinal scanning or just Bob playing reggae in the walls of your office. However, securing your data over the Internet and intranet is another story. There was no question then that Enterprise JavaBeans, targeted at enterprise solutions, had to include support for security in its specification. This month I'll provide an overview of EJB security and how it relates to keeping your corporate data safe.
EJB Security Model
EJB is an open architecture capable of integrating with existing security standards while sheltering components from advances in technology. With this in mind it's understandable that the EJB security model is both simple and flexible.
The basic concept surrounding EJB security is role-based access control of corporate data. Enterprise JavaBeans isn't as concerned about communications integrity as SSL protocol is, nor is EJB worried about playing a little too boisterously in the "sandbox"! Instead, enterprise beans are believed to be trusted components that are focused on data security.
EJB provides role-based security via ACLs (access control lists) and principals. ACLs are named list entries that are used to control permission to server-side resources. For instance, an ACL may be created to grant system administrators permission to deploy new components into an EJB server or to manage what roles at a bank can perform monetary transfers between member accounts. ACLs typically contain a set of permissions that are associated with the principal(s) on the list. A principal simply refers to a user of the resource a human user, an application or a component within an application.
Principals can be members of more than one ACL. It's left to the EJB server vendor to provide an implementation of role-based security. Each user may have different rights, or they may be grouped together into ACLs with similar permissions.
The EJB security model is flexible. Its component model provides container-managed security enforcement of the context of each call to an enterprise bean. As with other container-managed features such as persistence and transaction management, security permissions never have to be hard-coded by the bean provider. Instead, they can be finalized during deployment of the bean, allowing a more flexible approach to development and reusability. If a fine level of security is needed in the bean, javax.ejb.EJBContext interface provides a means for it to question the caller's identity itself.
How Does It Work?
This month let's take a look at how EJB's role-based security works. I'll save coverage of hard-coded security checks against the principal in EJBContext for a later article. To begin with, there are two aspects of security to define for an enterprise bean: method-level security policies and bean identity.
Method-Level Security Policy
During bean deployment, an AccessControlEntry for an enterprise bean is defined for each individual method and one may be made for an entire bean, which applies to all methods without individual security policies. This entry associates a role to an entry in a previously defined ACL of who is allowed to access the bean's method(s).
A bean instance has an identity, referred to as the "RunAs" security identity, associated with it at all times. This identity is determined at deployment and can be one of the following:
CLIENT_IDENTITY: Use the identity (principal) of the caller.
SYSTEM_IDENTITY: Use a predefined global system identity
SPECIFIED_IDENTITY: Use the identity specified by the RunAsIdentity security attribute.
When a bean attempts to access a system resource or another enterprise bean, this RunAs identity is associated with the method invocation (see below).
EJB Security in Action
When an operation on an enterprise bean component is invoked through its remote interface or its home interface, an EJBContext object is associated with the client's call and passed to the bean's container. The container uses the context to retrieve the caller's identity, or principal, and performs a lookup against the bean method's ACL to see if a corresponding access control entry exists for the client.
If an entry exists, the bean method is invoked. Also, the "RunAs" security identity of the bean is used for any future calls from the bean to system resources or other beans.
If an entry doesn't exist, permission to execute the bean method is denied, and a java.security.Exception is thrown. At this level it's the responsibility of the EJB Container to audit an attempted breach of security in the system. This detail is noted in 15.6.10 of the specification, but has yet to be formalized.
EJB Bank Security Scenario
This scenario represents a bank that contains sensitive account data for its members. Each enterprise bean in our example (UserSessionBean and AccountEntityBean) is protected through EJB's role-based security model.
For instance, a user in the role of Bank Teller may have read-and-write access privileges to Account beans, while other roles such as Loan Officer may only view account details but not make any modifications to the account. Users log in under a particular role and assume that role for all subsequent interactions with the system.
Figure 1 illustrates the security enforcement occurring in the system when a user tries to access an account. A Loan Officer, User A, invokes a UserSessionBean to view an account at the bank. A context containing his or her identity is passed along with the request to the EJB Container. When the container intercepts the method call, the identity of the caller is taken from the context and compared to the ACL entries for the bean's viewAccount() method. For our example let's assume the security check is successful. Next, the UserSessionBean delegates to the AccountEntityBean to actually get the account information.
Figure 2 illustrates how the "RunAs" characteristics of a bean are forwarded to other resources and enterprise beans. In this scenario the RunAs identity is set to CLIENT_IDENTITY and User A's identity is passed onto the AccountEntityBean's EJB Container where it is verified once again for permission to invoke the getAccountDetails() method. Because CLIENT_IDENTITY was chosen during deployment of the UserSessionBean, this bean instance actually assumes the identity of the original caller.
The EJB security model, as demonstrated in this scenario, is simple, yet effective at controlling the access to sensitive bank account information. The permissions were granted in a component-based fashion. Access control entries for each method were determined at deployment of the enterprise beans, and no hard-coded security checks were needed. This fosters flexibility in deploying the bean into new environments, encouraging reusability of the component.
Enterprise JavaBeans provides a simple yet effective and flexible model for enforcing role-based security in your applications. EJB eases the implementation of security requirements by providing you with the ability (1) to graphically define security permissions at bean deployment, and (2) to control access to data at the method level of the enterprise bean. When designing security for your next EJB application, I recommend taking a close look at harnessing the power of EJB security to save precious development time and protect company data from prying eyes.
Jason Westra is a
managing partner with Verge Technologies Group, Inc., a Java consulting firm
specializing in Enterprise JavaBeans solutions.
He can be reached at: [email protected]