BEA WebLogic Enterprise Security 4.1 offers a new, integrated approach to addressing the distributed application security problem found with enterprise applications.

With this new distributed, infrastructure-based approach, application security becomes a function of the application infrastructure and is separate from the application itself. Any distributed application deployed using BEA WebLogic Enterprise Security can be secured either through the security features included out of the box, or by plugging in other specialized security solutions from major security vendors that the customer's enterprise standardizes on.

This article defines the major requirements for a distributed application security solution, and explains how WebLogic Enterprise Security 4.1 delivers them to your application.

Introduction
The introduction of Web-based applications, component-based architectures such as J2EE, and now service-based architectures, has brought about a change in how applications are created. Where once an application would be constructed as a single entity containing both business logic and a set of embedded security mechanisms, applications are now constructed by integrating a number of applications that provide services to other components in a distributed environment.

But as these highly distributed applications proliferate, the ability to secure these applications from malicious use from outsiders as well as control the actions of insiders continues to present a critical challenge. A notable effect of this style of application construction is that the number of potential entry points into the application that could be leveraged for malicious activities increases significantly. With the various components of the application distributed throughout the enterprise and even perhaps across enterprise boundaries, the traditional approach of securing an application at only its perimeter is no longer effective. Security enforced only at the perimeter leaves gaps that can be easily exploited by malicious insiders and results in individual silos of security enforcement at almost every component of the application.

Taming this challenge requires a solution that flexibly stitches the existing application fabric to the existing security foundation, while enabling the efficient administration of policies that govern access to business functions. Application security is not static. Administrators need the power to respond to evolving computing technologies and ever-changing threat environments. They must be able to determine the security posture of every single component executing business functions for which they are responsible. They must be able to update this posture by altering the use of various security technologies or changing the policies governing access to resources. Only by addressing the needs for comprehensive security integration, encapsulated policy enforcement, and responsive administration can an application security solution meet both goals.

Reducing the onerous burden requires two separate innovations: service-based security and unified distributed administration. A service-based security layer offers a universal security abstraction for application containers on one side and pluggable provider interfaces for security solutions on the other side. Of course, such flexibility could create its own set of problems surrounding the configuration of service bindings and maintenance of consistent polices. Avoiding this issue with unified administration requires a robust paradigm for synchronizing, propagating, and analyzing administrative directives.

BEA WebLogic Enterprise Security is the first solution to deliver these two innovations in a single, comprehensive package. It doesn't require enterprises to replace existing application containers or existing security solutions. What it does is allow enterprises to weave these existing components into a seamless whole that is easy to manage, maintain, and extend. For the first time, an information technology organization can have complete visibility into and control over every aspect of security for every business function supported by its applications.

Designed as a security infrastructure for providing security services in a consistent and uniform approach to application containers throughout an enterprise, WebLogic Enterprise Security leverages many of the lessons learned from successful distributed systems while focusing on the reliability, availability, scalability, and performance. In addition, WebLogic Enterprise Security is well suited for environments where an application server decision has not been made. Unlike a number of other products, it does not require customers to utilize any of the components of the BEA WebLogic Platform suite and can be used in environments where these components don't exist (see Figure 1).

One major difference between BEA WebLogic Enterprise Security and other security solutions is the use of a distributed infrastructure that allows for decision points to be colocated with the resources that are being protected. Instead of a central security server where policy decisions are determined, WebLogic Enterprise Security uses a patented approach for distributing configuration and policy information to the decision points that are colocated with the resources that are to be protected. Doing this avoids the performance degradation associated with the latency of network calls to a central decision point, and provides better reliability and availability since there is no runtime dependency on an external process that must be operational and responsive.

At the heart of the WebLogic Enterprise Security infrastructure is a sophisticated security framework known as the "BEA Security Framework", the same one found in BEA WebLogic Server. This allows security services developed for use with WebLogic Server to be utilized by WebLogic Enterprise Security throughout the enterprise. In addition, the use of a common security infrastructure provides customers with a single, unified approach to application security whether or not they use the BEA WebLogic Platform suite.

