Overview of the WebLogic Security Service

While other security documents in the WebLogic Server documentation set guide users through a specific job task—such as developing a custom security provider or managing the WebLogic Security Service—this Introduction is intended for all users of the WebLogic Security Service. This document summarizes the features of the WebLogic Security Service, presents an overview of the architecture and capabilities of the WebLogic Security Service, and defines WebLogic Server security terms. It is the starting point for understanding the WebLogic Security Service.

The following sections introduce the WebLogic Security Service and its features:

Installing and maintaining security is a huge challenge for an IT organization that is providing new and expanded service to customers using the Web. To serve a worldwide network of Web-based users, the IT organization must address the fundamental issues of maintaining the confidentiality, integrity and availability of the system and its data. Challenges to security involve every component of the system, from the network itself to the individual client machines. Security across the infrastructure is a complex business that requires vigilance as well as established and well-communicated security policies and procedures.

This document focuses on securing the Web application component of an enterprise system—the Java-based application and the BEA WebLogic Server on which it is deployed. This release of WebLogic Server incorporates a completely redesigned security architecture that provides a unique and secure foundation for Web applications. By taking advantage of these new features in WebLogic Server, applications benefit from a comprehensive, flexible security infrastructure designed to address the security challenges of Web applications. BEA WebLogic Server security services can be used standalone to secure WebLogic Server applications or as part of an enterprise-wide security management system that represents a best-in-breed third-party security management solution.

BEA WebLogic Server security provides the following benefits to help solve the practical dilemmas that information technology (IT) departments face when installing and maintaining Web applications:

With an open architecture, standard interfaces, and unified administration, BEA WebLogic Server security gives the IT department the tools it needs to address real-world issues in security. BEA WebLogic Server's new security architecture provides essential integration or "plug-in" points that allow best-in-breed solutions to be provided by commercial security vendors or customers themselves. In addition, BEA WebLogic Server provides pre-built implementations (WebLogic security provider plug-ins) for most of these plug-in points.

The security services design for BEA WebLogic Server sets a new standard for security architecture in application servers. The new security services offer a carefully crafted, unified approach for security that is:

The components and services of the WebLogic Server security system seek to strike a balance between ease of use (for end users and for administrators) and customizability (for application developers and for security service providers).

