Cloud Security Authors: Pat Romanski, Liz McMillan, Elizabeth White, Zakia Bouachraoui, Yeshim Deniz

Related Topics: Java IoT, Cloud Security

Java IoT: Article

Implementing J2EE Security With WebLogic Server

Implementing J2EE Security With WebLogic Server

This month's article is the first in a two-part series on J2EE security. In Part 1 we'll discuss basic J2EE security. Part 2 will provide you with a model to set up and deploy a functioning security-enabled application. Resident J2EE security guru, Chris Siemback, has been kind enough to join me in coauthoring this series to contribute in-depth examples of J2EE security at work.

Our discussions will cover securing both Enterprise JavaBeans (EJBs) in the business and data layers as well as JavaServer Pages (JSPs) and servlets in the web layer of a J2EE application.

J2EE Security Overview
Understanding the strong suits and weaknesses in the J2EE security model will help you determine the right security architecture for your application. A basic overview of J2EE security will help you compare its qualities to your security requirements. Let's come to grips with a few terms we'll see in the discussion that follows:

  • Principal
    A principal is an entity that can be authenticated in an enterprise application. The data and the content required to be authenticated may be different from implementation to implementation, but a principal is generally authenticated by a username and password combination.
  • Security Policy Domain
    A security policy domain, commonly called a realm or, just, security domain, is simply the implementation of a store containing authentication and authorization information and the enforcement of policies on this information as defined by a security administrator. Security domains are typically repositories where users, groups, permissions, and secured resources are stored. In other words, the realm contains the usernames, passwords, and roles that the container uses to authenticate and authorize user requests. A realm may be based on LDAP, UNIX, database, and NT security stores, or it may simply be XML documents that are read by the application server.

    With so many choices in security domains, how do you choose which one to use in your enterprise application? Numerous factors are involved including politics, corporate standards, and features such as the ability to modify the realm and for the realm to cache information.

    For instance, politics and technology often govern standards in the organizations with which we work. If an organization has standardized on NT, you may choose to leverage the existing NT security.

    For large-scale applications, you should ensure that your implementation of a J2EE security domain has at least the ability to add, remove, and modify users, roles, privileges, and secured resources to and from the realm without having to shut down the server. Some implementations are statically loaded and do not allow reloading of security information. However, this forces downtime to reload modified information, which is generally not acceptable in today's online applications.

    Also, a great feature to have in your realm is the ability to cache security information. Although it may change (as mentioned above) this information is generally static, and a high-performing application needs the ability to cache commonly used information at the application server level rather than retrieving it from a persistent store with each request.

  • Credential
    A credential either contains security attributes or refers to attributes for a principal. A credential is used to grant access to other secured services; thus it's passed along to each service accessed by the principal. If security attributes are not passed along, they may be retrieved from a trusted third party storing the information required for authentication and authorization.

  • Authentication and Authorization
    When you attempt to access restricted resources, the container is responsible for both authenticating and authorizing the request based on your credentials. Authentication is the process of verifying who you are. Authorization is the step made after authentication that verifies whether or not you may use a secured resource.

    Now that you have a handle on the security vocabulary we'll be using, let's look at how J2EE security allows the authentication and authorization of principals within a security domain, providing access to secured resources such as Web components and EJBs.

Characteristics of J2EE Security
There are two main characteristics of J2EE security: it's role-based rather than user-based (object level), and declarative rather than code-based. J2EE security is designed to be a role-based, declarative approach to securing applications and resources through the use of security domains.

  • Role-based Security
    J2EE security authorizes access to resources based on the role of the user. An example of a role would be a member or system administrator. Once users have been authenticated (e.g., they exist in the security domain), they'll begin to access various resources while performing their business tasks. This will result in any number of security checks by the J2EE server against the credential (e.g., permissions) of the user with respect to the "role" the user assumed at login.

    The ability to perform object-level security (security on a per-user basis) is often required in sophisticated enterprise applications. However, role-based security is incapable of performing object-level security because roles relate to a "group" level rather than focusing on an individual. For instance, there's no way to ensure that the user "John Doe" can view/modify his own employee records, but not other employee records. You could declare that users in the department manager role can view/modify all employee records in their department, however. If your application requires object-level security, be sure to architect it into your solution.

  • Declarative Security
    The J2EE platform strives for portability across compliant servers. To this end, J2EE stresses the use of declarative security in Web applications (.wars) and EJBs, rather than promoting coding of security logic. Declarative security allows the J2EE server to intercept requests to access secured resources and perform authentication and authorization to use the service. No coding is involved on your behalf. However, the deployment of the component involves the extra step of determining which roles have the right to use a resource and then mapping these roles to the appropriate services.

