Security Fundamentals

The following sections describe security fundamentals as they relate to security in WebLogic Server:

 

Auditing

Auditing is the process whereby information about operating requests and the outcome of those requests are collected, stored, and distributed for the purposes of non-repudiation. In other words, auditing provides an electronic trail of computer activity. In the WebLogic Server security architecture, an Auditing provider is used to provide auditing services.

If configured, the WebLogic Security Framework will call through to an Auditing provider before and after security operations (such as authentication or authorization) have been performed, enabling audit event recording. The decision to audit a particular event is made by the Auditing provider itself and can be based on specific audit criteria and/or severity levels. The records containing the audit information may be written to output repositories such as an LDAP server, database, and a simple file.

 

Authentication

Authentication is the mechanism by which callers prove that they are acting on behalf of specific users or systems. Authentication answers the question, "Who are you?" using credentials such as username/password combinations.

In WebLogic Server, Authentication providers are used to prove the identity of users or system processes. Authentication providers also remember, transport, and make identity information available to various components of a system (via subjects) when needed. During the authentication process, a Principal Validation provider provides additional security protections for the principals (users and groups) contained within the subject by signing and verifying the authenticity of those principals.

The following sections describe authentication concepts and functionality.

 

Subjects and Principals

Subjects and principals are closely related.

A principal is an identity assigned to a user or group as a result of authentication. Both users and groups can be used as principals by application servers such as WebLogic Server. The Java Authentication and Authorization Service (JAAS) requires that subjects be used as containers for authentication information, including principals.

Figure 2-1 illustrates the relationships among users, groups, principals, and subjects.

Note: In this release of WebLogic Server, subjects replace WebLogic Server 6.x users.

Figure 2-1 Relationships Among Users, Groups, Principals and Subjects


As part of a successful authentication, principals are signed and stored in a subject for future use. A Principal Validation provider signs principals, and an Authentication provider's LoginModule actually stores the principals in the subject. Later, when a caller attempts to access a principal stored within a subject, a Principal Validation provider verifies that the principal has not been altered since it was signed, and the principal is returned to the caller (assuming all other security conditions are met).

Any principal that is going to represent a WebLogic Server user or group needs to implement the WLSUser and WLSGroup interfaces, which are available in the weblogic.security.spi package.

 

Java Authentication and Authorization Service (JAAS)

Whether the client is an application, applet, Enterprise JavaBean (EJB), or servlet that requires authentication, WebLogic Server uses the Java Authentication and Authorization Service (JAAS) classes to reliably and securely authenticate to the client. JAAS implements a Java version of the Pluggable Authentication Module (PAM) framework, which permits applications to remain independent from underlying authentication technologies. Therefore, the PAM framework allows the use of new or updated authentication technologies without requiring modifications to your application.

WebLogic Server uses JAAS for remote fat-client authentication, and internally for authentication. Therefore, only developers of custom Authentication providers and developers of remote fat client applications need to be involved with JAAS directly. Users of thin clients or developers of within-container fat client applications (for example, those calling an Enterprise JavaBean (EJB) from a servlet) do not require the direct use or knowledge of JAAS.

 

JAAS LoginModules

