BEA Home | Events | Solutions | Partners | Products | Services | Download | Developer Center | WebSUPPORT
| WebLogic Server Doc Home | Security | Previous Topic | Next Topic | Contents | View as PDF

Introduction to WebLogic Security

The following sections provide an introduction to WebLogic Security including:

- WebLogic Security Features

- WebLogic Security Architecture

- Using WebLogic Server as a Client to BEA Tuxedo

WebLogic Security Features

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:

- Security realms which represent a logical grouping of Users, Groups, ACLs, and permissions for the purpose of protecting WebLogic Server resources. You can use the default security realm or one of a set of alternative security realms that allow you to use Windows NT, UNIX, and LDAP security stores. In addition, custom developed security realms are supported.

- Authentication of clients requesting access to WebLogic Server resources. Authentication can be accomplished using a username/password combination or digital certificates where a client is authenticated using the identity inside of the X.509 digital certificate provided to WebLogic Server as part of a Secure Sockets Layer (SSL) connection.

- Authorization of Users and Groups through access control lists (ACLs).

- The Java Authentication and Authorization Service (JAAS) application programming interface (API) for authentication. The JAAS implementation in WebLogic Server provides LoginContext authentication and Subject authorization. Support for JAAS authorization is not provided.

- Data integrity and confidentiality through the SSL protocol. Clients can establish SSL sessions with WebLogic Server using the Hypertext Transfer Protocol (HTTP), the BEA proprietary T3 protocol, or the Remote Method Invocation (RMI) over Internet Inter-ORB (IIOP) protocol.

- Auditing of events such as failed login attempts, authentication requests, rejected digital certificates and invalid ACLs.

- Filtering of client connections for the purpose of accepting or rejecting the client request based the origin (host name or network address) or protocol of the client.

- Propagation of the security context from WebLogic Server security realms to BEA Tuxedo domains using WebLogic Enterprise Connectivity (WLEC). This feature allows the propagation of security information about the requesting WebLogic Server User to the BEA Tuxedo domain over network connections that are part of a trusted WLEC connection pool.

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:

1. If the resource is protected and the User has not previously been authenticated, the User is requested to authenticate. If the authentication fails, the request is rejected.

2. WebLogic Server identifies the User invoking the method. If the user cannot be determined, the request is rejected.

3. WebLogic Server determines the set of required permissions to invoke the method on the WebLogic Server resource.

4. If the invoking User has at least one of the required permission, WebLogic Server allows the method to be invoked.

The following sections describe how WebLogic Server provides security for different types of connections.

Connections with Web Browsers

Web browsers interact securely with WebLogic Server in the following manner:

1. A user invokes a resource in WebLogic Server by entering the URL for that resource in a Web browser.

2. The Web server in WebLogic Server receives the request. WebLogic Server provides its own Web server but also supports the use of Apache Server, Microsoft Internet Information Server, and Netscape Enterprise Server as Web servers.

3. The Web server checks whether the WebLogic Server resource is protected by an ACL. If the WebLogic Server resource is protected, the Web server uses the established HTTP connection to request a user ID and password from the user.

4. When the user's Web browser receives the request from WebLogic Server, it prompts the user for a user ID and password.

5. The Web browser sends the request again, along with the user ID and password.

6. The Web server forwards the request to the Web server plug-in. WebLogic Server provides the following plug-ins for Web servers:

   - Apache-Weblogic Server plug-in

   - Netscape Server Application Programming Interface (NSAPI)

   - Internet Information Server Application Programming Interface (ISAPI)

     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.

7. Upon successful authentication, WebLogic Server determines whether the user has the permissions necessary to access the resource.

8. If authorization succeeds, the servlet engine fulfills the request. The servlet engine resides within WebLogic Server.

9. Before invoking a method on the servlet, the servlet engine performs a security check. During this check, the servlet engine extracts the User's credentials from the security context and verifies that the User is authorized to invoke the method on the servlet.

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:

- Managing Security

- Configuring the Apache Server Plug-In

- Configuring the Microsoft-IIS Plug-In

- Configuring the Netscape Plug-In

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:

1. The client creates a LoginContext which instantiates a LoginModule object and a CallbackHandler object.

   - The LoginContext references a Configuration object which specifies the LoginModules and their order of execution.

   - The CallbackHandler object gathers input from users (such as a password or the name of a digital certificate file) and passes it in turn to the LoginModules.

2. The client invokes the login() method of the LoginContext object. The login() method then invokes the specified LoginModules.

3. The LoginModule prompts for and verifies the client credentials.

4. Upon successful authentication, WebLogic Server determines whether the client has the permission required to access the requested resource. The permission is determined by the ACL for the resource as defined in the WebLogic Server security realm.

5. Upon successful ACL authorization, the client request from the client is fulfilled by WebLogic Server.

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:

- Programming with the WebLogic Security SPI

- Managing Security

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:

- "Configuring Security Context Propagation" in Managing Security

- Using WebLogic Connectivity

Copyright © 2001 BEA Systems, Inc. All rights reserved. Required browser: Netscape 4.0 or higher, or Microsoft Internet Explorer 4.0 or higher.