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