BEA Logo BEA WebLogic Server Release 6.1

  BEA Home  |  Events  |  Solutions  |  Partners  |  Products  |  Services  |  Download  |  Developer Center  |  WebSUPPORT



  WebLogic Server Doc Home   |     Security   |   Previous Topic   |   Next Topic   |   Contents   |   View as PDF

Security Fundamentals


This section describes the following concepts behind WebLogic Server security:



Resources are entities that are accessible from WebLogic Server, such as events, servlets, JDBC connection pools, JMS destinations, JNDI contexts, connections, sockets, files, and enterprise applications and resources, such as databases.

For each resource you want to protect in WebLogic Server, you must specify the following:

For more information, see Managing Security.


Security Realms

A security realm is a logical grouping of Users, Groups, and ACLs. A WebLogic Server resource is protected under only one security realm and by a single ACL in that security realm. A User must be defined in a security realm in order to access any resources belonging to that realm. When a User attempts to access a particular WebLogic Server resource, WebLogic Server tries to authenticate and authorize the User by checking the ACL and permissions assigned the User in the relevant realm. Figure 2-1 illustrates how realms work in WebLogic Server.

Figure 2-1 Users, Groups, and ACLs in a WebLogic Server Realm


The default security realm in WebLogic Server is the File realm. When WebLogic Server is started, the File realm creates User, Group, and ACL objects from properties defined through the Administration Console in WebLogic Server and stored in the file.

Note: The File realm is designed for use with 10,000 or fewer users. If you have more that 10,000 users, we recommend using an alternate security realm.

WebLogic Server also provides support for developers who want or must accommodate special security situations. WebLogic Server allows you to use a security realm other than the File realm by installing an alternate security realm or by writing your own customized security realm. Alternate security realms can support some or all of the authentication and authorization operations WebLogic Server requires of a realm.

There are two possible realm configurations:

Note: If you choose to use an alternate security realm or a custom security realm, you must configure the Caching realm.

In the default scenario, a client request arrives at the WebLogic Server through the Caching realm. The Caching realm forwards the request to the File realm for authorization and authentication. When it receives the results of the realm lookups (whether successful or unsuccessful), the Caching realm stores these results. It maintains separate caches for User, Group, permission, ACL, and authentication look ups. You can selectively enable each type of cache, set the number of objects cached, and specify the number of seconds a cached object is valid. Effectively, the Caching realm makes the authentication and authorization process faster and more efficient.

If you use an alternate security realm or a custom security realm, the Caching realm evaluates the client request, delegates it to the appropriate security realm, and caches the results to make the next lookup faster. For example, you may be using an alternate security realm that supports only authentication operations. When a client request is received by WebLogic Server, the Caching realm contacts the alternate security realm for authentication, and then the File realm for authorization.

Figure 2-2 illustrates how alternate security realms, the Caching realm, and the File realm work together to authenticate and authorize users in a WebLogic Server environment.

Figure 2-2 Alternate Security Realms, the Caching Realm, and the File Realm in WebLogic Server


WebLogic Server provides the following alternate security realms:

For more information, see the following sections in Managing Security:



Users are entities that use WebLogic Server, such as application end users, client applications, and even other WebLogic Servers.

When a user wants to access WebLogic Server, it presents a username and a credential (either a password or a digital certificate) through programmatic means to WebLogic Server. If WebLogic Server can prove the identity of the User based on that username and credential, WebLogic Server associates the User with a thread that executes code on behalf of the User. Before the thread begins executing code, however, WebLogic Server checks pertinent ACLs to make sure the User has the required permissions to continue.

When defining a User in a WebLogic Server realm, you also define a password for that User. In the past, usernames and passwords were stored in clear text in a WebLogic Server security realm. Now WebLogic Server hashes all passwords. When WebLogic Server receives a client request, the password presented by the client is hashed and WebLogic Server compares it to the already hashed password for matching.

For more information, see the following sections in Managing Security:



Groups are logically ordered sets of Users. Managing Groups is more efficient than managing large numbers of Users individually. For example, an administrator may specify permissions for 50 users at one time by specifying a Group. Usually, Group members have something in common. For example, a company may separate their sales staff into two Groups, Sales Representatives and Sales Managers, because staff members have different levels of access to WebLogic Server resources depending on their job descriptions.

WebLogic Server can be configured to assign Users to Groups. Each Group shares a common set of permissions that govern its member users' access to resources. You can mix Group names and User names whenever a list of Users is permitted.

