|
|
|
|
| |
This section describes the following concepts behind WebLogic Server security:
Resources are entities that are accessible from WebLogic Server, such as Enterprise JavaBeans (EJBs), servlets, Java Server Pages (JSPs), 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.
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 fileRealm.properties file.
Note: The File realm is designed for use with 1,000 or fewer users. If you have more that 1,000 users, we recommend using an alternate security realm.
WebLogic Server also provides support for developers who want 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.
WebLogic Server provides two realms: a primary realm and the backup realm. The primary realm is always the Caching realm. The backup realm may be any of the following: the File realm, an alternate security realm, or a custom security realm. The primary and backup realms in WebLogic Server work together to fulfill client requests with the proper authentication and authorization.
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:
Provides authentication through a Lightweight Directory Access Protocol (LDAP) server which allows you to manage Users in one place, the LDAP directory. When the LDAP security realm is used, the LDAP server authenticates Users and Groups. If you are using the SSL protocol with WebLogic Server, the LDAP Security Realm retrieves a User's common name from its digital certificate and searches the LDAP directory for that name. The LDAP Security Realm does not verify the digital certificate, that verification is performed by the SSL protocol.
The LDAP Security Realm currently supports Netscape Directory Server, Microsoft Site Server, and Novell NDS.
Note: The LDAP security realm has been rewritten to provide improved performance and configurability. BEA recommends upgrading your WebLogic Server 6.0 installation to Service Pack 1.0 to take advantage of this functionality. The rewritten LDAP security realm is available from the BEA downloads page.
Uses Windows NT account information to authenticate Users. Users and Groups defined through Windows NT can be used by WebLogic Server. You can use the Administration Console to view this realm, but you must use the facilities provided by Windows NT to defines Users and Groups.
Executes a native program, wlauth, to authenticate Users and Groups using UNIX login IDs and passwords. On some UNIX platforms, wlauth uses a pluggable authentication module (PAM) that allows you to configure authentication services in a UNIX platform without altering applications that use those services. On UNIX platforms for which PAM is not available, wlauth uses the standard login mechanism, including shadow passwords when they are supported. You can use the Administration Console to view this realm, but you must use the facilities provided by the UNIX platform to define Users and Groups.
Reads Users, Groups, and ACLs from a database. The RDBMS Security realm is provided as an example of a custom realm implementation that provides authentication and authorization services for WebLogic Server.
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 of those 50 users belong to the same 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.
Permissions represent privileges requires 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 java.security.acl 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:
ACLs and permissions for EJBs differ from ACLs and permissions for other kinds of WebLogic Server resources in the following ways:
For more information, see the "Defining ACLs" section in Managing Security.
For information about assigned ACLs in WebLogic Web applications, see Programming WebLogic Enterprise JavaBeans.
The SSL protocol offers security to two application 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.
https://myserver.com/mypage.html
WebLogic Server supports HTTPS with Web browsers that support SSL3. The Java Virtual Machine (JVM) in WebLogic Server does not currently support the HTTPS protocol adapter. Consequently, WebLogic Server depends on the implementation of the SSL protocol in the Web browser.
t3s://myserver.com:7002/mypage.html
Java clients running in WebLogic Server can establish either T3S connections to other WebLogic Servers, or HTTPS connections to other servers that support the SSL protocol, such as Web servers or secure proxy servers.
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.
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. Two types of authentication mechanisms are supported by WebLogic Server:
The SSL (or HTTPS) protocol can be used to provide an additional level of security to password authentication. Because the SSL protocol encrypts the data transferred between the client and WebLogic Server, the user ID and password of the user do not flow in the clear. Therefore, WebLogic Server can authenticate the user without compromising the confidentiality of the user's ID and password.
You can also use mutual authentication. In this case, WebLogic Server not only authenticates itself, it also requires authentication from the requesting client. Clients are required to submit digital certificates issued by a trusted certificate authority. Mutual authentication is useful when you must restrict access to trusted clients only. For example, you might restrict access by accepting only clients with digital certificates provided by you.
For more information, see the following sections in Managing Security:
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.
For more information, see the "Configuring the SSL Protocol" section in Managing Security.
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:
DES-CBC is a 64-bit block cipher run in Cipher Block Chaining (CBC) mode. It provides 56-bit keys. (8 parity bits are stripped from the full 64-bit key.)
Two-key triple-DES is a 128-bit block cipher run in Encrypt-Decrypt-Encrypt (EDE) mode. Two-key triple-DES provides two 56-bit keys (in effect, a 112-bit key).
For some time it has been common practice to protect and transport a key for DES encryption with triple-DES, which means that the input data (in this case the single-DES key) is encrypted, decrypted, and then encrypted again (an encrypt-decrypt-encrypt process). The same key is used for the two encryption operations.
RC4 is a variable key-size block cipher with a key size range of 40 to 128 bits. It is faster than DES and can be exported with a key size of 40 bits. A 56-bit key size is allowed for foreign subsidiaries and overseas offices of United States companies. In the United States, RC4 can be used with keys of virtually unlimited length, although the WebLogic Server PKI restricts the key length to 128 bits.
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.
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.
WebLogic Server supports the cipher suites described in Table 2-1.
|
Cipher Suite |
Key Exchange Type |
Symmetric Key |
|---|---|---|
|
SSL_RSA_WITH_RC4_128_SHA |
RSA |
128 |
|
SSL_RSA_WITH_RC4_128_MD5 |
RSA |
128 |
|
SSL_RSA_WITH_DES_CDC_SHA |
RSA |
56 |
|
SSL_RSA_EXPORT_WITH_RC4_40_MD5 |
RSA |
40 |
|
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA |
RSA |
40 |
|
SSL_RSA_WITH_3DES_EDE_CBC_SHA |
RSA |
112 |
|
SSL_NULL_WITH_NULL_NULL |
||
|
SSL_RSA_WITH_NULL_SHA |
RSA |
0 |
|
SSL_RSA_WITH_NULL_MD5 |
RSA |
0 |
The license for WebLogic Server determines what strength (either domestic or export) of cipher suite is used to protect communications. However, the cipher suite strength defined in the config.xml file overrides the license. For example, if you have an export license but define the use of a domestic cipher suite in the config.xml file, the domestic strength cipher suite will be used.
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|