When using SSL with WebLogic Server, use keystores; storing identity (private keys and certs) and trust (CA) in files is deprecated. Migrating from an earlier version might require you to create keystores from private keys, certs, or trust files.
If the network that connects WebLogic Server in a domain is not trusted, enable SSL on each server in the domain, so that LDAP replication between the admin server and managed servers uses SSL connections. Enabling an administration port in the domain requires that all servers use SSL.
The default WebLogic installation represents exportable-strength SSL implementation (the maximum SSL strength is 512-bit keys with 40-bit bulk encryption). Key lengths longer than 512 bits require a domestic-strength SSL license key from BEA. If you use SSL in your production environment, use high-strength SSL. Key lengths of less than 1024 bits are generally considered weak.
SSL hardware accelerators:
Running SSL on the WebLogic servers is a tremendous drain on server resources. By offloading SSL processing, the resources can be applied to WebLogic functions. Web servers, load balancers, firewalls, or switches can handle SSL processing.
Filtering them can control incoming connections in WebLogic Server. WebLogic Server provides a default implementation of connection filter that you can configure in the admin console.
Tips
1. In production, do not use the sample SSL certificates that are provided with WebLogic.
2. To avoid compromising application security, install and configure server-specific SSL
certificates and enable hostname verification on production servers.
3. Use SSL with WebLogic Server only if it is necessary. SSL degrade performance.
4. To control the types of connections accepted by WebLogic Server instances, use connection filters.
5. Use load balancer with built-in secure sockets layer (SSL) support, or run WebLogic Server on a machine that has SSL hardware, with Java Cryptography Extension (JCE)
Friday, 7 December 2007
To recover the administrator password in a WebLogic domain
When using the default authenticator, if you have not modified the global admin role (which, by default is granted to the administrators group), you can recover the administrator password in a WebLogic domain.
To recover the administrator password in a WebLogic domain:
1. At the command line, change directory to the domain and run the setEnv script to set the PATH and CLASSPATH.
2. Backup the existing DefaultAuthenticatorInit.ldift file in a different directory.
3. java -cp D:\bea\weblogic700\server\lib\weblogic.jar weblogic.security.utils.AdminAccount adminuser weblogic . (Be careful: there is a dot at the end of the command).
4. rm myserver/ldap/DefaultAuthenticatormyrealmInit.initialized
5. rm boot.properties (if any)
6. Reboot the admin server with "adminuser" as administrator userid
7. After the server has successfully booted, delete the new DefaultAuthenticatorInit.ldift file and replace it with the backed up file. If you don't perform these steps in the correct sequence or if you create a DefaultAuthenticatorInit.ldift file by hand, a cleartext password may be available.
To recover the administrator password in a WebLogic domain:
1. At the command line, change directory to the domain and run the setEnv script to set the PATH and CLASSPATH.
2. Backup the existing DefaultAuthenticatorInit.ldift file in a different directory.
3. java -cp D:\bea\weblogic700\server\lib\weblogic.jar weblogic.security.utils.AdminAccount adminuser weblogic . (Be careful: there is a dot at the end of the command).
4. rm myserver/ldap/DefaultAuthenticatormyrealmInit.initialized
5. rm boot.properties (if any)
6. Reboot the admin server with "adminuser" as administrator userid
7. After the server has successfully booted, delete the new DefaultAuthenticatorInit.ldift file and replace it with the backed up file. If you don't perform these steps in the correct sequence or if you create a DefaultAuthenticatorInit.ldift file by hand, a cleartext password may be available.
Security Vs Weblogic Domain
Never use development mode for production servers; development mode relaxes the security constraints for all servers in a domain. When using compatibility security, disable guest logins in production, so that guest logins cannot be used to access WebLogic resources in a WebLogic Server domain.
When you are creating a security policy, if inherited policy statements are present in the Inherited Policy Statement box of the Policy Editor page, the new policy overrides them. Changing a security policy defined in a J2EE deployment descriptor requires redeployment; changing an embedded LDAP policy in the admin console is dynamic. Configure additional administrative users to roles such as admin, deployer, monitor or operator.
SerializedSystemIni.dat contains hashes for the passwords in a domain; ensure that you store a copy of this file in a safe place. Give read privileges for SerializedSystemIni.dat only to the WebLogic system administrator account. If you lose the administrative password, and the boot identity is not stored in the form of boot.properties file, you cannot restart servers.
Tips
1. Store the encrypted boot identity of the user who has privileges to start WebLogic Server in the boot.properties file.
2. BEA recommends using security roles (rather than users or groups) to secure WebLogic resources; first assign users to groups, then create role statements.
3. Do not install or run WebLogic Server software as root. If you must bind to a privileged port, use post-bind UID or post-bind GID in the WebLogic machine configuration.
4. Set the ownership of the WebLogic installation and applications directory for access only by the user account that runs the server.
When you are creating a security policy, if inherited policy statements are present in the Inherited Policy Statement box of the Policy Editor page, the new policy overrides them. Changing a security policy defined in a J2EE deployment descriptor requires redeployment; changing an embedded LDAP policy in the admin console is dynamic. Configure additional administrative users to roles such as admin, deployer, monitor or operator.
SerializedSystemIni.dat contains hashes for the passwords in a domain; ensure that you store a copy of this file in a safe place. Give read privileges for SerializedSystemIni.dat only to the WebLogic system administrator account. If you lose the administrative password, and the boot identity is not stored in the form of boot.properties file, you cannot restart servers.
Tips
1. Store the encrypted boot identity of the user who has privileges to start WebLogic Server in the boot.properties file.
2. BEA recommends using security roles (rather than users or groups) to secure WebLogic resources; first assign users to groups, then create role statements.
3. Do not install or run WebLogic Server software as root. If you must bind to a privileged port, use post-bind UID or post-bind GID in the WebLogic machine configuration.
4. Set the ownership of the WebLogic installation and applications directory for access only by the user account that runs the server.
Stateless Session EJB
A stateless session EJB free pool improves performance and throughput as beans are created at server startup or deployment time. WebLogic Server uses a cache of bean instances to improve the performance of stateful session EJBs. The cache stores active EJB instances in memory so that they are immediately available for client requests.
Using application-level/combined cache will result in reduced fragmentation, better utilization of memory and heap space. But the use of application-level/combined cache is limited to entity EJBs in an enterprise application. For an application that requires high throughput, use bean-level caching. Bean-level caching is effective because tasks do not compete for control of the one thread of control in a combined cache.
To make use of WebLogic provided optimization of calls made to EJB components within an application, set to true.
The same can also be achieved by writing local interfaces for EJBs for access within the same enterprise application.
Concurrency strategies for entity EJBs include:
Database:Improves throughput by deferring to database (for EJB 1.1 and 2.0, this is the default and recommended mechanism)
Exclusive:Avoids deadlocks; use it only if a high level of consistency is required on non-clustered servers
Optimistic:No lock will be held in the EJB container or database during transaction. But the EJB container ensures that the data being updated by a transaction has not been changed.
Read-only:Container does not attempt to save a bean's state at the end of a transaction; use this for EJBs that do not make any change to persistent data. With the read-only strategy, use to invalidate cached bean data in the container; this updates the data from the persistent store when a timeout occurs.
Tips
1. Consider the number of execute threads, to configure maximum number of beans in the free pool.
2. To limit the memory used by a stateful session EJB, set the maximum number of beans that can reside in the cache (max-beans-in-cache).
3. Too small cache causes frequent activation and passivation.
4. Too large a cache wastes memory.
5. LRU algorithm keeps a bean in the passive state after it passes the ideal number timeout seconds.
6. To avoid the associated overhead of passivating stateful session EJBs, use the not recently used (NRU) algorithm
7. Local interfaces for EJBs provide optimized access for server-side EJB clients.
8. Combined cache enables the administrator to tune just one cache, rather than multiple caches, in weblogic-application.xml.
9. Message-driven beans that use container-managed transactions must use XA connection factories.
Using application-level/combined cache will result in reduced fragmentation, better utilization of memory and heap space. But the use of application-level/combined cache is limited to entity EJBs in an enterprise application. For an application that requires high throughput, use bean-level caching. Bean-level caching is effective because tasks do not compete for control of the one thread of control in a combined cache.
To make use of WebLogic provided optimization of calls made to EJB components within an application, set
The same can also be achieved by writing local interfaces for EJBs for access within the same enterprise application.
Concurrency strategies for entity EJBs include:
Database:Improves throughput by deferring to database (for EJB 1.1 and 2.0, this is the default and recommended mechanism)
Exclusive:Avoids deadlocks; use it only if a high level of consistency is required on non-clustered servers
Optimistic:No lock will be held in the EJB container or database during transaction. But the EJB container ensures that the data being updated by a transaction has not been changed.
Read-only:Container does not attempt to save a bean's state at the end of a transaction; use this for EJBs that do not make any change to persistent data. With the read-only strategy, use
Tips
1. Consider the number of execute threads, to configure maximum number of beans in the free pool.
2. To limit the memory used by a stateful session EJB, set the maximum number of beans that can reside in the cache (max-beans-in-cache).
3. Too small cache causes frequent activation and passivation.
4. Too large a cache wastes memory.
5. LRU algorithm keeps a bean in the passive state after it passes the ideal number timeout seconds.
6. To avoid the associated overhead of passivating stateful session EJBs, use the not recently used (NRU) algorithm
7. Local interfaces for EJBs provide optimized access for server-side EJB clients.
8. Combined cache enables the administrator to tune just one cache, rather than multiple caches, in weblogic-application.xml.
9. Message-driven beans that use container-managed transactions must use XA connection factories.
Deployment Descriptor Editing
Changing the deployment descriptor of a J2EE application takes effect only when the application is redeployed. The WebLogic admin console provides a way to change some deployment descriptor attributes without redeploying the application. To take advantage of this feature, you must to deploy the application in exploded directory structure (non-archived format), when the domain is running in development mode.
To change descriptor values of the application after deployment (as exploded format) go to Web Application Module > Your Application > Configuration tab > Descriptor tab.
Tips
1. Use tools provided with WebLogic Server to generate and edit XML deployment descriptors.
2. WebLogic Builder generates descriptors; it includes an interface for editing descriptors.
3. DDInit is a command-line utility for generating deployment descriptors for WebLogic Server applications.
4. ddcreate is an Ant task that can be used for creating deployment descriptors for enterprise applications.
To change descriptor values of the application after deployment (as exploded format) go to Web Application Module > Your Application > Configuration tab > Descriptor tab.
Tips
1. Use tools provided with WebLogic Server to generate and edit XML deployment descriptors.
2. WebLogic Builder generates descriptors; it includes an interface for editing descriptors.
3. DDInit is a command-line utility for generating deployment descriptors for WebLogic Server applications.
4. ddcreate is an Ant task that can be used for creating deployment descriptors for enterprise applications.
Precompiled JSP pages and EJBs
Production and test deployments should include precompiled JSP pages and EJBs (use weblogic.appc or weblogic.jspc/weblogic.ejbc with earlier weblogic versions). They can catch compile-time errors in applications long before you deploy them. Also offline compilation validates the deployment descriptors for compliance with current specifications. Deploying compiled applications reduces deployment time and subsequent server restart time. Development deployments intended for use on the developer's workstation can use on-the-fly compilation.
Tips
1. To precompile JSP files during application deployment or server startup, enable the precompile parameter in weblogic.jar.
2. To disable pagecheck and recompilation at runtime in a production environment, set pageCheckSeconds to -1.
3. You can use weblogic.appc or weblogic.ejbc (deprecated) to compile EJBs outside the server VM. This reduces the subsequent server restart time.
4. Use the weblogic.Deployer utility, or its associated Ant task, wldeploy, in scripts to automate deployment in production environments.
Tips
1. To precompile JSP files during application deployment or server startup, enable the precompile parameter in weblogic.jar.
2. To disable pagecheck and recompilation at runtime in a production environment, set pageCheckSeconds to -1.
3. You can use weblogic.appc or weblogic.ejbc (deprecated) to compile EJBs outside the server VM. This reduces the subsequent server restart time.
4. Use the weblogic.Deployer utility, or its associated Ant task, wldeploy, in scripts to automate deployment in production environments.
Enterprise Application (EJB)
WebLogic optimizes EJB access, if the client is within the same enterprise application classes and libraries can be shared across all archive applications within the enterprise application. So consider creating enterprise archives rather than deploying related applications independently. Also Enterprise-wide settings can be used, rather than multiple local settings in deployment descriptors. Create JDBC resources in the WebLogic Server domain, using the WebLogic console, rather than employing the weblogic-application.xml technique.
Tips
1. Avoid deploying EJB archives and related Web applications as separate independent applications in WebLogic Server.
2. Improved runtime performance can be achieved when Web components access EJB components within the same enterprise application.
3. The enterprise can be deployed as one deployment unit.
4. Do not place application-specific classes or JAR files in the system classpath (to avoid having to restart the server for reloading them).
5. When using WebLogic Server 8.1, use the new APP-INF/lib and APP-INF/classes directories in the enterprise-application directory structure, to simplify the packaging of utility classes and utility archives.
Tips
1. Avoid deploying EJB archives and related Web applications as separate independent applications in WebLogic Server.
2. Improved runtime performance can be achieved when Web components access EJB components within the same enterprise application.
3. The enterprise can be deployed as one deployment unit.
4. Do not place application-specific classes or JAR files in the system classpath (to avoid having to restart the server for reloading them).
5. When using WebLogic Server 8.1, use the new APP-INF/lib and APP-INF/classes directories in the enterprise-application directory structure, to simplify the packaging of utility classes and utility archives.
Subscribe to:
Posts (Atom)