A person can be defined as both an individual User and a Group member. Individual access permissions override any Group member access permissions. WebLogic Server evaluates each user by first looking for a Group, and testing whether the user is a member of the Group, and then looking for the User in the list of defined Users.

For more information, see the "Defining Groups" topic in Managing Security.


ACLs and Permissions

Permissions represent privileges required to access resources. A system administrator protects resources by creating lists of Users and Groups that have the permissions required to access those resources. Such lists are called access control lists (ACLs). ACLs and the functions for which they grant permission are resource-specific. For example, Users with the proper permissions may read, write, send, and/or receive files, load servlets, and link to libraries.

An ACL file is composed of AclEntries, each of which contains a set of permissions for a particular User or Group.

WebLogic Server uses the JavaSoft ACL standard, distributed with the Java Development Kit (JDK) 1.1, to extend the security framework of Java and make it practical for use at the enterprise level. The WebLogic Server implementation of ACLs is based on the package. Because ACLs in WebLogic Server are based on an open-standard, you are not tied to a proprietary solution.

You can set permissions on the following WebLogic Server resources:

Note: Access to EJBs and Web applications is not controlled through ACLs. Rather, security elements in deployment descriptors are used to define access to a particular EJB or Web application.

For more information, see the "Defining ACLs" section in Managing Security.

For information about EJB security, see Programming WebLogic Enterprise JavaBeans.

For more information about Web application security, see Assembling and Configuring Web Applications.


SSL Protocol

The SSL protocol offers security to applications connected through a network. Specifically, the SSL protocol provides the following:

When the SSL protocol is used, the target always authenticates itself to the initiator. Optionally, if the target requests it, the initiator can authenticate itself to the target. Encryption makes data transmitted over the network intelligible only to the intended recipient. An SSL connection begins with a handshake during which the applications exchange digital certificates, agree on the encryption algorithms to be used, and generate the encryption keys to be used for the remainder of the session.

The SSL protocol provides the following security features:

If you are using a Web browser to communicate with WebLogic Server, you can use the Hypertext Transfer Protocol with SSL (HTTPS) to secure network communications.

The SSL protocol is tunneled over an IP-based protocol. Tunneling means that each SSL record is encapsulated and packaged with the headers needed to send the record over another protocol. The use of SSL is signified in the protocol scheme of the URL used to specify the location of WebLogic Server.

WebLogic Server is available with exportable- or domestic-strength SSL.

The standard WebLogic Server distribution supports exportable-strength SSL only. The domestic version is available, by request only from your BEA sales representative. Since the United States Government relaxed restrictions on exporting encryption software in early 2000, the domestic version of WebLogic Server can be used in most countries.

During installation, you are prompted to choose which strength of the SSL protocol you want to use.We recommend the domestic WebLogic Server distribution because it allows stronger encryption. If you generate a Certificate Signature Request (CSR) using the exportable WebLogic Server distribution, you cannot support high-strength connections and you cannot authenticate clients that present domestic-strength certificates.

The implementation of the SSL protocol provided by WebLogic Server is a pure-Java implementation. A native library provides faster performance for some SSL operations on the Solaris, Windows NT, and IBM AIX platforms. You can request the use of these native Java libraries for the SSL protocol through the Administration Console.

For more information, see the "Configuring the SSL Protocol" section in Managing Security.


Authentication Mechanisms

WebLogic Server users must be authenticated whenever they request access to a protected WebLogic Server resource. For this reason, each user is required to provide a credential (a username/password pair or a digital certificate) to WebLogic Server. The following types of authentication mechanisms are supported by WebLogic Server:

For more information, see the following sections in Managing Security:


Digital Certificates

Digital certificates are electronic documents used to verify the unique identities of principals and entities over networks such as the Internet. A digital certificate securely binds the identity of a user or entity, as verified by a trusted third party known as a certificate authority, to a particular public key. The combination of the public key and the private key provides a unique identity to the owner of the digital certificate.

Digital certificates allow verification of the claim that a specific public key does in fact belong to a specific user or entity. A recipient of a digital certificate can use the public key in a digital certificate to verify that a digital signature was created with the corresponding private key. If such verification is successful, this chain of reasoning provides assurance that the corresponding private key is held by the subject named in the digital certificate, and that the digital signature was created by that subject.

A digital certificate typically includes a variety of information, such as the following:

The most widely accepted format for digital certificates is defined by the ITU-T X.509 international standard. Digital certificates can be read or written by any application complying with the X.509 standard. The public key infrastructure (PKI) in WebLogic Server recognizes digital certificates that comply with X.509 version 3, or X.509v3. We recommend obtaining digital certificates from a certificate authority such as Verisign or Entrust.