LoginModules are the work-horses of authentication: all LoginModules are responsible for authenticating users within the security realm and for populating a subject with the necessary principals (users/groups). LoginModules that are not used for perimeter authentication also verify the proof material submitted (for example, a user's password).

If there are multiple Authentication providers configured in a security realm, each of the Authentication providers' LoginModules will store principals within the same subject. Therefore, if a principal that represents a WebLogic Server user (that is, an implementation of the WLSUser interface) named "Joe" is added to the subject by one Authentication provider's LoginModule, any other Authentication provider in the security realm should be referring to the same person when they encounter "Joe". In other words, the other Authentication providers' LoginModules should not attempt to add another principal to the subject that represents a WebLogic Server user (for example, named "Joseph") to refer to the same person. However, it is acceptable for another Authentication provider's LoginModule to add a principal of a type other than WLSUser with the name "Joseph".

 

JAAS Control Flags

If a security realm has multiple Authentication providers configured, the Control Flag attribute on the Authenticator provider determines the ordered execution of the Authentication providers. The values for the Control Flag attribute are as follows:

  • REQUIRED - This LoginModule must succeed. Even if it fails, authentication proceeds down the list of LoginModules for the configured Authentication providers. This setting is the default.
  • REQUISITE - This LoginModule must succeed. If other Authentication providers are configured and this LoginModule succeeds, authentication proceeds down the list of LoginModules. Otherwise, return control to the application.
  • SUFFICIENT - This LoginModule needs not succeed. If it does succeed, return control to the application. If it fails and other Authentication providers are configured, authentication proceeds down the LoginModule list.
  • OPTIONAL - The user is allowed to pass or fail the authentication test of this Authentication providers. However, if all Authentication providers configured in a security realm have the JAAS Control Flag set to OPTIONAL, the user must pass the authentication test of one of the configured providers.

 

CallbackHandlers

A CallbackHandler is a highly-flexible JAAS standard that allows a variable number of arguments to be passed as complex objects to a method. There are three types of CallbackHandlers: NameCallback, PasswordCallback, and TextInputCallback, all of which are part of the javax.security.auth.callback package. The NameCallback and PasswordCallback return the username and password, respectively. TextInputCallback can be used to access the data users enter into any additional fields on a login form (that is, fields other than those for obtaining the username and password). When used, there should be one TextInputCallback per additional form field, and the prompt string of each TextInputCallback must match the field name in the form. WebLogic Server only uses the TextInputCallback for form-based Web application login.

An application implements a CallbackHandler and passes it to underlying security services so that they may interact with the application to retrieve specific authentication data, such as usernames and passwords, or to display certain information, such as error and warning messages.

CallbackHandlers are implemented in an application-dependent fashion. For example, implementations for an application with a graphical user interface (GUI) may pop up windows to prompt for requested information or to display error messages. An implementation may also choose to obtain requested information from an alternate source without asking the user.

Underlying security services make requests for different types of information by passing individual Callbacks to the CallbackHandler. The CallbackHandler implementation decides how to retrieve and display information depending on the Callbacks passed to it. For example, if the underlying service needs a username and password to authenticate a user, it uses a NameCallback and PasswordCallback. The CallbackHandler can then choose to prompt for a username and password serially, or to prompt for both in a single window.

 

Mutual Authentication

With mutual authentication, both the client and the server are required to authenticate themselves to each other. This can be done by means of certificates or other forms of proof material. WebLogic Server supports two-way SSL authentication, which is a form of mutual authentication. However, by strict definition, mutual authentication takes place at higher layers in the protocol stack then does SSL authentication. For more information, see One-way/Two-way SSL Authentication.

 

Identity Assertion Providers and LoginModules

When used with a LoginModule, Identity Assertion providers support single sign-on. For example, an Identity Assertion provider can generate a token from a digital certificate, and that token can be passed around the system so that users are not asked to sign on more than once.

The LoginModule that an Identity Assertion provider uses can be:

  • Part of a custom Authentication provider you develop.
  • Part of the WebLogic Authentication provider that BEA developed and packaged with WebLogic Server.
  • Part of a third-party security vendor's Authentication provider.

Unlike in a simple authentication situation, the LoginModules that Identity Assertion providers use do not verify proof material such as usernames and passwords; they simply verify that the user exists.

 

Identity Assertion and Tokens

Identity Assertion providers support user name mappers, which map a valid token to a WebLogic Server user. You develop Identity Assertion providers to support the specific types of tokens that you will be using to assert the identities of users or system processes. You can develop an Identity Assertion provider to support multiple token types, but the WebLogic Server administrator must configure the Identity Assertion provider so that it validates only one "active" token type. While you can have multiple Identity Assertion providers in a security realm with the ability to validate the same token type, only one Identity Assertion provider can actually perform this validation.

Note: To use the WebLogic Identity Assertion provider for X.501 and X.509 certificates, you have the option of using the default user name mapper that is supplied with the WebLogic Server product (weblogic.security.providers.authentication. DefaultUserNameMapperImpl) or providing you own implementation of the weblogic.security.providers.authentication.UserNameMapper interface. For more mformation, see Do I Need to Develop a Custom Identity Assertion Provider? in Developing Security Providers for WebLogic Server.

 

Types of Authentication

WebLogic Server users must be authenticated whenever they request access to a protected WebLogic resource. For this reason, each user is required to provide a credential (for example, a password) to WebLogic Server. The following types of authentication are supported by the WebLogic Authentication provider that is included in the WebLogic Server distribution:

WebLogic Server can use the WebLogic Authentication provider that is provided as part of the WebLogic Server product or custom security providers to perform the different types of authentication. For information on the WebLogic Authentication provider and how to configure authentication, see The Credential Mapping Process" on page 4-9 and the following sections in Managing WebLogic Security:

 

Username/Password Authentication

In username/password authentication, a user ID and password are requested from the user and sent to WebLogic Server. WebLogic Server checks the information and if it is trustworthy, grants access to the protected WebLogic resource.

Secure Sockets Layer (SSL), or Hyper-Text Transfer Protocol (HTTPS), can be used to provide an additional level of security to username/password authentication. Because SSL 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 digital certificate is issued by an entity (a trusted certificate authority), which validates the identity of WebLogic Server.

You can also use two-way SSL authentication, a form of mutual authentication. With two-way SSL authentication, both the client and server must present a certificate before the connection thread is enabled between the two. See One-way/Two-way SSL Authentication.

Note: Two-way SSL authentication is supported by the WebLogic Authentication provider that is provided as part of the WebLogic Server product.

 

Perimeter Authentication

Perimeter authentication is the process of authenticating the identity of a remote user outside of the application server domain.

The following sections describe perimeter authentication:

 

How is Perimeter Authentication Accomplished?

Perimeter authentication is typically accomplished by the remote user specifying an asserted identity and some form of corresponding proof material, normally in the form of a passphrase (such as a password, a credit card number, Personal Identification Number, or some other form of personal identification information), which is used to perform the verification.

The authentication agent, the entity that actually vouches for the identity, can take many forms, such as a Virtual Private Network (VPN), firewall, an enterprise authentication service, or some other form of global identity service. Each of these forms of authentication agents has a common characteristic: they all perform an authentication process that results in an artifact or token that must be presented to determine information about the authenticated user at a later time. Currently, the format of the token varies from vendor to vendor, but there are efforts to define a standard token format using XML. In addition, there is a current standard for Attribute Certificates, which is based on the X.509 standard for digital certificates. But even after all of this, if the applications and the infrastructure on which they are built are not designed to support this concept, enterprises are still forced to require that their remote users re-authenticate to the applications within the network.

 

How Does WebLogic Server Support Perimeter Authentication?

WebLogic Server is designed to extend the single sign-on concept all the way to the perimeter through support for identity assertion (see Figure 2-2). Provided as a critical piece of the WebLogic Security Framework, the concept of identity assertion allows WebLogic Server to use the authentication mechanism provided by perimeter authentication schemes such as Checkpoint's OPSEC, the emerging Security Assertion Markup Language (SAML), or enhancements to protocols such as Common Secure Interoperability (CSI) v2 to achieve this functionality.

Figure 2-2 Perimeter Authentication


Support for perimeter authentication requires the use of an Identity Assertion provider that is designed to support one or more token formats. Multiple and different Identity Assertion providers can be registered for use. The tokens are transmitted as part of any normal business request, using the mechanism provided by each of the various protocols supported by WebLogic Server. Once a request is received with WebLogic Server, the entity that handles the processing of the protocol message recognizes the existence of the token in the message. This information is used in a call to the WebLogic Security Framework that results in the appropriate Identity Assertion provider being called to handle the verification of the token. It is the responsibility of the Identity Assertion provider implementation to perform whatever actions are necessary to establish validity and trust in the token and to provide the identity of the user with a reasonable degree of assurance, without the need for the user to re-authenticate to the application.

 

Authorization

Authorization is the process whereby the interactions between users and WebLogic resources are controlled, based on user identity or other information. In other words, authorization answers the question, "What can you access?" In WebLogic Server, an Authorization provider is used to limit the interactions between users and WebLogic resource to ensure integrity, confidentiality, and availability.

The following sections describe authorization concepts and functionality:

 

WebLogic Resources

A WebLogic resource is a structured object used to represent an underlying WebLogic Server entity, which can be protected from unauthorized access using security roles and security policies.

WebLogic resources are hierarchical. Therefore, the level at which you define these security roles and security policies is up to you. For example, you can define security roles and security policies on: entire enterprise applications (EARs); an Enterprise JavaBean (EJB) JAR containing multiple EJBs; a particular Enterprise JavaBean (EJB) within that JAR; or a single method within that EJB.

WebLogic resource implementations are available for:

  • Administrative resources
  • Application resources
  • Common Object Model (COM) resources
  • Enterprise Information System (EIS) resources
  • Enterprise JavaBean (EJB) resources
  • Java Database Connectivity resources
  • Java Messaging Service resources
  • Java Naming and Directory Interface (JNDI) resources
  • Server resources
  • Universal Resource Locator (URL) resources
  • Web Service resources

Note: Each of these WebLogic resource implementations is explained in detail in the Javadocs for WebLogic Classes. For more information, see Types of WebLogic Resources" in Securing WebLogic Resources.

 

Security Policies

In releases prior to WebLogic Server 7.0, access control lists (ACLs) were used to protect WebLogic resources. In this release of WebLogic Server, security policies replace ACLs and answer the question "Who has access to a WebLogic resource?" A security policy is created when you define an association between a WebLogic resource and one or more users, groups, or security roles. You can optionally define a time constraint for a security policy. A WebLogic resource has no protection until you assign it a security policy.

You assign security policies to any of the defined WebLogic resources (for example, an EJB resource or a JNDI resource) or to attributes or operations of a particular instance of a WebLogic resource (an EJB method or a servlet within a Web application). If you assign a security policy to a type of WebLogic resource, all new instances of that resource inherit that security policy. Security policies assigned to individual resources or attributes override security policies assigned to a type of WebLogic resource.

Security policies are stored in an Authorization provider's database. By default, the WebLogic Authorization provider is configured and security policies are stored in the embedded LDAP server.

To use a user or group to create a security policy, the user or group must be defined in the security provider database for the Authentication provider that is configured in the default security realm. To use a security role to create a security policy, the security role must be defined in the security provider database for the Role Mapping provider that is configured in the default security realm. By default, the WebLogic Authentication and Role Mapping providers are configured in the database in the embedded LDAP server.

By default, security policies are defined in WebLogic Server for the WebLogic resources. These security policies are based on security roles and default global groups. You also have the option of basing a security policy on a user. BEA recommends basing security policies on security roles rather than users or groups. Basing security policies on security roles allows you to manage access based on a security role that a user or group is granted, which is a more efficient method of management. For a listing of the default security realm for the WebLogic resources, see Default Security Policies" in Securing WebLogic Resources.

 

ContextHandlers

A ContextHandler is a high-performing WebLogic class that obtains additional context and container-specific information from the resource container, and provides that information to security providers making access or role mapping decisions. The ContextHandler interface provides a way for an internal WebLogic resource container to pass additional information to a WebLogic Security Framework call, so that a security provider can obtain contextual information beyond what is provided by the arguments to a particular method. A ContextHandler is essentially a name/value list and as such, it requires that a security provider know what names to look for. (In other words, use of a ContextHandler requires close cooperation between the WebLogic resource container and the security provider.) Each name/value pair in a ContextHandler is known as a context element, and is represented by a ContextElement object.

Currently, three types of WebLogic resource containers pass ContextHandlers to the WebLogic Security Framework: the Servlet, EJB, and Web Service containers. Thus, URL (Web), EJB, and Web Service resource types have different context elements whose values Authorization and Role Mapping providers can inspect. An implementation of the AuditContext interface (used when a security provider is implemented to post audit events) may also examine the values of context elements.

For more information about the values of particular context elements, see "ContextHandlers and WebLogic Resources in Developing Security Providers for WebLogic Server.

 

Access Decisions

Like LoginModules for Authentication providers, an Access Decision is the component of an Authorization provider that actually answers the "is access allowed?" question. Specifically, an Access Decision is asked whether a subject has permission to perform a given operation on a WebLogic resource, with specific parameters in an application. Given this information, the Access Decision responds with a result of PERMIT, DENY, or ABSTAIN.

 

Adjudication

Adjudication involves resolving any authorization conflicts that may occur when more than one Authorization provider is configured in a security realm, by weighing the result of each Authorization provider's Access Decision. In WebLogic Server, an Adjudication provider is used to tally the results that multiple Access Decisions return, and determines the final PERMIT or DENY decision. An Adjudication provider may also specify what should be done when an answer of ABSTAIN is returned from a single Authorization provider's Access Decision.

 

Secure Sockets Layer (SSL)

SSL enables secure communication between applications connected through the Web. For a discussion of the components of SSL communication and why each component is necessary, see How SSL Works, published by the Netscape Communications Corporation, and available on the Web at http://developer.netscape.com/tech/security/ssl/howitworks.html.

WebLogic Server fully supports SSL communication. By default, WebLogic Server is configured for one-way SSL authentication. Using the Administration Console, you can configure WebLogic Server for two-way SSL authentication.

To use SSL with WebLogic Server, you need a private key, a digital certificate containing the matching public key, and a certificate signed by at least one trusted certificate authority (CA) that can verify the data embedded in the digital certificate. If the certificate authority that signed the digital certificate is not well-known, you may also need to install their root trusted CA's certificate in your WebLogic Server. Trusted CA ceritificates are signed by authorities that are well-know.

To acquire a digital certificate for your server, you generate a public key, private key, and a Certificate Signature Request (CSR), which contains your public key. You send the CSR request to a certificate authority and follow their procedures for obtaining a signed digital certificate.

Once you have your private keys, digital certificates, and any additional trusted CA certificates that you may need, you need to store them so that WebLogic Server can use them to verify identity. In this release of WebLogic Server, you should store your private keys and certificates in keystores. For purposes of backwards compatibility, you may also store your private keys and certificates in files. For more information about private key, public key, and certificate requirements and procedures, see "Configuring SSL and Managing WebLogic Security.

To use SSL when connecting to a WebLogic server application with your browser, you simply specify HTTPS and the secure port (port number 7002) in the URL. For example: 

https://localhost:7002/examplesWebApp/SnoopServlet.jsp

Where localhost is the name of the system hosting the Web application.

The following topics are discussed in this section:

 

SSL Features

WebLogic Server provides a pure-Java implementation of SSL. Generally, SSL provides the following:

  • A mechanism that the communicating applications can use to authenticate each other's identity.
  • Encryption of the data exchanged by the applications.

When SSL is used, the target (the server) always authenticates itself to the initiator (the client). 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.

SSL provides the following security features:

  • Server authentication - WebLogic Server uses its digital certificate, issued by a trusted certificate authority, to authenticate to clients. SSL minimally requires the server to authenticate to the client using its digital certificate. If the client is not required to present a digital certificate, the connection type is called one-way SSL authentication.
  • Client Identity 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 authentication, a form of mutual authentication.
  • 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 validation of user identities.

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

 

SSL Tunneling

SSL 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. SSL can be used by Web browsers and Java clients as follows:

  • 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 adapter. Consequently, WebLogic Server depends on the implementation of SSL in the Web browser.

  • Java clients connecting to WebLogic Server with SSL tunnelled 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 SSL, such as Web servers or secure proxy servers.

 

One-way/Two-way SSL Authentication

WebLogic Server supports one-way and two-way SSL authentication.With one-way SSL authentication, the target (the server) is required to present a digital certificate to the initiator (the client) to prove its identity. The client performs two checks to validate the digital certificate:

  1. The client checks that the digital certificate is on its list of trusted certificate authorities.
  2. The client checks that the host name in the certificate matches the name of the server.

If both of the above checks return true, the SSL connection is established.

With two-way SSL authentication, both the client and server must present digital certificates before the SSL connection is enabled between the two. Thus, in this case, WebLogic Server not only authenticates itself to the client (which is the minimum requirement for certificate authentication), but it also requires authentication from the requesting client. Two-way SSL authentication is useful when restrict access to trusted clients only.

Figure 2-3 illustrates WebLogic Server SSL connections and shows which connections support one-way SSL, two-way SSL, or both. The Web browser client, Web Server, Fat client, Web Services client, and SSL server connections can be configured for either one-way or two-way SSL. WebLogic Server determines whether an SSL connection is configured for one-way or two-way. Use the Administration Console to configure SSL.

Figure 2-3 How WebLogic Server Supports SSL Connections


 

Domestic SSL and Exportable SSL

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

  • Exportable SSL supports 512-bit certificates and 40- and 50-bit bulk data encryption.
  • Domestic SSL also supports 768-bit and 1024-bit certificates, 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.

Notes: If you request the domestic-strength version of WebLogic Server and you qualify to receive it, you will receive a domestic-strength WebLogic Server software license to use when you install the WebLogic Server distribution.

Because the United States Government relaxed restrictions on exporting encryption software early the year 2000, the domestic version of WebLogic Server can be used in most countries.

BEA recommends the domestic WebLogic Server distribution because it allows stronger encryption.

Note: If you generate a Certificate Signature Request (CSR), which is an electronically generated request for a certificate, using the exportable-strength WebLogic Server distribution, you cannot support domestic-strength SSL connections and you cannot authenticate clients that present domestic-strength certificates.

For more information, see Configuring SSL" in Managing WebLogic 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 enable 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. BEA recommends obtaining digital certificates from a certificate authority such as Verisign or Entrust.

For more information, see Configuring SSL" inManaging WebLogic Security.

 

Certificate Authorities

Digital certificates are issued by certificate authorities. 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 party.

The requesting party 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 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 top-level, self-signed certificate known as the root certificate, because no other public key is needed to certify it. Root certificates are issued by trusted (root) Certificate Authorities.

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, the recipient of an encrypted message can develop trust in the public key of a certificate authority recursively. 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 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 Configuring SSL" inManaging WebLogic Security.

 

Host Name Verification

Host Name verification is the process of verifying that the name of the host to which an SSL connection is made is the intended or authorized party. Host name verification prevents man-in-the-middle attacks when a Web client (a Web browser, a WebLogic client, or a WebLogic Server acting as a client) requests an SSL connection to another application server.

By default, WebLogic Server, as a function of the SSL handshake, compares the common name in the SubjectDN of the SSL server's digital certificate with the host name of the SSL server used to initiate the SSL connection. If these names do not match, the SSL connection is dropped.

 

Trust Managers

When an SSL client connects to an SSL server, the SSL server presents its digital certificate chain to the client for authentication. That chain could contain an invalid digital certificate. The SSL specification says that the client should drop the SSL connection upon discovery of an invalid certificate. Web browsers, however, ask the user whether to ignore the invalid certificate and continue up the chain to determine if it is possible to authenticate the SSL server with any of the remaining certificates in the certificate chain. The Trust Manager eliminates this inconsistent practice by enabling you to control when to continue or discontinue an SSL connection. Using a Trust Manager you can perform custom checks before continuing an SSL connection. For example, you can use the Trust Manager to specify that only users from specific localities, such as towns, states, or countries, or users with other special attributes, can gain access via the SSL connection.

WebLogic Server provides the weblogic.security.SSL.TrustManagerJSSE interface, which enables you to override validation errors in a peer's digital certificate and continue the SSL handshake. You can also use this interface to discontinue an SSL handshake by performing additional validation on a server's digital certificate chain.

Note: This interface takes new style certificates and replaces the weblogic.security.SSL.TrustManager interface, which is being deprecated in this release of WebLogic Server.

 

Asymmetric Key Algorithms

Asymmetric key (also referred to as public key) algorithms are implemented through a pair of different, but mathematically related keys: a public key and a private key.

  • The public key (which is distributed widely) is used for verifying a digital signature or transforming data into a seemingly unintelligible form.
  • The private key (which is always kept secret) is used for creating a digital signature or returning the data to its original form.

The Public Key Infrastructure (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.

For information on storage of public and private keys, see Keystore Providers.

 

Symmetric Key Algorithms

With symmetric key algorithms, you use the same key to encrypt and decrypt a message. This common 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.

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

 

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.

 

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. A cipher suite is 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 RSA cipher suites described in Table 2-1.

Cipher Suite

Symmetric Key Strength

TLS_RSA_WITH_RC4_128_SHA 128
TLS_RSA_WITH_RC4_128_MD5 128
TLS_RSA_WITH_DES_CBC_SHA 56
TLS_RSA_EXPORT_WITH_RC4_40_MD5 40
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA 40
TLS_RSA_WITH_3DES_EDE_CBC_SHA 112
TLS_RSA_WITH_NULL_SHA 0
TLS_RSA_WITH_NULL_MD5 0
TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA 56
TLS_RSA_EXPORT124_WITH_RC4_56_SHA 56

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 WebLogic Server 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.

 

Firewalls

A firewall limits traffic between two networks. Firewalls can be a combination of software and hardware, including routers and dedicated gateway machines. They employ filters that allow or disallow traffic to pass based on the protocol, the service requested, routing information, and the origin and destination hosts or networks. They may also allow access for authenticated users.

Figure 2-4 illustrates a typical setup with a firewall that filters traffic destined for a WebLogic Server cluster.

Figure 2-4 Typical Firewall Setup


You can use the following features in WebLogic Server in conjunction with firewalls:

 

Connection Filters

You can use WebLogic Server connection filters to set up firewalls that filter network traffic based on protocols, IP addresses, and DNS node names. For more information, see Using Network Connection Filters" in Programming WebLogic Security.

 

Perimeter Authentication

You can use Identity Assertion providers to set up perimeter authentication - a special type of authentication using tokens. The WebLogic Server security architecture supports Identity Assertion providers that perform perimeter-based authentication (Web server, firewall, VPN) and handle multiple security token types/protocols (SOAP, IIOP-CSIv2).

 

J2EE and WebLogic Security

For implementation and use of user authentication and authorization, BEA WebLogic Server utilizes the security services of the SDK version 1.4.1 for the Java 2 Platform, Enterprise Edition (J2EE). Like the other J2EE components, the security services are based on standardized, modular components. BEA WebLogic Server implements these Java security service methods according to the standard, and adds extensions that handle many details of application behavior automatically, without requiring additional programming.

BEA WebLogic Server's support for SDK 1.4.1 security means that application developers can take advantage of Sun Microsystems' latest enhancements and developments in the area of security, thus leveraging a company's investment in Java programming expertise. By following the defined and documented Java standard, WebLogic Server's security support has a common baseline for Java developers. The innovations that WebLogic Server provides rest on the baseline support for SDK 1.4.1.

The following topics are discussed in this section:

 

SDK 1.4.1 Security Packages

WebLogic Server is compliant with and supports the following SDK 1.4.1 security packages:

 

The Java Secure Socket Extension (JSSE)

JSSE is a set of packages that support and implement the SSL and TLS v1 protocol, making those protocols and capabilities programmatically available. WebLogic Server provides Secure Sockets Layer (SSL) support for encrypting data transmitted across WebLogic Server clients, as well as other servers.

While JSSE provides a core set of classes for SSL functions, other companies, such as Certicom, provide extensions to those classes. WebLogic Server uses the Certicom JSSE extensions in its implementation of SSL.

 

Java Authentication and Authorization Services (JAAS)

JAAS is a set of packages that provide a framework for user-based authentication and access control. BEA WebLogic Server uses only the authentication classes of JAAS.

JAAS is used as follows:

  • For remote Java client authentication
  • For authentication internally in instances of WebLogic Server in the Web and EJB containers and in the WebLogic Authentication and Identity Assertion providers.

For more information on JAAS, see Java Authentication and Authorization Service (JAAS).

 

The Java Security Manager

Developed by Sun Microsystems, Inc., the Java Security Manager is the security manager for the Java Virtual Machine (JVM). The security manager works with the Java API to define security boundaries through the java.lang.SecurityManager class. The SecurityManager class enables programmers to establish a custom security policy for their Java applications.

The Java Security Manager can be used with WebLogic Server to provide additional protection for WebLogic resources running in the JVM. Use of the Java Security Manager to protect WebLogic resources in WebLogic Server is an optional security step.

You can use the Java Security Manager to perform the following security tasks to protect WebLogic resources:

  • Modify the weblogic.policy file for general use.
  • Set application-type security policies on EJBs and Resource Adapters.

    Use the Java security policy file to perform this task.

  • Set application-specific security policies on specific EJBs and Resource Adapters.

    Use the deployment descriptors (weblogic.xml, weblogic-ejb-jar.xml, and rar.xml) to perform this task.

For more information on how to use the Java Security Manager to perform these tasks, see Using the Java Security Manager to Protect WebLogic Resources in Programming WebLogic Security.

 

Java Cryptography Architecture and Java Cryptography Extensions (JCE)

Developed by Sun Microsystems, Inc., these security APIs provide a framework for accessing and developing cryptographic functionality for the Java platform and developing implementations for encryption, key generation and key agreement, and Message Authentication Code (MAC) algorithms.

WebLogic Server fully supports these security APIs.

 

Common Secure Interoperability Version 2 (CSIv2)

WebLogic Server provides support for the Enterprise JavaBean (EJB) interoperability protocol that is based on Internet Inter-ORB (IIOP) (GIOP version 1.2) and the CORBA Common Secure Interoperability version 2 (CSIv2) specification. CSIv2 support in WebLogic Server:

  • Interoperates with the Java 2 Enterprise Edition (J2EE) version 1.4.1 reference implementation.
  • Allows WebLogic Server IIOP clients to specify a username and password in the same manner as T3 clients.
  • Supports Generic Security Services Application Programming Interface (GSSAPI) initial context tokens. For this release, only usernames and passwords and GSSUP (Generic Security Services Username Password) tokens are supported.
Note that the CSIv2 implementation in WebLogic Server passed Java 2 Enterprise Edition (J2EE) Compatibility Test Suite (CTS) conformance testing.

The external interface to the CSIv2 implementation is a JAAS LoginModule that retrieves the username and password of the CORBA object. The JAAS LoginModule can be used in a WebLogic Java client or in a WebLogic Server instance that acts as a client to another J2EE application server. The JAAS LoginModule for the CSIv2 support is called UsernamePasswordLoginModule, and is located in the weblogic.security.auth.login package.

Skip navigation bar  Back to Top Previous Next