Since mapping is performed at the deployment of the component, the component is portable across compliant J2EE servers such as WebLogic Server (www.bea.com) and iPlanet Application Server (www.iplanet.com).

Not only does J2EE support declarative security, it also provides an API into the security principals in the domain allowing programmatic checks. This feature is neither as portable, nor as configurable as declarative security, however, and should be used with caution.

Securing Web Resources
All J2EE products are required to support a single sign-on in the web tier, so you shouldn't have to log in multiple times for different applications on a site. Furthermore, it specifies that authentication occurs only if a user attempts to access restricted resources. This is described as "lazy authentication," which means you may freely access web-based resources if no security restrictions are placed on them. If you later attempt to access restricted portions of the site, the server must use one of three methods to authenticate the user:

  • HTTP basic authentication
    HTTP basic authentication is the security method supported by the HTTP protocol. This is the familiar browser pop-up window that requests a username and password. For instance, you may have encountered it the last time you tried to hack your friend's secured site. Upon receiving the username and password, the Web server authenticates the username against the security domain. Note that basic authentication is not a secure method of sending credentials. Adding SSL can alleviate this concern, but there's no control of the look and feel of the browser-generated pop-up window.
  • HTTPS Authentication
    HTTPS is HTTP over Secure Sockets Layer (SSL). SSL encrypts the data being sent between the client and the Web server using a "public/private" digital key scheme. This means that although someone may be able to intercept the data being transmitted, he or she will not be able to decrypt the information without the private key. This method of security is often used with applications that require credit card numbers, for example, purchasing a book at Amazon.com. This is all done automatically by the client and the server and doesn't require any input from you, the user.

  • Form-Based Login
    Form-based authentication allows developers to create customer login pages for their users. When you attempt to access restricted resources, the custom login page is displayed. The credentials you provide are sent back to the server (preferably over SSL) and verified against the domain. If you have authorization, you're granted access to the resource, otherwise, a custom "failed login" page is presented.

    For more information on web-based security, see the Servlet 2.2 specification. It can be downloaded at www.javasoft.com/products/servlet/download.html.

EJB Security
In the spirit of J2EE's declarative security, the EJB architecture discourages (but does not prevent) the practice of hard-coding security logic in EJBs. Instead, EJB's security model allows developers to place restrictions on bean methods contained within the remote and home interfaces through its deployment descriptor.

During the assembly of an EJB, the application assembler is responsible for defining security roles for an application. This entails bundling sets of permissions into logical groups that restrict component access at the method level. Next, the deployer is responsible for mapping the defined security roles to groups within the enterprise's security domain. In many cases, the same individual performs these two roles.

During method invocation on an EJB component, the container intercepts the method call, enforcing the security restrictions defined during deployment for the EJB. The EJB container will allow a user to execute a method only if the caller's principal is contained within one of the defined security roles. Furthermore, as EJBs invoke methods on other EJBs in the system, the security context is passed along to each component. While this enables seamless security checks across the EJB layer, there's a performance penalty encountered while checking security on each method call.

For more information on EJB security, see the EJB 1.1 specification. It can be downloaded at www.javasoft.com/products/ejb/docs.html.

J2EE Security: Putting It All Together
In the previous sections, we reviewed how each layer in a J2EE application can be secured, but how do web components and EJBs work together to provide a unified, single sign-on across all layers of your architecture? Figure 1 depicts a web client accessing restricted resources such as JSPs, servlets, and EJBs. As you can see, each layer in the J2EE architecture (Web server and EJB container) provides its own authentication against the security domain.

The web server first authenticates the user against the security domain, then confirms that the credentials supplied match to a principal (user) within the security domain. If the user doesn't exist, the authentication fails and the request for the specified resource is denied.

If authentication is successful, the server authorizes the request to access the secured resource, verifying that the user has been given adequate permission to use the resource. If the user has the required permissions for the resource, then the request is granted access to utilize its services; otherwise the server will deny the request. Notice that the credentials provided to the web server are propagated to the EJB, providing seamless integration. In both cases, the container will enforce the security restrictions based on the deployment descriptor for the component.

J2EE security can be used to secure resources in a portable fashion. Because it's declarative in nature, no coding is necessary to implement it in either the EJB layer or the web tier, providing transparent security for the developer. This keeps both your web component and EJB code focused on presentation or business logic, and enhances portability across different servers. Furthermore, it lets businesses use any type of data store as a security policy domain, allowing them to leverage any existing security implementations they currently have.

