What are the two functions performed by digital certificates?

Security Fundamentals

This section describes the following concepts behind WebLogic Server security:

• Resources

• Security Realms

• Users

• Groups

• ACLs and Permissions

• SSL Protocol

• Authentication Mechanisms

• Digital Certificates

• Certificate Authority

• Supported Public Key Algorithms

• Supported Symmetric Key Algorithms

• Supported Message Digest Algorithms

• Supported Cipher Suites

Resources

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:

• An ACL defining who may access the resource

• The security realm to which the resource belongs

• An authentication mechanism that can verify users who request access to the resource.

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 fileRealm.properties 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:

• Only a File realm.

• A Caching realm with an alternate security realm or a custom security realm.

  In this configuration, the alternate security realm or the custom security realm functions as the primary realm. The File realm is the backup realm. The primary and backup realms in WebLogic Server work together to fulfill client requests with the proper authentication and authorization. For example, if you choose to use an alternate security realm such as the LDAP security realm, WebLogic Server first looks in that realm for a User. If the Users is not in the primary realm (in this case the LDAP security realm), WebLogic Server then looks for the User in the backup realm.

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:

• LDAP Security Realm

  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 Open LDAP, Netscape iPlanet, Microsoft Site Server, and Novell NDS.

  Note: An updated LDAP security realm is provided in this release of WebLogic Server. This LDAP security realm provides improved performance and configurability. BEA recommends upgrading to this updated LDAP security realm to take advantage of this functionality. However, you can still use the old LDAP security realm. For more information, see Managing Security.

• Windows NT Security Realm

  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.

• UNIX Security Realm

  Executes a native program, wlauth, to authenticate Users and Groups using UNIX login IDs and passwords. The UNIX Security realm is supported only on the Solaris and Linux platforms. The wlauth program uses a pluggable authentication module (PAM) that allows you to configure authentication services in a UNIX platform without altering applications that use those services. 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.

• RDBMS Security Realm

  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:

• "Specifying a Security Realm"

• "Configuring the Caching Realm"

• "Configuring the LDAP Security Realm"

• "Configuring the Windows NT Security Realm"

• "Configuring the UNIX Security Realm"

• "Configuring the RDBMS Security Realm"

Users

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:

• "Defining Users"

• "Protecting Passwords"

Groups

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 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:

• WebLogic Servers

• WebLogic events

• WebLogic JDBC connection pools

• WebLogic JMS destinations

• WebLogic JNDI contexts

• Weblogic MBeans

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:

• A mechanism that the applications can use to authenticate each other's identity.

• Encryption of the data exchanged by the applications.

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:

• Server authentication—WebLogic Server uses its digital certificate, issued by a trusted certificate authority, to authenticate to clients.

• Client Identify Verification—optionally, clients might be required to present their digital certificates to WebLogic Server. WebLogic Server then verifies that the digital certificate was issued by a trusted certificate authority and establishes the SSL connection. An SSL connection is not established if the digital certificate is not presented and verified. This type of connection is called two-way SSL. When you use two-way SSL, the certificate presented by the client is not equivalent to a WebLogic Server User so the client must also present a username and credential (either a password or a digital certificate) to use for authentication and authorization.

• Confidentiality—all client requests and server responses are encrypted to maintain the confidentiality of data exchanged over the network.

• Data Integrity—data that flows between a client and WebLogic Server is protected from tampering by a third party.

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.

• SSL communications between Web browsers and WebLogic Server are encapsulated in HTTPS packets for transport. For example:

  https://myserver.com/mypage.html

  WebLogic Server supports HTTPS with Web browsers that support SSL version 3. 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.

• Java clients connecting to WebLogic Server with the SSL protocol tunnel over BEA's multiplexed T3 protocol. For example:

  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.

• Exportable SSL supports 512-bit certificates and 40-bit bulk data encryption.

• Domestic SSL also supports 768-bit and 1024-bit certificates, and 56-bit and 128-bit bulk data encryption.

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:

• Password authentication—a user ID and password are requested from the user and sent to WebLogic Server in clear text. WebLogic Server checks the information and if it is trustworthy, grants access to the protected resource.

  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.

• Certificate authentication—when an SSL or HTTPS client request is initiated, WebLogic Server responds by presenting its digital certificate to the client. The client then verifies the digital certificate and an SSL connection is established. The CertAuthenticator class then extracts data from the client's digital certificate to determine which WebLogic Server User owns the certificate and then retrieves the authenticated User from the WebLogic Server security realm.

  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:

• "Configuring the SSL Protocol"

• "Configuring Mutual Authentication"

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 name of the subject (holder, owner) and other information required to confirm the unique identity the subject, such as the URL of the Web server using the digital certificate, or an individual's e-mail address

• The subject's public key

• The name of the certificate authority that issued the digital certificate

• A serial number

• The validity period (or lifetime) of the digital certificate (defined by a start date and an end date)

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 weblogic.security.X509 class does not provide accessors that provide information about which extensions are used in a particular digital certificate. To obtain that information, convert the weblogic.security.X509 object to a java.security.cert.X509Certificate object. The following code example includes code to perform this conversion:

X509[] wlCerts=... X509Certificate [] javaCerts = new X509Certificate[wlCerts.length]; try{ CertificateFactory cf = java.security.cert.CertificateFactory.getInstance("X.509"); for(int i=0; i

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:

• A public key (which is distributed widely) for verifying a digital signature or transforming data into a seemingly unintelligible form

• A private key (which is always kept secret) for creating a digital signature or returning the data to its original form

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 (Data Encryption Standard for Cipher Block Chaining)

  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 (Data Encryption Standard)

  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 (Rivest's Cipher 4)

  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.

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

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.

What is the function of a digital certificate?

What are the main features of a digital certificate?

What are the two name of digital certificate?