|
|
|
|
|
|
| | | |
Introduction to WebLogic Security
The following sections provide an introduction to WebLogic Security including:
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. Proof material is typically a secret word or phrase that gives a user access to a particular application or system. 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 at which malicious people can intercept data, disrupt operations, or generate fraudulent input. As a business becomes more distributed there is an increased probability that security attacks can be perpetrated. Accordingly, as a business distributes its applications, it becomes increasingly important for the distributed computing software upon which such applications are built to provide security.
The security features provided in WebLogic Server let you establish secure connections from Web browsers, Java clients, and other WebLogic Servers to WebLogic Server. In addition, WebLogic Server can be used as a client to BEA Tuxedo over a secure connection.
Specifically, WebLogic Server provides the following security features:
For information about security in WebLogic EJBs, see Programming WebLogic Enterprise JavaBeans.
For information about security in Web applications, see Assembling and Configuring Web Applications.
WebLogic Security Architecture
The security architecture in WebLogic Server is based on the authorization and authentication of Users. Figure 1-1 illustrates the security architecture in WebLogic Server.
Figure 1-1 WebLogic Server Security Architecture
Authentication is the first layer of security in the WebLogic Server environment. Authentication is the process of verifying an entity's identity before completing a connection. Authentication protects who gets access to the WebLogic Server environment.
The default authentication scheme for WebLogic Server is one-way authentication. One-way authentication is common on the Internet where customers want to create secure connections before they share personal data. When WebLogic Server receives a client request, WebLogic Server authenticates the client by comparing the supplied username and password against the usernames and passwords defined in the WebLogic Server security realm. If the username and password can be validated, the client is granted access to the WebLogic Server environment.
If the SSL protocol is used, the establishment of the secure connection requires WebLogic Server to present its digital certificate chain to the client to prove its identity. The client uses a set of digital certificates for certificate authorities it trusts to verify the authenticity of the digital certificate presented by WebLogic Server. When the SSL protocol on a WebLogic Server is configured for two-way SSL, the client is also required to pass a chain of digital certificates that validates its identity.
Once in the WebLogic Server environment, authorization protects who has access to the available resources. Authorization is based on the definition of Users and Groups and the permissions assigned to the resources in WebLogic Server. A resource can be an event, a servlet, JDBC connection pools, passwords, JMS destinations, and JNDI contexts. WebLogic Server uses security realms to logically organize Users, Groups, ACLs, and the permissions for the resources. A WebLogic Server resource is protected under only one security realm by an ACL in that security realm. A User must be defined in a security realm in order to access any resources belonging to that security realm.
When a User attempts to execute a method on a resource, the following steps are taken to determine whether access is permitted:
The following sections describe how WebLogic Server provides security for different types of connections.
Web browsers interact securely with WebLogic Server in the following manner:
The Web server plug-in performs authentication by sending the request, via the HTTP protocol, to the resource in WebLogic Server, along with the authentication data (user ID and password) received from the user.
Figure 1-2 illustrates the secure login process for Web browsers.
Figure 1-2 Secure Login for Web Browsers
The HTTPS protocol provides an additional level of security to this usage scenario. Because the SSL protocol encrypts the data transmitted between the Web browser and WebLogic Server, the user ID and password do not flow in clear text. Therefore, WebLogic Server can authenticate a user while protecting that User's password by using the SSL protocol.
For more information, see the following sections:
Connections with Servlets, JSPs, EJBs, RMI Objects and Java Applications
Servlets, JSPs, EJBs, RMI objects, and Java applications use the Java Authentication and Authorization Service (JAAS) to authenticate WebLogic Server. JAAS is a standard extension to the Java 2 Software Development Kit. The authentication component of JAAS provides the ability to reliably and securely maintain client identity, regardless of whether the code is running as a Java application, a JSP, an EJB, an RMI object or a servlet. In WebLogic Server, JAAS is layered over the existing Security Service Provider Interface (SPI) allowing the continued use of realm-based authorization. This is necessary because WebLogic Server does not provide the authorization component of JAAS. All authorization checking is done through the underlying security realm.
When using JAAS authentication, Java clients enable the authentication process by instantiating a LoginContext object which in turns references a Configuration object. The Configuration object specifies the configured LoginModules to be used for client authentication. The LoginModule object prompts for and verifies the client credentials. It is important to understand that you need to write a LoginModule object for each type of authentication mechanism you want to use with WebLogic Server. For example, if you want to use mutual authentication, you need to provide a LoginModule object that both requests and provides credentials.WebLogic Server does not supply any LoginModule objects.
Clients (servlets, JSPs, EJBs, RMI objects, and Java applications) interact securely with WebLogic Server in the following manner:
When using a LoginModule that implements password authentication, you can configure WebLogic Server to use the SSL protocol. The SSL protocol encrypts the data transmitted between the client and WebLogic Server so that the username and password do not flow in clear text.
Figure 1-3 illustrates the secure login process for servlets, JSPs, EJBs, RMI objects, and Java applications.
Figure 1-3 Secure Login for Java Clients
WebLogic Server can function as a client to another WebLogic Server. In this scenario, WebLogic Server has the same authentication options as a client.
Note: WebLogic Server still supports the JNDI method of passing authentication. However, this functionality is being replaced with JAAS authentication.
For more information, see the following sections:
Connections with Administration Servers
In WebLogic Server, an Administration Server is a WebLogic Server that functions as the central source of all configuration information. An Administration Server may contain configuration information for one WebLogic Server or a cluster of WebLogic Servers. It is important to protect the connection between the Administration Server and the other WebLogic Servers in your environment from eavesdropping, tampering, replay, and impersonation attacks.
When the SSL protocol and certificate authentication are used, the Administration Server presents its digital certificate to the managed WebLogic Server whenever the managed WebLogic Server is started. The managed WebLogic Server then authenticates the Administration Server, using the information in the digital certificate.
Digital certificates for Administration Servers are provided by BEA. They are installed during the installation of WebLogic Server in \wlserver6.1\config\mydomain.
By default, the connection between the Administration Server and other WebLogic Servers is not secure. The file containing usernames and passwords is not encrypted. Usernames and passwords are sent in clear text over the connection, leaving configuration information unprotected. For this reason, we recommend using the SSL protocol and certificate authentication to protect the configuration information in the Administration Server.
Figure 1-4 illustrates the secure login process between Administration Servers and managed WebLogic Servers.
Figure 1-4 Secure Login for Managed and Administration Servers
For more information, see Managing Security.
Using WebLogic Server as a Client to BEA Tuxedo
The scope of security in a WebLogic Server security realm differs from that in a BEA Tuxedo domain. Each contains it own security store of Users and its own access control. However, by using WebLogic Enterprise Connectivity, the identity of a User authenticated in a WebLogic Server security realm can be used to form the identity of an authenticated principal in a BEA Tuxedo domain over a connection that is part of a trusted WLEC connection pool. This functionality is referred to as security context propagation.
Note: The propagation of security context in the WebLogic Server product is unidirectional. It allows you to propagate a User's identity in only one direction: from a WebLogic Server security realm to a BEA Tuxedo domain.
Figure 1-5 illustrates how the propagation of the security context between the WebLogic Server and the BEA Tuxedo environments works.
Figure 1-5 Propagation of the Security Context Between WebLogic Server and BEA Tuxedo
When propagating the security context, the security identity of a WebLogic Server User is included as part of the service context of an IIOP request. This request is sent to a BEA Tuxedo domain over a network connection that is part of a pool of WLEC connections. Each network connection in a WLEC connection pool is authenticated using a defined User identity. Both password and certificate authentication can be used to establish a WLEC connection pool.
The propagated security identity is used by the IIOP Listener/Handler to impersonate a User identity in the BEA Tuxedo 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 CORBA object in the BEA Tuxedo domain, where they are used for authorization and auditing.
To facilitate the mapping of User identities, the IIOP Listener/Handler in BEA Tuxedo uses an authentication plug-in. This plug-in is responsible for mapping the User identity into the authorization and auditing tokens. These tokens are propagated, in turn, as part of the request being forwarded to the target CORBA object. The target CORBA object can then use the tokens to determine information about the initiator of the request, including the identity of the User and the Role or Group name with which the User is associated.
The SSL protocol is used to protect the confidentiality and integrity of the request sent from the WebLogic Server security realm. SSL encryption is provided for IIOP requests sent to CORBA objects in the BEA Tuxedo domain. To protect a request, both WebLogic Connectivity and the BEA Tuxedo CORBA application must be configured to use the SSL protocol.
For more information, see the following sections:
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|