J2EE security was designed to provide a portable and flexible solution. however, it's important to be aware of some of the limitations. If your application(s) requires a very fine-grain level of security, you may need to add programmatic security. This obviously reduces the portability of your code and opens up possible security holes.

Next month in EJB Home, we'll walk through a sample application based on BEA's WebLogic Server that demonstrates the concepts described here. We'll create a relational database security domain, then construct a secured web-based application that communicates with EJBs. See you next month!

More Stories By Jason Westra

Jason Westra is the CTO of Verge Technologies Group, Inc. (www.vergecorp.com). Verge is a Boulder, CO based firm specializing in eBusiness solutions with Enterprise JavaBeans.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

IoT & Smart Cities Stories
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
The platform combines the strengths of Singtel's extensive, intelligent network capabilities with Microsoft's cloud expertise to create a unique solution that sets new standards for IoT applications," said Mr Diomedes Kastanis, Head of IoT at Singtel. "Our solution provides speed, transparency and flexibility, paving the way for a more pervasive use of IoT to accelerate enterprises' digitalisation efforts. AI-powered intelligent connectivity over Microsoft Azure will be the fastest connected pat...
As you know, enterprise IT conversation over the past year have often centered upon the open-source Kubernetes container orchestration system. In fact, Kubernetes has emerged as the key technology -- and even primary platform -- of cloud migrations for a wide variety of organizations. Kubernetes is critical to forward-looking enterprises that continue to push their IT infrastructures toward maximum functionality, scalability, and flexibility. As they do so, IT professionals are also embr...
CloudEXPO has been the M&A capital for Cloud companies for more than a decade with memorable acquisition news stories which came out of CloudEXPO expo floor. DevOpsSUMMIT New York faculty member Greg Bledsoe shared his views on IBM's Red Hat acquisition live from NASDAQ floor. Acquisition news was announced during CloudEXPO New York which took place November 12-13, 2019 in New York City.
In an age of borderless networks, security for the cloud and security for the corporate network can no longer be separated. Security teams are now presented with the challenge of monitoring and controlling access to these cloud environments, at the same time that developers quickly spin up new cloud instances and executives push forwards new initiatives. The vulnerabilities created by migration to the cloud, such as misconfigurations and compromised credentials, require that security teams t...
The graph represents a network of 1,329 Twitter users whose recent tweets contained "#DevOps", or who were replied to or mentioned in those tweets, taken from a data set limited to a maximum of 18,000 tweets. The network was obtained from Twitter on Thursday, 10 January 2019 at 23:50 UTC. The tweets in the network were tweeted over the 7-hour, 6-minute period from Thursday, 10 January 2019 at 16:29 UTC to Thursday, 10 January 2019 at 23:36 UTC. Additional tweets that were mentioned in this...
The term "digital transformation" (DX) is being used by everyone for just about any company initiative that involves technology, the web, ecommerce, software, or even customer experience. While the term has certainly turned into a buzzword with a lot of hype, the transition to a more connected, digital world is real and comes with real challenges. In his opening keynote, Four Essentials To Become DX Hero Status Now, Jonathan Hoppe, Co-Founder and CTO of Total Uptime Technologies, shared that ...
After years of investments and acquisitions, CloudBlue was created with the goal of building the world's only hyperscale digital platform with an increasingly infinite ecosystem and proven go-to-market services. The result? An unmatched platform that helps customers streamline cloud operations, save time and money, and revolutionize their businesses overnight. Today, the platform operates in more than 45 countries and powers more than 200 of the world's largest cloud marketplaces, managing mo...
When Enterprises started adopting Hadoop-based Big Data environments over the last ten years, they were mainly on-premise deployments. Organizations would spin up and manage large Hadoop clusters, where they would funnel exabytes or petabytes of unstructured data.However, over the last few years the economics of maintaining this enormous infrastructure compared with the elastic scalability of viable cloud options has changed this equation. The growth of cloud storage, cloud-managed big data e...
Your applications have evolved, your computing needs are changing, and your servers have become more and more dense. But your data center hasn't changed so you can't get the benefits of cheaper, better, smaller, faster... until now. Colovore is Silicon Valley's premier provider of high-density colocation solutions that are a perfect fit for companies operating modern, high-performance hardware. No other Bay Area colo provider can match our density, operating efficiency, and ease of scalability.