WebLogic Server supports the extensions provided by the X.509 standard, however, the class does not provide accessors that provide information about which extensions are used in a particular digital certificate. To obtain that information, convert the object to a object. The following code example includes code to perform this conversion:

X509[] wlCerts=...
X509Certificate [] javaCerts = new X509Certificate[wlCerts.length];
																		        CertificateFactory cf =
        for(int i=0; i<wlCerts.length; i++){
              ByteArrayOutputStream bos = new ByteArrayOutputStream();
              ByteArrayInputStream bis = new
              javaCerts[i] = (X509Certificate)cf.generateCertificate(bis);

For more information, see the "Configuring the SSL Protocol" section in Managing Security.


Certificate Authority

Digital certificates are issued by a certificate authority. Any trusted third-party organization or company that is willing to vouch for the identities of those to whom it issues digital certificates and public keys can be a certificate authority. When a certificate authority creates a digital certificate, the certificate authority signs it with its private key, to ensure that any tampering will be detected. The certificate authority then returns the signed digital certificate to the requesting subject.

The subject can verify the signature of the issuing certificate authority by using the public key of the certificate authority. The certificate authority makes its public key available by providing a digital certificate issued from a higher-level certificate authority attesting to the validity of the public key of the lower-level certificate authority. This scheme gives rise to hierarchies of certificate authorities. This hierarchy is terminated by a self-signed digital certificate known as the root key.

The recipient of an encrypted message can develop trust in the private key of a certificate authority recursively, if the recipient has a digital certificate containing the public key of the certificate authority signed by a superior certificate authority who the recipient already trusts. In this sense, a digital certificate is a stepping stone in digital trust. Ultimately, it is necessary to trust only the public keys of a small number of top-level certificate authorities. Through a chain of digital certificates, trust in a large number of users' digital signatures can be established.

Thus, digital signatures establish the identities of communicating entities, but a digital signature can be trusted only to the extent that the public key for verifying it can be trusted.

For more information, see the "Configuring the SSL Protocol" section in Managing Security.


Supported Public Key Algorithms

Public key (or asymmetric key) algorithms are implemented through a pair of different but mathematically related keys:

The PKI in WebLogic Server also supports digital signature algorithms. Digital signature algorithms are simply public key algorithms used to generate digital signatures.

WebLogic Server supports the Rivest, Shamir, and Adelman (RSA) algorithm.


Supported Symmetric Key Algorithms

In symmetric key algorithms, the same key is used to encrypt and decrypt a message. The public key encryption system uses a symmetric key algorithm to encrypt a message sent between two communicating entities. Symmetric key encryption operates at least 1000 times faster than public key cryptography.

A block cipher is a type of symmetric key algorithm that transforms a fixed-length block of plain text (unencrypted text) data into a block of cipher text (encrypted text) data of the same length. This transformation takes place in accordance with the value of a randomly generated session key. The fixed length is called the block size.

The PKI in WebLogic Server supports the following symmetric key algorithms:

WebLogic Server users cannot expand or modify this list of algorithms.


Supported Message Digest Algorithms

WebLogic Server supports the MD5 and SHA (Secure Hash Algorithm) message digest algorithms. Both MD5 and SHA are well known, one-way hash algorithms. A one-way hash algorithm takes a message and converts it into a fixed string of digits, which is referred to as a message digest or hash value.

MD5 is a high-speed, 128-bit hash; it is intended for use with 32-bit machines. SHA offers more security by using a 160-bit hash, but is slower than MD5.


Supported Cipher Suites

A cipher suite is an SSL encryption method that includes the key exchange algorithm, the symmetric encryption algorithm, and the secure hash algorithm used to protect the integrity of a communication. For example, the cipher suite called RSA_WITH_RC4_128_MD5 uses RSA for key exchange, RC4 with a 128-bit key for bulk encryption, and MD5 for message digest.

The cyptographic modules used by WebLogic Server are FIPS 140-1 compliant.

WebLogic Server supports the cipher suites described in Table 2-1.

Table 2-1 SSL Cipher Suites Supported by WebLogic Server

Cipher Suite

Key Exchange Type

Symmetric Key


























The license for WebLogic Server determines what strength (either domestic or export) of cipher suite is used to protect communications. If the cipher suite strength defined in the config.xml file exceeds the strength specified by the license, the server uses the strength specified by the license. For example, if you have an export strength license but you define the use of an domestic strength cipher suite in the config.xml file, the server rejects the domestic strength cipher suite and uses the export strength cipher suite.


back to top previous page next page