Easy to use: For the end user, a secure BEA WebLogic Server environment requires only a single sign-on for user authentication (ascertaining the user's identity). Users do not have to re-authenticate within the boundaries of the WebLogic Server domain that contains application resources. Single sign-on allows users to log on to the domain once per session rather than requiring them to log on to each resource or application separately. Single sign-on is automatically available to BEA WebLogic Server applications, without additional programming.

Manageable: Administrators who configure, install, and deploy applications to the BEA WebLogic Server environment can use the BEA-supplied security plug-ins that support all required security functions, out of the box. The administrator can store authorization and security policy information in the WebLogic Server-supplied security store (an embedded, special-purpose LDAP directory server). Existing external security stores such as Lightweight Directory Access Protocol (LDAP) servers can also be used with the WebLogic environment. Native, third party, and customized security services can all be integrated into the WebLogic Server management environment, so that configuration and management of all security solutions can be done through the WebLogic Server Administration Console.

Customizable: For application developers, BEA WebLogic Server supports the WebLogic Security API and J2EE security standards such as JAAS and JSSE, for creating a fine-grained and customized security environment for applications that connect to WebLogic Server.

For security-specific application developers and third-party providers of security service technology, WebLogic Server Security Service Provider Interfaces (SSPIs) support both the development of new security plug-ins for the WebLogic Server environment, and interconnection of third-party services to the BEA-supplied security plug-ins.

In BEA WebLogic Server, the Web Services run-time is tightly integrated with the WebLogic Server Security framework. As with securing Web clients, specifying SSL security for BEA Web Services requires only a simple modification to the Web Services deployment descriptor, web-services.xml. In addition, the Administration Console has a special Web Services Components deployment node so that an Administrator can perform standard administration tasks, including security tasks, on Web Services components. Administrators can configure user authentication and service authorization using the same facilities they use to configure security for other server components.

BEA provides confidentiality for Web Services via the SSL (Secure Sockets Layer) protocol for assuring security between two hosts connected on an insecure network. In addition to server-side support, BEA provides a Web Services client with an integrated SSL implementation. Alternatively, developers can plug-in their own SSL implementation via a public API.

Within the Web Services framework, BEA provides the architecture for pluggable handlers on both the client and the server implementations. These handlers can be used to moderate Web Service transactions and provide additional functionality such as message level encryption, digital signatures, and token-based authentication.

The key to the BEA WebLogic Server security architecture is the organization of application users into users and groups that take on roles according to defined security policies. Users can be organized into groups. Groups can be used to represent organizational boundaries as well as to simplify administration. Each application user and group is mapped to a role dynamically during application execution, when authorization is needed.

Roles and policies determine access to system resources, and permitted behaviors. User roles are registered by an administrator using the built-in menu-driven security policy tool embedded in the BEA-supplied Authorization plug-in. The security policy tool's interface reflects business concepts, not programming concepts, and allows an administrator to create simple prose-based rules for dynamically assigning roles and calculating access privileges. Application developers are freed from having to write application code to implement complex business policies, because the policy tool separates the tasks of business policy creation and application creation.

The roles that a user can be assigned to are determined by policies defined by the administrator, on behalf of the company. Since policies reflect business security rules, a company's management sets security policies rather than the software development staff. Security policies can easily be changed with changes in business conditions.

The role-and-policy-based security scheme replaces the previous scheme of users, groups, and access control lists (ACLs), and offers clear advantages for ease of administration and ease of adaptability as security requirements change. Using roles and policies for authorization permits dynamic computation of access status for each resource, for each user or group.

The WebLogic Server dynamic, role-based authorization scheme can be applied to all WebLogic Server resources. The administrator and applications developer are no longer constrained by the limitations of the declarative security model in J2EE, which embeds security constraints in the code and makes it difficult to modify a security scheme when business requirements change.

Here are some details on how BEA WebLogic Server implements the primary task areas of a security system, which are authentication (determining a user's identity as a valid user) and authorization (determining a user's role or roles and computing the appropriate access privileges based on the policies in place).

Authentication is the process of ascertaining that a user requesting system services is a valid user. BEA WebLogic Server builds upon the authentication classes of the Java Authentication and Authorization Service (JAAS), which is a standard extension to the security in the Java Software Development Kit, version 1.3. The JAAS standard provides the support needed to submit a username and credential (password or digital certificate) when authenticating a user to WebLogic Server. BEA WebLogic Server goes beyond this by providing a link to legacy systems so a particular system's authentication credentials can be transparently used by WebLogic Server.

In addition, the new architecture supports perimeter authentication via Web server, firewall, or Virtual Private Network (VPN). Multiple "security token types" are possible (e.g. Liberty token types, or Microsoft Passport^TM, or SAML Assertions). Perimeter authentication is supported by multiple protocols, such as HTTP, and IIOP-CSIv2.

The WebLogic Server authentication scheme is flexible enough to benefit developers who have special security situations. By using and extending classes and configurations provided, developers can link to multiple authentication and authorization stores. Examples of connectivity include NT domains, LDAP directories, and Unix security services. For example, an organization might prefer to use the execute permissions associated with a Unix file system for a set of servlets stored on the Unix machine. To enable this, WebLogic Server can defer authentication of users to Unix, and reflect access control to Unix files in Java.

Since security requirements vary greatly, the server is easily configurable to allow different levels of authentication depending upon the needs of the deployment. When a client, administrator, or peer wants to access a WebLogic Server resource, it may be necessary to authenticate identities. BEA WebLogic Server supports two default mechanisms for authenticating users: passwords and digital certificates.

For minimal security, password-based authentication allows users to enter a username and password to authenticate themselves when requesting access to a given resource on the server. This is the basic authentication scheme defined in the HTTP protocol. This basic authentication is very easy to implement and manage, but provides limited security because passwords provide a weak form of authentication.

For stronger authentication, cryptographic authentication is supported in the form of digital certificates. These certificates are issued from a trusted third-party called a Certificate Authority (CA). A CA issues certificates that can be used to prove the identity of servers or users. BEA WebLogic Server does not restrict the number of CAs or the number of levels in a certificate chain. This provides more flexibility in business-to-business applications that require longer CA chains.

Authentication via digital certificates is the key to authentication using the Secure Sockets Layer (SSL) security protocol, which is supported by WebLogic Server. BEA WebLogic Server is compatible with the X.509v3 international digital certificate standard. This compatibility allows use of certificates from any CA that supports this standard. For mutual authentication, both the client and server must present a certificate before the connection is enabled between the two. When mutual authentication is used, the identity from the certificate can be mapped to a WebLogic Server user identity through a customization point called certificate authenticator that is registered with an Identity Asserter.

BEA WebLogic Server provides full-strength, 128-bit encryption for customers in the United States and Canada, and international customers that are allowed full-strength encryption by U.S. trade laws. A 56-bit encryption scheme is compatible with "low-strength" encryption, allowing universal compatibility. For this compatibility, WebLogic Server generates a temporary low-strength key for that connection.

Authorization determines what a user is allowed to do, using security roles and policies. Each user is assigned one or more roles, dynamically during application execution. Roles can be implemented as an identity, or as a named collection of permissions. Role assignments are dynamically computed according to security policies, set by the administrator using the BEA WebLogic Server Policy tool, as the user seeks to access various resources. With this release of WebLogic Server, Access Control Lists (ACLs) have been deprecated, and have been replaced by security policies.

The security roles and policies determine the level of access a particular user has to resources hosted on BEA WebLogic Server, for example:

Authorization and role assignments are delegated to the security service from the WebLogic Server container. This allows integration of external plug-ins and provides a unified authorization approach to all resources. The tight coupling between implementations of roles and access decisions allows for authorization decisions and role assignments to be based on context, which supports more "real life" conditions of doing business.

It is often necessary for security policies to be changed dynamically as new users are added and situations change. To accommodate this, BEA WebLogic Server can dynamically update users and roles by leveraging an external, centralized security database or service, such as LDAP (or by using the embedded LDAP directory server that has been customized for use by WebLogic Server).

In previous versions of WebLogic Server, user roles were defined exclusively in J2EE Deployment Descriptors. Changing these static role assignments required editing and updating Deployment Descriptors. The new architecture supports a comprehensive scheme that consumes all previous definitions and assignments, and lets administrators use the Administration Console to manage role definitions and assignments without editing deployment descriptors. This separation of the security of the application from the business logic simplifies security management.

Role definitions are specific to a unified security realm that represents the broadest policy scope to which security policies apply (e.g., the entire company, the company's Western Division, the company's Pacific Rim branch). Roles can be defined as scoped—associated with given resources; or global—associated with all resources. Roles can be assigned statically for specified users or groups at administration time, or dynamically, based on the context of the request at run-time.

The built-in Policy engine provides a GUI interface that lets Administrators set policies in the Administration Console—without writing application code. By right clicking on the system resource displayed in the Administration Console, users can select among the constraints displayed on the drop-down menus.

Figure 3 illustrates this simple menu-based approach to adding or changing security in applications.

BEA WebLogic Server can be configured to allow administrators to construct security audits for their systems. Administrators can configure the audit to detect and log authentication attempts, access attempts, and other significant security events. Administrators can use the BEA-supplied Auditing provider plug-in, which creates a log entry for access failures. More sophisticated auditing schemes can be implemented using custom Auditing providers or third-party auditing tools. As with the other security tools, administrators can have multiple Auditing provider plug-ins in place, and set various conditions for their use. This offers administrators fine-grained control over when and whether to take action on an event.

BEA WebLogic Server also provides administrator control over permissions to establish a connection to the server. The Connection Filter feature allows enforcement of rules that govern whether a connection should be established based on client IP access or protocol. This capability can be used to restrict the location from which connections to the application server are made, enhancing security of the application. Connection Filter features are configurable from the Administration Console.

In enterprise applications, denial-of-service and other attacks can render significant damage. The BEA WebLogic Server is designed to prevent certain forms of denial-of-service attacks. From the Administration Console, the administrator can set timeouts and other parameters that will counteract attempts to attack the integrity and availability of the application running on WebLogic Server. In addition, BEA WebLogic Server provides measures to counter both online and offline guessing of users and passwords. Offline protection for passwords is protected through use of encryption and other security techniques specifically targeted to counter brute force and dictionary attacks. Counter measures for online password guessing include the ability for administrators to control the number of times a login attempt can fail within a given period of time before the account is disabled or locked-out.

BEA WebLogic Server supports unified administration of security services through the Administration Console, for third-party and customized security services, as well as for BEA implementations. The Administration Console is a security command center, providing tools for functions such as the Role Mapper, the Auditor, the Authenticator, the Authorizer, the Credential Mapper, and the Keystore. For compatibility with earlier WebLogic Server 6.x environments, the Administration Console also provides a Realm function and a Realm Adapter.

With BEA WebLogic Server, the Administration Console becomes the central tool (and the best tool) for creating and modifying the security sections of configuration files and deployment descriptors. Configuration files no longer have clear text passwords. BEA WebLogic Server automatically creates protected passwords when it writes this information to the configuration file. Passwords are created on a per-realm basis.

Security management in the Administration Console is implemented using the classes of the Java Management Extensions (JMX) package. JMX supports both console and programmatic access to management functions, via Management Beans (MBeans). Plug-ins can extend base MBeans to meet their needs. This means that any security function in the Administration Console can be extended. Third-party security vendors or security-specific application programmers can add or replace pages in the Administration Console, as desired.

Security storage is provided by the Keystore, and by the BEA WebLogic Server system data store. The Java standard keystore stores public and private keys with encrypted storage. The WebLogic Server system data store is an embedded LDAP directory server optimized for use within WebLogic Server. The system data store provides unified storage (per security realm) of security information and proof material for users, groups, roles, and security policies. Customers can also use an existing LDAP directory service for retrieval of storage of user and group information.

Many security features have changed with respect to the security offered in WebLogic Server version 6.x.

Table 1-1 Changes in WebLogic Security Features

WebLogic Server Version 6.x	WebLogic Server 8.1
Security APIs	Most of the existing security APIs are deprecated in this release. BEA encourages you to use the corresponding J2EE standard interfaces to implement similar functionality in your application. For a complete list of deprecated APIs, see Programming WebLogic Security.
JNDI authentication	Java Authentication and Authorization Service (JAAS) authentication classes.
JAAS authentication	JAAS authentication has been enhanced to provide LoginModules for IIOP and T3 clients.
Auditing	You no longer have to create an implementation of the weblogic.security.Audit interface to add auditing to your WebLogic Server deployment. The WebLogic Auditing provider allows you to customize the data you want to record. You can further customize your auditing needs by implementing the Auditing SSPI to create a custom Auditing provider.
Defining security constraints in the weblogic.xml, weblogic-ejb-jar.xml, and weblogic-ra.xml files.	The functionality is enhanced so that security constraints can also be specified through the WebLogic Server Administration Console.
System password	There is no specific system account in WebLogic Server 8.1.
Access Control Lists (ACLs)	The ACLs used in previous releases of WebLogic Server are deprecated in this release. ACLs are replaced by security policies.
Users and Groups	Users and groups are still used; however, instead of assigning ACLs to a resource, you now create a security policy that grants users, groups, or roles access to a WebLogic resource.
6.x Security Realms (File realm, Caching realm, LDAP, Windows NT, UNIX, and RDBMS security realms)	The security realms used in previous releases of WebLogic Server are deprecated in this release. The WebLogic Authentication and Authorization providers provide the same functionality offered by the File realm, the Caching realm, and the LDAP realm. The Realm Adapter providers are available to allow you to continue to use the existing Windows NT, UNIX, and RDBMS security realms as you migrate to the new Authentication/Authorization scheme.
This feature was not available in previous releases of WebLogic Server.	Support for multiple security providers.
The SSL Protocol	The SSL support in WebLogic Server has been updated to provide the JSSE standard and the TLS v1 protocol.
This feature was not available in previous releases of WebLogic Server.	Support for J2EE JKS Keystores

Customers who installed security under BEA WebLogic Server 6.x have three choices when they transition to BEA WebLogic Server 8.1:

An Export utility (not part of BEA WebLogic Server, but provided on BEA dev2dev Online at http://dev2dev.bea.com/) enables customers to extract users (but not passwords), groups, and ACLs from WebLogic Server 6.x and import the information into the embedded LDAP Directory Server in WebLogic Server.

BEA WebLogic Server's open, flexible security architecture delivers advantages to all levels of users and introduces an advanced security design for application servers. BEA WebLogic Server provides out-of-the-box implementations for each of the Security Service Provider Interfaces (SSPIs). Companies now have a unique application server security solution that, together with clear and well-document security policies and procedures, can assure the confidentiality, integrity and availability of the server and its data. The key benefits of the new security architecture of BEA WebLogic Server include: