![]() |
![]() |
|
|
Overview of the WebLogic Enterprise
Security Service
This topic includes the following sections:
The WebLogic Enterprise Security Service
Security refers to techniques for ensuring that data stored in a computer or passed between computers is not compromised. Most security measures involve proof material and data encryption, where the proof material is a secret word or phrase that gives a user access to a particular program or system, and data encryption is the translation of data into a form that cannot be interpreted.
Distributed applications such as those used for electronic commerce (e-commerce) offer many access points for malicious people to intercept data, disrupt operations, or generate fraudulent input; the more distributed a business becomes, the more vulnerable it is to attack. Thus, the distributed computing software, or middleware, upon which such applications are built must provide security.
The Security Service of the WebLogic Enterprise product lets you establish secure connections between client and server applications. It has the following features:
To access the full features of the WebLogic Enterprise Security Service, you need to install the WebLogic Enterprise Security Pack. The WebLogic Enterprise Security Pack contains the files necessary to enable the use of the SSL protocol, LLE, and PKI. For information about installing the WebLogic Enterprise Security Pack, see the BEA WebLogic Enterprise Installation Guide.
Note: Using Security describes the security features of the T-Engine environment in the WebLogic Enterprise product. For a complete description of using the security features in the J-Engine environment in the WebLogic Enterprise product, see Using WebLogic SSL and Using WebLogic ACLs in the WebLogic Server portion of the online documentation. For a description of the T-Engine and J-Engine environments of the WebLogic Enterprise product, see Getting Started.
Table 1-1 summarizes the features in the Security Service of the WebLogic Enterprise product.
.
Security Features |
Description |
SPI |
Default Implementation |
---|---|---|---|
Proves the stated identity of users or system processes; safely remembers and transports identity information; and makes identity information available when needed. |
Implemented as a single interface |
Provides security at three levels: no authentication, application password, and username/password authentication. Certificate-based authentication is available by installing the WebLogic Enterprise Security Pack. |
|
Controls access to resources based on identity or other information. |
Implemented as a single interface |
N/A |
|
Safely collects, stores, and distributes information about operating requests and their outcomes. |
Implemented as a single interface |
Default auditing security is implemented via the features of the user log (ULOG). |
|
Uses symmetric key encryption to establish data privacy for messages moving over the network links that connect the machines in a WebLogic Enterprise application. |
N/A |
RC4 symmetric key encryption. |
|
SSL protocol |
Uses asymmetric encryption to establish data privacy for messages moving over network links between WebLogic Enterprise domains. |
N/A |
The SSL version 3.0 protocol is only available by installing the WebLogic Enterprise Security Pack. |
Single sign-on |
Propagates the security identity of a WebLogic Server client identity to a WebLogic Enterprise using WebLogic Connectivity. |
N/A |
N/A |
Public key security |
Uses public key (or asymmetric key) encryption to establish data privacy for messages moving over the network links between remote client applications and the IIOP Listener/Handler. Complies with SSL version 3 allowing mutual authentication based on X.509 digital certificates. |
Implemented as the following interfaces:
|
Default public key security supports the following algorithms:
|
The WebLogic Enterprise Security Environment
Direct end-to-end mutual authentication in a distibuted enterprise middleware environment such as the WebLogic Enterprise environment can be prohibitively expensive, especially when accomplished through security mechanisms optimized for long duration connections. It is not effecient for principals to establish direct network connections with each server application, nor is it practical to exchange and verify multiple authentication messages as part of process each service request. Instead,the WebLogic Enterprise product implements a delegated trust authentication model as shown in Figure 1-1.
Figure 1-1 Delegated Trust Model
In a delegated trust model, principals (generally users of client applications) authenticate to a trusted system gateway process. In the case of the WebLogic Enterprise product, the trusted system gateway process is the IIOP Listener/Handler. As part of successful authentication, security tokens are assigned to the initiating principal. A security token is an opaque data structure suitable for transfer between processes.
When a request from an authenticated principal reaches the IIOP Listener/Handler, the IIOP Listener/Handler attaches the principal's security tokens to the request and delivers the request to the target server application for authorization and auditing purposes.
In a delegated trust authentication model, the IIOP Listener/Handler trusts that the authentication software in the WebLogic Enterprise domain will verify the identity of the principal and generates the appropriate security tokens. Server applications, in turn, trust that the IIOP Listener/Handler will attach the correct security tokens. Server applications also trust that any other server applications involved in the process of a request from a principal will safely deliver the security tokens.
A session is established between the initiating client application and the IIOP Listener/Handler in the following way:
The IIOP Listener/Handler retrieves the authorization and auditing tokens from the security context. Together, the authorization and auditing tokens represent the principal's identity associated with the security context.
The protection of messages between the client application and the IIOP Listener/Handler is dependent on the security technology used in the WebLogic Enterprise application. The default behavior of the WebLogic Enterprise product is to encrypt the authentication information but not to protect the message sent between the client application and the WebLogic Enterprise domain. The message is sent in clear text. The SSL protocol can be used to protect the message. If the SSL protocol is configured to protect messages for integrity and confidentiality, the request is digitally signed and sealed (encrypted) before it is sent to the IIOP Listener/Handler.
Single Sign-On in the WebLogic Enterprise Security Environment
A WebLogic Server realm and a WebLogic Enterprise domain are considered separate scopes of security definitions. Each contains it own security database of users and access control. However, by using WebLogic Enterprise Connectivity, the identity of a principal authenticated in a WebLogic Server realm can be presented and used to form the identity of an authenticated principal in a WebLogic Enterprise domain over a connection that is part of a trusted pool of connections.
Note: The single sign-on functionality in the WebLogic Enterprise product is unidirectional. You can only propagate a principal's identity from the WebLogic Server realm to the WebLogic Enterprise domain.
Figure 1-2 illustrates how single sign-on works in the WebLogic Enterprise Security Environment.
Figure 1-2 Single Sign-On in the WebLogic Enterprise Security Environment
When using single sign-on, the security identity of a WebLogic Server principal is propagated as part of the service context of a IIOP request sent to the WebLogic Enterprise domain over a network connection that is part of a trusted connection pool. Each network connection in a trusted connection pool has been authenticated using a defined principal identity. Both username/password and certificate-based authentication can be used to establish a trusted connection pool.
The propagated security identity is used by the IIOP Listener/Handler to impersonate a principal identity in the WebLogic Enterprise domain. The impersonated identity is represented as a pair of tokens: one for authorization and one for auditing. These tokens are propagated to the target server application in the WebLogic Enterprise domain where they are used for authorization and auditing purposes.
To facilitate the mapping of principal identities, the IIOP Listener/Handler uses an authentication plug-in. This plug-in is responsible for mapping the principal identity into the authorization and auditing tokens. These tokens are propagated as part of the request being forwarded to the target EJB or CORBA object. The target EJB or CORBA object can then use these tokens to determine information about the initiator of the request, including the identity of the principal and the role/group name with which the principal is associated.
The SSL protocol can be used to protect the confidentiality and integrity of the request from the WebLogic Server realm. SSL encryption is provided for IIOP requests to CORBA objects in the WebLogic Enterprise domain and RMI on IIOP requests to EJBs and RMI objects. In order to protect the request, both WebLogic Connectivity and the WebLogic Enterprise application must be configued to use the SSL protocol.
For information about implementing single sign-on, see Configuring Single Sign-on.
WebLogic Enterprise Security SPIs
As shown in Figure 1-3, the authentication, authorization, auditing, and public key security features available with the WebLogic Enterprise product are implemented through a plug-in interface, which allows security plug-ins to be intergrated into the WebLogic Enterprise environment. A security plug-in is a code module that implements a particular security feature.
Figure 1-3 Architecture for the WebLogic Enterprise Security Service Provider Interfaces
The WebLogic Enterprise Security Service provides interfaces for the types of security plug-ins listed in Table 1-1.
Plug-In |
Description |
---|---|
Authentication |
Allows communicating processes to mutually prove identification. |
Authorization |
Allows system administrators to control access to WebLogic Enterprise applications. Specifically, an administrator can use authorization to allow or disallow principals to use resources or services provided by a WebLogic Enterprise application. |
Auditing |
Provides a means to collect, store, and distribute information about operating requests and their outcomes. Audit-trail records may be used to determine which principals performed, or attempted to perform, actions that violated the configured security policies of a WebLogic Enterprise application. They may also be used to determine which operations were attempted, which ones failed, and which ones successfully completed. |
Public key initialization |
Allows public key software to open public and private keys. For example, gateway processes may need to have access to a specific private key in order to decrypt messages before routing them. |
Key management |
Allows public key software to manage and use public and private keys. Note that message digests and session keys are encrypted and decrypted using this interface, but no bulk data encryption is performed using public key cryptography. Bulk data encryption is performed using symmetric key cryptography. |
Certificate lookup |
Allows public key software to retrieve X.509v3 digital certificates for a given principal. Digital certificates may be stored using any appropriate certificate repository, such as Lightweight Directory Access Protocol (LDAP). |
Certificate parsing |
Allows public key software to associate a simple principal name with an X.509v3 digital certificate. The parser analyzes a digital certificate to generate a principal name to be associated with the digital certificate. |
Certificate validation |
Allows public key software to validate an X.509v3 digital certificate in accordance with specific business logic. |
Proof material mapping |
Allows public key software to access the proof materials needed to open keys, provide authorization tokens, and provide auditing tokens. |
The specifications for the SPIs are currently only available to third-party security vendors who have entered into a special agreement with BEA Systems, Inc. Customers who want to customize a security feature must contact one of these vendors or BEA Professional Services. For example, a BEA customer who wants a custom implementation of public key security must contact a third-party vendor who can provide the appropriate security plug-in or BEA Professional Services.
For more information about security plug-ins, including installation and configuration procedures, see your BEA account executive.
![]() |
![]() |
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|