Service-Oriented Security
The WebLogic Enterprise Security approach is to simplify the integration of application containers with security solutions. An application container is the runtime infrastructure that supports the execution of components. Web servers may act as containers for CGI, JSP, or ASP components. Application servers may act as containers for J2EE and .NET components. Packaged applications act as the containers for the business functions they provide. Stand-alone programs in languages such as Java or C must act as their own containers. Web services may run on top of frameworks, in which case the framework is the container, or as stand alone components, in which case they are like other stand-alone programs. Application components already delegate security functions to the container and WebLogic Enterprise Security takes this process one step further by having the container delegate security functions to it.

In principle, every instance of a particular type of container can use the same integration interface, saving a great deal of time and effort. In practice, the situation is actually even better because the model for this interface can be the same across all container types. There are three primary kinds of information any type of security function might need from a container: the security context of the request, such as the username and password or any embedded security tokens; the identity of the resource that is the target of the request, such as the "change address" method of the "Customer" object in the "Accounts Receivable" application; and optionally the context of the request, such as the request parameters that represent the particular address and the particular customer. These three categories of information are the same for all possible containers and all possible security functions. It's simply a matter of encoding them according to the conventions of each type of container and dispatching the appropriate pieces of data to each security function in the correct order.

Figure 2 illustrates this approach. When a container receives a request on a protected resource, it makes a call to the universal security abstraction. This abstraction then invokes all the necessary individual security services, shielding the container and the component from the details. The container receives a decision indicating whether it should deny or fulfill the request.

The goal of BEA WebLogic Enterprise Security is to make integration with applications as easy as possible. In cases where applications already execute in a container-like abstraction, it may be possible to provide shrink-wrapped integration. Containers that provide open mechanisms for extending the container where security decisions can be interposed in the normal flow of handling a business request, such as a Web server's plug-in mechanism, can be used to integrate with WebLogic Enterprise Security. In its initial release, WebLogic Enterprise Security provides packaged integration for a number of containers, including BEA WebLogic Server and the Netscape/Sun ONE Web Server.

In the case of stand-alone applications, each application must individually call the WebLogic Enterprise Security API. For existing applications, there are a variety of straightforward techniques developers can use to add this delegation. Depending on the internal architecture, such techniques include using interceptors, changing the dispatch function, or creating proxy objects. For new applications, developers can create a mini-container abstraction that intercepts requests, calls WebLogic Enterprise Security and acts on the results. While these techniques all require some additional programming, this effort will be repaid many times over by eliminating the burden of maintaining all the embedded security code.

Service Provider Integration
After BEA WebLogic Enterprise Security receives a request from an application container, it manages security processing through a sophisticated internal framework. This security framework is the same framework used in BEA WebLogic Server. The first important point to note about this framework is that every step must pass through an auditing phase that generates a comprehensive set of events for the execution of that step. By filtering and capturing these events, an auditing provider can create as fine grained a log as necessary to comply with enterprise policies. The second important point to note is that security processing is a pipeline. Security functions follow a natural order, with downstream steps requiring the results from upstream steps. The requester's identity must be established before deciding whether to grant that identity access to a resource. Determining what roles an identity currently fulfills must occur before evaluating whether one of those roles authorizes it to perform a particular action on a resource. Within the logical processing order, this processing is very flexible. If a whole new category of security function emerges, WebLogic Enterprise Security can transparently enable it for all application containers by inserting it into its proper place in the pipeline.

For each step defined in the pipeline, WebLogic Enterprise Security invokes the service provider designated to handle that step. As shown in Figure 3, each security service has a corresponding Service Provider Interface (SPI) that defines the functions that security providers providing the service must support. To plug into WebLogic Enterprise Security, a security solution simply has to offer implementations of the SPI for services it knows how to provide. In many cases, these interfaces will consist simply of a wrapper around existing client libraries provided by the solution vendor. By taking advantage of WebLogic Enterprise Security's universal security abstraction, enterprises can transparently and efficiently switch to alternative services providers, upgrade to new versions of existing providers, or even implement their own custom providers to handle special cases.

