An Introduction to the WebLogic Server Security Service
WebLogic Server 7 provides a new flexible, extensible, and open security architecture, which has been derived from the following security industry trends and best practices:
In essence, WebLogic Server promotes having security enforcement performed outside the application by providing essential integration or plug-in points. These plug-in points provide an efficient mechanism to integrate best-of-breed security solutions and a means to replace security system components with the latest technologies.
This security plug-in scheme is based on a set of Security Service Provider Interfaces ( SPIs ) for plug-in points. The current Security SPIs available for WebLogic Server include Authentication, Authorization, Auditing, Credential Mapping, Role Mapping, and Public Key Infrastructure, which supports the Java-standard keystore for encrypted storage of public and private encryption keys.
Security providers are modules that provide security services to applications hosted on WebLogic Server.
The Security SPI scheme implies that customers have four choices for securing WebLogic Server installations, as follows :
With this new WebLogic Server SPI approach to implementing security, the following is possible:
The following section describes how WebLogic Server can be leveraged to provide security to J2EE applications.
A Basic Security Setup Using the WebLogic Server Security Service
WebLogic Server, as illustrated in Figure 26.1, receives inbound requests and directs them to the appropriate J2EE container ”Web or EJB. After the container receives a request targeted at an object it contains, it delegates the complete request and its entire context to the security service. The framework returns a yes or no decision on whether to grant the request. This approach takes business logic out of the security equation by providing the same information to the security system that is available to the target object. They each use this information to fulfill their dedicated responsibility:
Figure 26.1. A basic security setup for WebLogic Server.
As illustrated in Figure 26.1, a basic security setup of J2EE applications deployed to WebLogic Server 7 can also include the elements described in the following sections.
The Demilitarized Zone
The demilitarized zone ( DMZ , as it's known in the network community) is a perimeter network used to protect a specific trusted network environment from direct exposure to an untrusted (external network) environment. To define a DMZ, you first must identify the network environment you need to protect and then identify all the entrance points (front and back doors) to that network. In most cases, the entrance point is a Web server connected to the Internet or an untrusted intranet.
A firewall is typically a hardware appliance used for the following:
The Web Server
A Web server can be leveraged to serve a J2EE application's static content. Dynamic content requests to servlets or JSPs are delegated via the Web server's proxy plug-in to WebLogic Server. Using a Web Proxy server does have its advantages, as you can leverage existing infrastructure and any firewall policies for the Web tier , which prevents direct connections to WebLogic Server.
You can also use WebLogic Server as a Web Proxy server by deploying HttpClusterServlet .
Connection filters are a type of firewall that WebLogic Server can be configured to use. They can be configured to accept or deny incoming connection requests from a network client based on the origin of the request or the type of connection protocol used. For example, you can ensure that all access to the WebLogic Server application is secure from the Internet by denying any non-SSL connections originating from outside your corporate network.
Connection filters can be used to protect server resources on individual servers, server clusters, or an entire internal network (intranet), hence providing another layer of security.
Lightweight Directory Access Protocol
Lightweight Directory Access Protocol ( LDAP ) is a standardized protocol, derived from X.500, for building, accessing, and managing a hierarchical database. A hierarchical structure is especially useful for storing identities, access groups, or roles for the purposes of authentication. LDAP was originally created to be a trimmed -down, lower-overhead version of the international X.500 directory protocol standard.
Within the context of a LDAP registry, identities (users) are defined as a Distinguished Name ( DN ), which is a compound definition composed of the following elements:
Each element represents a branch of a tree, with the Common Name being the leaf. For example, Figure 26.2 represents the LDAP structure for the DN composed of cn=Admin, ou=Research, o=Objectmind, and c=US.
Figure 26.2. An example of an LDAP structure.
For the following reasons, LDAP is an appealing identity management directory choice for organizations wanting to consolidate their user, group , and role information at a corporate level:
The following vendors provide LDAP-compliant directory servers: