Welcome!

Weblogic Authors: Mark O'Neill, Chris Muir, Roger Strukhoff, Michael Sheehan

Related Topics: Weblogic, Security

Weblogic: Article

Security Integration with WebLogic J2EE: Making It EASI

Security Integration with WebLogic J2EE: Making It EASI

The rise in popularity of Web services is breaking down barriers and obliterating isolated silos everywhere. That's good news for any organization looking to make e-business the normal way of doing business with customers, colleagues, and partners. Of course, with every falling barrier comes a new set of challenges around the issue of security. In this article, I'll review the challenges of security integration with WebLogic J2EE applications in a distributed environment - and how they can be addressed with an Enterprise Application Security Integration (EASI) framework based on Web-centric industry standards.

The Challenge of Distributed Security
First, let's agree on the two high-level goals of any security infrastructure in a distributed environment: to limit access to applications, data, and other resources to only those with proper authorization; and to make accessing those resources by authorized parties as easy as possible. Meeting both of these goals can be complicated.

In a typical WebLogic implementation, at the front-end, or perimeter, tier, we often have Microsoft IIS (Internet Information Server) serving Web pages and providing a first line of security. IIS authenticates users by accessing user profile information, including group privilege attributes, residing in Microsoft ADS (Active Directory Service). At the application tier, we have WebLogic J2EE applications. These provide user authorization based on user roles, residing in WebLogic repositories as EJBs. These WebLogic applications, in turn, interact with mainframe and other enterprise systems in the back-office tier. In addition, most organizations have legacy security infrastructures composed of point solutions that provide protection for specific systems or applications.

In addition to the basic challenges of interoperation, such an architecture presents a major maintenance headache. IT must manage two sets of user/group authentication data - one for IIS ADS and the other for WebLogic repositories - to ensure they "map" to each other. This task is multiplied when other domains are involved. And it's further complicated by the fact that IIS attributes and WebLogic roles are arranged according to different hierarchies.

Single Sign-on (SSO), with which a user can log in once and gain access to all authorized resources, is an important feature from the user's point of view. Proper implementation of SSO in distributed environments can be extremely complex. One workaround is to send a user's password from IIS along to WebLogic applications, legacy security solutions, and, in some cases, even back-end systems. This is considered poor security practice, introducing the potential for breaches. And it can diminish system performance, forcing users to wait longer for authentication.

Three Common Options
Under pressure to put new applications into production, IT groups facing these challenges have several options. First, they can disable the security facility built into WebLogic and rely on IIS perimeter security alone. This eliminates the need to map the two user repositories, but it greatly diminishes control over access. IIS does not provide very granular access control. And it isn't known for its robustness - it's certainly not the single line of defense one wants in today's hacker-rich environment.

Another option is to disable IIS perimeter security and rely solely on WebLogic for access control. This approach leaves the front end unprotected, eliminating the critical screening that IIS performs. Web pages become vulnerable to defacement, and sensitive content is no longer properly protected against unauthorized access. Again, not a good option.

The third option is to bite the bullet and try to get IIS and WebLogic to interoperate. As already explained, this raises a host of integration issues associated with getting two dissimilar repositories of user data to communicate. This is typically a costly, proprietary, and very complicated alternative.

A New Option: Unified Security
So how can IT groups bridge the gap between the Microsoft world (ADS) and the WebLogic world (Java/EJB) to achieve seamless security interoperation in such a distributed environment?

The answer lies in a standards-based Enterprise Application Security Integration (EASI) framework (see Figure 1) that can map user/group attribute and authentication information among IIS, WebLogic, back-end systems, and standards-based legacy security services. The result is a unified, "pluggable" security infrastructure that strengthens security, while streamlining secure access and greatly simplifying security administration and system evolution.

This security framework divides the world into security consumers and security providers using a variety of code types (see Figure 2). Security consumers make requests to authenticate a principal, to obtain privilege attributes, or to authorize access to a protected resource. Security providers process authentication, attribute, and authorization requests according to the particular technology upon which the provider is based. The security framework connects security consumers, using adapters, with security providers, via mappers. The framework controls the selection of which mapper to use to satisfy a request from a given adapter. The "pluggability" of this architecture arises from the fact that the framework can be configured to use any mapper to process a request from any adapter. Figure 3 shows the basic elements of this EASI architecture. While an EASI framework leverages a number of open industry standards (such as XML and SOAP), key to its effectiveness is its use of standards arising from the OASIS SAML (Security Assertion Markup Language) initiative. SAML assertions provide a standardized way to represent user and/or group security statements and security requests. SSL, digital signatures, and other cryptography technologies are used to secure communications within the framework.

With this framework, developers have the flexible tool they need to knit together their entire distributed-security infrastructure - overcoming the differences among IIS, WebLogic applications, back-end systems, and their associated repositories. It can dramatically reduce the cost and time required to implement a WebLogic environment, including multidomain environments, while enhancing security effectiveness. It greatly simplifies the administration and maintenance of that distributed environment, as well as the task of integrating new applications, technologies, and security services, such as the new Security Service Provider Interfaces (SSPI) introduced in WebLogic 7.

More Stories By Sean Dolan

Sean Dolan is a security architect at Quadrasis (Quadrasis, is a business unit of Hitachi Computer Products (America), Inc). He has 16 years of experience in commercial and scientific systems and application software development, including experience architecting approaches to the integration of J2EE Application Server products into enterprise security frameworks. As a member of the Sun Java Community Process (JCP) program he has participated in the definition of a number of J2EE security-related specifications.

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.