Out of the box, WebLogic Enterprise Security includes security service providers for a security service that simply use the framework SPIs. Other implementations of a security service can be created and integrated to the facilities of the underlying framework through the same SPIs. These clean SPIs make it possible to plug and unplug different security providers as the security ecology evolves, benefiting everyone involved. Although BEA can individually upgrade the providers included with WebLogic Enterprise Security, security vendors can easily make their services available to all supported containers by coding their products to the appropriate SPIs. Moreover, enterprises can quickly implement customized security processing where necessary.

BEA WebLogic Enterprise Security Architecture
Security Service Modules
The pieces of WebLogic Enterprise Security that provide a universal security abstraction are called Security Service Modules (SSMs). An SSM instance includes the interface to the container, the security framework, and all the service providers configured for that instance. Each SSM instance supports a container instance (see Figure 4).

Every SSM requires configuration of its service providers and their corresponding policy information. An initial configuration occurs upon installation and enrollment of the SSM with the administration server, but updates then occur as service providers change and policies evolve. With perhaps a hundred different server machines involved in the execution of some applications, each with multiple instances of containers, the need for a sophisticated approach to administration is pretty clear.

Service Control Modules
The first point of sophistication is the aggregation of administrative operations across multiple instances on the same machine. In most enterprise architectures, it is quite common to run multiple instances of a Web or an application server on the same machine. In some cases, particularly powerful servers may run instances of different types of containers on the same machine. Obviously, if every instance communicated directly with the administrative system there would be a lot of duplicative resource consumption on that machine. Moreover, many types of containers allow administrators to dynamically create and destroy instances so WebLogic Enterprise Security needs a means to control the creation and destruction of corresponding SSM instances. Therefore, every machine on which SSMs may run has a Service Control Module (SCM) as shown in Figure 5.

Administration Server
BEA WebLogic Enterprise Security maintains named configurations in the administration server. In addition to the service providers assigned to the configuration, it maintains a hierarchy of all protected resources managed by that configuration. This hierarchy can include levels for groups of applications, applications, components, objects, and methods so policies can apply to any level of this tree. Resources inherit policies from their ancestors in this tree, though administrators can override this inheritance. All of this configuration, resource, and policy information resides in the policy store, which can be an Oracle or Sybase database. This policy store also maintains information about administrative roles and privileges. WebLogic Enterprise Security has an administrative resource tree that it protects just like application resources. The tree has four main branches: (1) operations on users and groups; (2) operations on policies for role assignment and authorization; (3) operations on protected resource definitions; and (4) operations on service provider configurations. Each of these branches is further divided. Branch 1 has subdivisions corresponding to the user and group hierarchy. Branches 2 and 3 have subdivisions corresponding to the resource tree. Branch 4 has subdivisions corresponding to the configuration tree. An individual administrator may be assigned create, read, update, or delete privileges for any set of branches of this resource hierarchy. In addition to this flexibility in compartmentalization, WebLogic Enterprise Security offers other features for administration.

Conclusion
BEA WebLogic Enterprise Security doesn't impose a rigid security model on enterprises that hinders the integration of application components with security services and forces the costly workaround of mixing security code with business logic. Instead, it delivers an open framework, common throughout BEA's application platform suite, so that components running on existing application platforms can seamlessly cooperate with the existing security ecology. This framework eliminates dependencies between application components and security services - new application components can seamlessly utilize existing security services and new security services can seamlessly support existing application components. This capability reduces the life-cycle cost of securing existing application components with existing security services.

By embracing the principles of distributed computing, WebLogic Enterprise Security preserves flexibility without sacrificing control. Its innovative administrative model enables enterprises to have complete visibility into and control over the security configuration of every application component as well as the specific policies used to control access to business functions. They can administer security from a single location, propagating both configuration and policy changes throughout the distributed application fabric. This capability enables better assessment and mitigation of security risks.

In addition to supporting existing security services, WebLogic Enterprise Security offers groundbreaking role mapping and authorization services that make it easy to untangle security code from business logic. Because they offer an unprecedented level of flexibility in evaluating the context of a request, enterprises don't have to mix security code with business logic to achieve policy enforcement. This capability decreases the cost of maintaining applications and enables more responsive risk management. It is representative of BEA WebLogic Enterprise Security's overriding goal - to increase IT efficiency and improve system security while supporting business objectives by embracing business procedures rather than constraining them.