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:

• There should be a clean and elegant abstraction between security policy and business logic, which makes J2EE application security easier to deploy, manage, maintain, and modify as requirements change.

• There should be a simple declarative interface for managing security policies in real time, which makes security administration more efficient.

• The security framework delivered through an application infrastructure should enable cooperation with the rest of an organization's security ecology through a framework that can support a security vendor's full value proposition, not just a subset.

• The security framework delivered through an application infrastructure should provide unified protection for all container resources, for example JSPs, servlets, EJBs, J2CA adapters, Java Database Connectivity (JDBC) connection pools, and JMS destinations.

• The security framework delivered through an application infrastructure should comply with all the J2EE 1.3 security requirements, such as Java Authentication and Authorization Service (JAAS) for objects related to authentication and authorization, JSSE for communication using Secure Sockets Layer (SSL) and Transport Layer Security (TLS), and the SecurityManager class for code-level security.

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.

Note

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 :

• Using the out-of-the-box BEA-supplied security plug-ins.

  Note

  WebLogic Server 7 provides prebuilt implementations (security service plug-ins) for most plug-in points.

  
  

• Using third-party security plug-ins based on the BEA Security SPI interface.

• Using the BEA Security SPIs to create customized security plug-ins for WebLogic Server systems.

• Adapting existing third-party security technologies so that they are BEA-compliant.

With this new WebLogic Server SPI approach to implementing security, the following is possible:

• Security solutions can be mixed and matched to create end-to-end custom security solutions for WebLogic Server “hosted applications, from the mainframe to the Web browser.

• Multiple plug-ins for a given security function can be leveraged, and constraints can be set that govern which product or protocol is used in a given situation.

• Security plug-ins can be swapped, as required, which enables organizations to

  • Not be bound to non-evolving vendor security solutions because security infrastructures can change over time to meet organizations' requirements.

  • Reduce their total cost of ownership.

  • Maximize their return on investment in security infrastructure.

  • Possess substantial technical agility in utilizing their security infrastructures.

• The WebLogic Administration Console can be used to provide a unified management interface for administering security rules, security policies, and security providers.

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.

• The container serves as the security policy enforcement point.

• The security service serves as the security policy decision point.

• The J2EE object executes business logic.

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.

The Firewall

A firewall is typically a hardware appliance used for the following:

• Instituting a secure access policy for crossing a network's perimeter. For example, allowing only authorized traffic to pass from an untrusted network environment, such as the Internet, to a DMZ.

• Protecting the Web server from malicious attacks, such as Denial of Service (DoS) attacks and widespread outbreaks of increasingly sophisticated and damaging viruses, such as Nimda, Code Red, and Love Bug.

• Performing Network Address Translation (NAT), which hides Web server addresses in the DMZ from the Internet. For example, from the Internet the Web server's address might appear to be 202.123.64.55, but the DMZ network sees the Web server at address 10.9.8.1. Hence, NAT also allows the Web server to differentiate between inbound requests from the Internet and requests from the internal network.

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.

Tip

You can also use WebLogic Server as a Web Proxy server by deploying HttpClusterServlet .

Connection Filters

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.

Note

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:

• Common Name ” Abbreviated as cn, usually consists of the user 's first name and last name.

• Organizational Unit ” Abbreviated as ou, often a department name.

• Organization ” Abbreviated as o, usually the business owning the Organizational Unit.

• Country ” Abbreviated as c.

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 LDAP directory provides a single registry for defining and storing a user community.

• Users defined in the LDAP directory can have mappings to identities on multiple platforms. For example, LDAP can be used to unify both Windows and Unix user and group information.

• LDAP provides abstraction for users in the enterprise network, which implies that user identities are passed to application servers in the same format, regardless of the platform origin or destination.

• LDAP directories can be replicated across multiple servers, supporting load-balancing and high availability efforts.

• LDAP uses TCP/IP for communication and can also be configured to run over SSL for secure communications.

• LDAP provides a single authentication point for users, which is a modular approach to upgrading security infrastructure.

The following vendors provide LDAP-compliant directory servers:

• IBM ” IBM Directory Server

• Microsoft ” Active Directory Server

• Nexor Inc . ” Nexor Directory

• Novell ” eDirectory

• Oracle ” Oracle Internet Directory Server

• Sun ” Sun ONE Directory Server 5.1