|
|
|
|
| |
WebLogic Server Administration
In addition to providing a rich runtime environment for multitier applications, an application server must be robust, scalable, and secure. This chapter describes WebLogic Server facilities for security, monitoring and tuning performance, and for clusters, which make it possible to deploy multiple WebLogic Servers to support increasing numbers of clients with failover capabilities.
This chapter covers the following topics:
WebLogic Server Administrative Facilities
WebLogic Server includes a variety of administrative tools. The weblogic.properties file, a Java properties file, is the primary method for configuring WebLogic Server. The WebLogic Console is a graphical administration tool you can use to monitor and manage a running WebLogic Server. You can view WebLogic Server administrative information in a web browser using the Admin servlets. Finally, WebLogic Server includes several command line utilities that you can use to administer the server.
Configuring WebLogic Server
WebLogic Server is primarily configured with a Java properties file, named weblogic.properties. The file is located in the WebLogic Server installation directory. If you use WebLogic clusters, there is one cluster-wide properties file and an optional individual per-server properties file for each WebLogic Server participating in the cluster. See WebLogic Server Clusters in this chapter for more about clusters.
WebLogic Server is distributed with a default weblogic.properties file with properties set so that you can get WebLogic Server running quickly. You can edit the weblogic.properties file with any text editor that saves pure ASCII text.
If you installed with the zip file distribution, you must edit the file and set the password for the "system" user before you can run WebLogic Server. You should also search the file for file and directory names and edit them for your environment.
You can learn about many properties by exploring the properties file. It is heavily commented, and includes many properties that are described, but commented-out. You can find online documentation for all WebLogic Server properties in Setting WebLogic Properties.
The WebLogic Console
The WebLogic Console is a Java application that you can use to monitor and administer WebLogic Server. Here are some of the things you can do with the WebLogic Console:
The WebLogic Console displays a hierarchical tree in its left pane and information about the selected object in the tree in its right pane. The right pane has a Properties tab that displays information about the selected object. Some objects have a Commands tab that you can use to administer the object.
Here is an example of the Console's display for the Emp Enterprise JavaBean example:
See Using the WebLogic Console for help using the Console.
WebLogic Server Security
WebLogic Server provides a comprehensive security architecture encompassing access control, cryptography-based privacy, and user authentication.
User-level and group level ACLs (access control lists), Realms, SSL (Secure Sockets Layer), and digital certificates are all standards-based security measures used in the WebLogic Server. Used together, these security features track who has access to what services. A developer can restrict access to some WebLogic services through application logic at design time and the system administrator can also define how services are accessed at deployment. Additionally, WebLogic Server can operate independently from other security services or be incorporated into a single-sign-on solution by accessing existing security information stores.
Specifying security through the properties file allows easy prototyping and allows basic production systems to be up and running very quickly. For installations with more complex security needs, WebLogic Server includes support for integrating with other security services.
Users and Groups
WebLogic Server security begins with a specification of users. Users are entities that will connect to WebLogic Server and access WebLogic services. Users may be human end-users, other applications, or even other servers, such as web servers, proxy servers, or WebLogic Servers.
In the simplest case, the WebLogic Server administrator defines the names and passwords of users in the weblogic.properties file, which WebLogic Server reads at startup time. Users can be combined into groups for role-based authorization by setting additional properties in the file.
Defining Users
You define a user with a weblogic.password property. For example, to add the WebLogic user "joeuser" with password "joesPassword," you add this property to the weblogic.properties file:
weblogic.password.joeuser=joesPassword
WebLogic Server passwords must have at least 8 characters. You can require longer passwords by changing the weblogic.system.minPasswordLen property in the weblogic.properties file.
Defining Groups
A group allows you to assign permissions to groups of users. You create a group by adding a weblogic.security.group property in the weblogic.properties file. For example, to create a "managers" group containing users "bill," "ed,", and "al" you first define the users, and then the group, using properties like these:
weblogic.password.bill=billsPassword
weblogic.password.ed=PasswordOfEd
weblogic.password.al=alsPassword
weblogic.security.group.managers=bill,ed,al
Special Users and Groups
WebLogic Server defines two special users, "system" and "guest." The password for the "system" user must be defined in the weblogic.properties file before you can start WebLogic Server. If you install WebLogic Server on Windows NT using the InstallShield distribution, the "system" password is set as part of the installation process. Otherwise, you must edit the weblogic.properties file and set the password before you can run WebLogic Server.
The "system" user has administrative privileges in WebLogic Server and is needed to initialize internal services when WebLogic Server starts up. The "system" user account must also be used to perform activities such as shutting down WebLogic Server. The default weblogic.properties file restricts some capabilities to the "system" user.
The "guest" user is the default identity for unauthenticated WebLogic users. If a user does not provide a specific identity when connecting, WebLogic Server assigns the "guest" identity and permits only those activities allowed for the "guest" user. You do not have to define the "guest" user; it is created automatically (with the password "guest"). You can add a weblogic.password.guest property to change this user's password.
WebLogic Server provides a default "everyone" group, which includes all users. Permissions assigned to this group are available to any user.
Authentication
Since security requirements vary greatly, WebLogic Server is configurable to allow different levels of authentication depending upon the needs of the deployment. When a client, administrator, or peer wants to access a protected WebLogic resource, client authentication is required. When a browser wants to establish a secure connection to WebLogic Server, server authentication is required.
WebLogic Server supports two mechanisms, defined by the HTTP protocol, to authenticate users: basic (username and password) and strong (digital certificates). Developers can create application-specific authentication mechanisms, which is a common feature of many web-based commercial applications.
Basic Authentication
Basic authentication is accomplished by requiring users to supply their usernames and passwords for authentication. When a web browser user requests a protected HTML page, HTTP Servlet, or JSP page, the browser displays a dialog box requesting a username and password. WebLogic Server passes the username and password to the WebLogic security realm for authentication.
A Java application performs basic authentication by including the username and password with the information it sends to WebLogic Server to establish a JNDI connection.
Some resources are intentionally unprotected-public HTML pages, for example. For unprotected resources, WebLogic Server allows unauthenticated users to assume the "guest" user identity within the WebLogic security realm. This is transparent to end users.
Strong Authentication
Strong authentication is accomplished by establishing a secure connection using SSL (Secure Sockets Layer). SSL is a standard developed by Netscape for secure connections on the web.
SSL defines a protocol that allows clients and servers to authenticate each other using certificates, and then to negotiate algorithms for encrypting the data they exchange. The certificates are based on public key encryption. With public key encryption, two files are generated for a user or server: a public key and a private key. Anyone who has the public key can encrypt data and transmit it. But the data can only be decrypted using the corresponding private key. Therefore, the private key is always stored locally-installed in a user's browser or on their local hard disk, or in a server's file system-and never transmitted over the network.
To obtain a certificate, a request containing the public key is submitted to a trusted third party called a Certificate Authority (CA). WebLogic Server supports the VeriSign and GTE CyberTrust CAs out-of-the-box. The CA verifies the identity of the user or server and returns a digitally-signed certificate that includes the public key and the CA's certificate.
Most web-based applications use certificates to authenticate the server (web server or application server) to the client (web browser). By checking the server's certificate, the client verifies that it has connected to the intended server. A web browser checks the server's certificate to ensure that it was issued by a recognized CA, that it has not expired, and that the server is running at the DNS name specified in the certificate. The web browser alerts the user when a problem is detected with the certificate.
Applications that require authenticated clients generally use password authentication rather than requiring users to present certificates. During the SSL negotiation, the server's certificate is authenticated and a secure, encrypted connection is established between the server and client. Then the client's username and password can be obtained using the basic authentication mechanism, and transmitted to the server securely.
For very high-security enterprise applications, WebLogic Server can be configured to require clients to present certificates issued by selected CAs. This requires every user to obtain a certificate from one of the approved CAs.
Authenticating a client certificate does not provide an identity for a client; it just establishes the client as a trusted entity. Although the client's identity can be extracted from the certificate, this is not an automatic side effect of the SSL negotiation. The WebLogic Server distribution includes an example to demonstrate how to extract a user's identity from their certificate. When a WebLogic Server user identity is required and none has been supplied, WebLogic Server initiates basic authentication, even when the client has been authenticated with a certificate.
Authorization
WebLogic Server uses the Java ACL standard, distributed with JDK 1.1 and later, to extend the security framework of Java and make it practical for use at the enterprise level.
An ACL (Access Control List) is a structure with three parts:
A permission is the ability to carry out a certain operation on a WebLogic Server resource. Some examples of permissions are "execute" permission for an HTTP Servlet or JSP, and "reserve" permission for a JDBC connection pool.
In the default WebLogic Server configuration, ACLs are defined in the properties file and read by WebLogic Server at startup time. Dynamic ACLs are possible using a custom realm, as described in the next section.
ACLs are used to regulate and limit access to the majority of WebLogic Server services. Each of the following services can be protected by ACLs:
ACLs are defined in the weblogic.properties file with weblogic.allow properties. The format for this property is:
weblogic.allow.permission.resource={user|group}[,user|group]...
A permission is a resource-dependent string, such as "execute" for servlets or "lookup" for JNDI. See the complete list of permissions in Using WebLogic Realms and ACls.
A resource is the name of a protected object or service in WebLogic Server.
For example, the "classes" servlet is registered and protected with these properties:
weblogic.httpd.register.classes=weblogic.servlet.ClasspathServlet
weblogic.allow.execute.weblogic.servlet.classes=everyone
The name of the servlet is "classes," as defined by the weblogic.httpd.register property. The ACL for the servlet grants the "execute" permission to the "everyone" group.
See Using WebLogic Realms and ACLs for examples of ACLs for each type of protectable WebLogic Server resource.
Security Realms
A security realm organizes security information and defines its range of operations. A WebLogic realm combines users, groups, permissions, and ACLs. It determines how a user is authenticated and retrieves users, groups, and ACLs for protected resources.
When a user attempts to access a given WebLogic Server resource, the server calls into the realm to:
This abstraction of users and groups into realms allows you to substitute an enterprise-wide security data store for the security-related properties defined in the WebLogic Server properties file.
WebLogic includes a number of default realm extensions providing out-of-the-box security by linking to standard authentication and authorization stores, such as various LDAP servers and the Windows NT security domain. A developer can also build a custom security realm by using and extending Java classes provided with WebLogic Server. To help with this task, WebLogic Server includes an RDBMS realm example.
For example, you might prefer to use the execute permissions associated with a UNIX file system for a set of servlets stored on the UNIX computer. To enable this, WebLogic Server can defer authentication of users to UNIX and reflect access control to UNIX files in Java.
It is often necessary for security policies to be changed dynamically as new users are added and situations change. WebLogic Server can dynamically update users and groups by leveraging an external centralized security database or service such as LDAP or Kerberos.
Additional Security Considerations
WebLogic Server inherits security features from its Java environment, and from its operating system and network environments.
The Java language and runtime environment provide several built-in security features. The JVM verifies the bytecodes in a Java class file to ensure that they follow established safety rules before they are executed. This protects the JVM against class files generated by non-compliant Java compilers. The Java class loader ensures that Java class files it loads do not attempt to override existing classes. This prevents an attempt to circumvent other security measures provided by the Java runtime environment.
Java 1.2 adds a security policy feature that makes it possible to grant specific permissions to Java class files based on their point of origin. For example, you can prevent servlets loaded from a specified directory from performing any disk I/O operations.
The JVM protects itself from corruption by common programming logic errors. Such errors are caught and reported in the WebLogic Server log file. In most cases, the thread executing the errant code is unable to complete its task, but the WebLogic Server is not otherwise compromised.
The operating system on the computer running WebLogic Server can be, and should be, configured to protect the WebLogic Server installation. On a UNIX computer, you should create a WebLogic Server user and run WebLogic Server as that user. All files and directories in the WebLogic Server installation directory should belong to the WebLogic Server user and that user should have exclusive read and write access on its files and directories.
WebLogic Server also relies on the operating system to ensure the integrity of the file system it depends upon. Regular backups and other measures, such as mirrored disks, can ensure fast recovery from hardware failures.
The network environment may contain a variety of security enhancements including firewalls and proxy servers that restrict access to WebLogic Server outside of the firewall. WebLogic Server can be configured to work cooperatively with these facilities. Java clients can be permitted to tunnel to WebLogic Server over HTTP, which allows them to establish connections with WebLogic Server through a firewall or proxy.
WebLogic Server depends upon backend services, especially database servers, to provide their own security and recovery facilities. WebLogic Server uses a database to store persistent objects, including Enterprise JavaBeans and JMS messages. Therefore, database integrity is essential to WebLogic Server applications that use these features.
Administrative Utilities
The WebLogic Server distribution includes many Java utility programs that are useful for administering WebLogic Server, verifying your configuration, or diagnosing problems with your configuration. This section introduces some of these utilities.
For complete documentation on these and other WebLogic utilities, see Using the WebLogic Utilities and Running and Maintaining WebLogic Server.
General Information Utilities
Database-related Utilities
Setting up multitier database connections and JDBC connection pools requires setting up a JDBC driver and configuring two two-tier connections. The utils.dbping and utils.t3dbping utilities are useful to isolate and test the connections individually.
utils.Schema
weblogic.Admin Class
The weblogic.Admin class is a Java command line application that understands several WebLogic Server administration commands. weblogic.Admin has at least two arguments-the WebLogic Server URL and the command name-and may require additional arguments, depending on the command you choose.
ZAC (Zero Administration Client)
ZAC makes it easy to install and update Java applications, libraries, and applets on client computers. The ZAC Publisher is a GUI utility that you use to define and publish a client application on a WebLogic Server. You select the files that an application comprises, define dependent files or ZAC packages, and publish the package on one or more WebLogic Servers. Later, you can update the contents of a package and republish it.
You also use the ZAC publisher to create small native executable installers for each platform your application supports. You distribute the installer to clients, either in e-mail, an ftp link on a web page, on a network drive, or any other method you choose.
Clients get the installer for the package they want to install and run it to begin the installation. The installer contacts WebLogic Server and determines which files must be transferred to the client computer and transfers just those files.
Applications published with ZAC can use the ZAC API to automatically update themselves.
See Publishing with WebLogic ZAC for help creating and publishing ZAC packages. See Using WebLogic ZAC for more about using the ZAC API in your Java applications.
Performance Packs
A performance pack is a BEA-supplied native library that uses operating system calls to manage multiplexed I/O for WebLogic Server socket connections.
Operating systems provide system-level calls that monitor a set of file descriptors for I/O activity on behalf of the caller. The standard Java networking package does not provide access to these system calls-each WebLogic Server connection is represented by a Java Socket object that must be managed independently within WebLogic Server. Using a performance pack, WebLogic Server benefits from the more efficient multiplexing services provided by the operating system, resulting in a significant performance improvement.
Check the Platform support page to see if a performance pack is available for your platform. To use a performance pack, you must use a JVM with native threads.
The performance pack is enabled by default for Windows NT. To enable the performance pack for other supported platforms, just add this property to your weblogic.properties file:
weblogic.system.nativeIO.enable=true
WebLogic Server Clusters
A WebLogic Server cluster provides scalability and availability by deploying multiple, cooperating WebLogic Servers behind a single network name.
A cluster promotes scalability by allowing you to add WebLogic Servers to handle increasing numbers of clients. A cluster provides availability by providing automatic failover when a WebLogic Server fails or becomes unavailable for some reason. For example, if you take a WebLogic Server out of service for maintenance, other WebLogic Servers in the cluster pick up the server's load.
Cluster Architecture
WebLogic Servers participating in a cluster can execute on heterogeneous hardware and operating systems. Each server has its own memory and disk, although a shared network disk makes it much easier to set up and maintain a cluster.
To participate in a cluster, a WebLogic Server must be accessible at a unique, static IP address, and it must be accessible by IP multicast. This means that all WebLogic Servers participating in a cluster must be on the same LAN, since multicast is not available on the Internet.
Initial load-balancing and failover are accomplished using DNS. With DNS, you map a cluster name to every WebLogic Server IP address so that the cluster appears to clients as a single network host. When multiple addresses are mapped to the same name, a DNS lookup on the name returns the entire list of addresses. If you use the standard bind service for DNS, the addresses on the list are rotated on each request so that consecutive requests are directed to the participating WebLogic Servers in a round-robin fashion. You can substitute software or hardware for bind to implement more sophisticated load-balancing algorithms.
If the WebLogic Server at an address fails to respond, the client (web browser or Java application) tries the next address on the list, providing transparent failover.
WebLogic Server clustering differs for HTTP requests and server objects accessed through JNDI, such Enterprise JavaBeans and RMI classes. For HTTP requests, the initial DNS round-robin algorithm determines which WebLogic Server will service the HTTP request. For JNDI objects, the initial DNS lookup selects a WebLogic Server to handle JNDI naming services. But when you use that naming service to look up an object, a different WebLogic Server in the cluster is chosen for the object, based on the capabilities of individual servers in the cluster and the characteristics of the object. EJB and RMI support pluggable load-balancing algorithms that can override a cluster-wide load-balancing algorithm set in the cluster's properties file.
HTTP Clustering
Servlet session data can be replicated among servers in the cluster using either JDBC persistence or in-memory replication. Session replication allows any server in the cluster to handle any request on a servlet without losing a client's session context. With JDBC persistence, sessions are stored in a database or file accessible by all servers in the cluster. With in-memory replication, which is recommended for best performance, session data is exchanged among WebLogic Servers over the network.
If you put all HTML and servlet files in a directory on a shared file system, every WebLogic Server can serve HTTP requests from the same directory. Otherwise, you must mirror the files to each WebLogic Server's directory.
RMI and EJB Clustering
RMI and EJB objects rely upon a single cluster-wide JNDI naming tree. Clustered services advertise on the cluster-wide JNDI name tree, which is replicated across the cluster so there is no single point of failure. To offer a clustered service, a WebLogic Server advertises a provider at a node in the replicated naming tree. Each server adds a stub for that provider to a service pool stored in its copy of the naming tree.
Both RMI and EJB send remote stubs to their clients. The stubs manage communications between the client and the associated server-side objects. Stubs delivered to the client can be clusterable or nonclusterable. Consecutive calls on clusterable stubs may be handled by any WebLogic Server in the cluster, depending on load-balancing and failover requirements when a call is made. With a non-clusterable stub, all calls on a stub are handled by the WebLogic Server that initially delivered the stub to the client. Clusterable stubs can failover transparently; nonclusterable stubs cannot.
Some RMI and EBJ objects must not be clustered because they have state in the server-side object. The client must always interact with the same instance of the object on the same WebLogic Server. In this case, you can take advantage of load-balancing and failover up to the point where a stateful object is instantiated. For example, an EJB home interface has no state and is clusterable. You can look up an EJB home and retrieve a clusterable stub. But when you use a method on the home interface to create or look up a stateful session bean or entity bean, you get a non-clusterable stub. All calls you make on the bean are handled on the WebLogic Server where the bean was instantiated. A remote object with nonclusterable stubs is said to be "pinned" to the WebLogic Server where it lives.
To take advantage of clustering with stateful objects, you can wrap operations in transactions and then, if the host WebLogic Server fails, look up the object again and reapply the transaction. For example, if the WebLogic Server hosting an entity bean instance fails, you can use the same home interface to look up or create the bean again. The home interface has a clusterable stub and failover capability, so it will automatically choose another WebLogic Server to host the new bean instance.
Unlike EJB, RMI does not define categories of stateful and stateless objects, so you must intentionally "pin" a stateful RMI object to its server. One way to do this is to emulate the EJB home interface by looking up a clusterable factory method in the replicated JNDI tree. Calls on the factory method can execute on any server in the cluster, but objects that you create with the factory are pinned to their server.
You can also go directly to a specific WebLogic Server in a cluster, bypassing the cluster-wide JNDI name tree, to look up an EJB or RMI class. This ensures that your remote objects are pinned to the selected server, but does not take advantage of load balancing.
JDBC clustering
WebLogic JDBC connection pools can be registered in the replicated naming tree so that applications can advantage of load balancing and failover provided by a WebLogic Server cluster.
In the usual case, each WebLogic Server in the cluster is configured with a JDBC connection pool that accesses the same back-end DBMS instance. Each WebLogic Server then has a pool of connections to the same database. A connection pool is registered in the naming tree by defining a DataSource property in the weblogic.properties file.
You could use different database instances for each WebLogic Server if your application does not require a shared database, or if the DBMS has replication or mirroring services that make it possible for the various database instances to behave as a single instance.
A client uses the WebLogic JDBC/RMI JDBC driver to get a database connection from a cluster. This driver, new in WebLogic Server version 5.1, makes it possible to get a database connection from a pool using JNDI. When a client looks up the DataSource name for a connection pool, the load-balancing algorithm selects the WebLogic Server that will serve the request. Since a JDBC connection maintains state on WebLogic Server, a JDBC connection is pinned to the WebLogic Server that is selected to serve a client's request.
See Using WebLogic JDBC/RMI and Clustered JDBC for information about clustered JDBC.
Non-clustered Services in a WebLogic Server Cluster
WebLogic JMS is not a clustered service in the current WebLogic Server release. If you use JMS, select one WebLogic Server in the cluster to provide JMS services for the cluster and configure JMS in its per-server properties file. More importantly, do not configure any other WebLogic Server for JMS. When the WebLogic Server configured for JMS starts up, its JMS ConnectionFactories, Queues, and Topics, are added to the cluster-wide JNDI tree. Any client that looks up a JMS object is then directed to the WebLogic Server that is configured for JMS.
More about WebLogic Clusters
To learn more about WebLogic clusters, refer to these documents:
See Setting up a WebLogic Cluster for help setting up clustering.
See Using WebLogic Clusters for help developing clustered WebLogic Server applications.
See Using WebLogic JDBC/RMI and Clustered JDBC for help with setting up and using clustered JDBC.
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|