Posted on

How to recover Oracle Weblogic administrator password

oracle weblogic tutorials howto example wls java ee

How to change the administrator password

The last two recipes of this book will help you in case you have lost your administration password or just in case you want to simply change it. We will begin from the latter one. In order to change the Administrator password:

  1. Start the Web console and select from the left tree panel Security Realms |[yourrealm] | Users and Groups tab. From there, click on the administrator user (e.g. “weblogic”):

oracle weblogic tutorials howto example wls java ee

  1. In the next screen, click on the Passwords tab. Enter the new password and Save.

oracle weblogic tutorials howto example wls java ee
In order to make this change available when the server starts, you need to edit the boot.properties located at DOMAIN_HOME\servers\AdminServer\security and provide the values used for user/password . The original values should be an encrypted string; however just enter the values as plain text as in the following example:

password=wlsadmin

username=newAdminPassword

Save the file. Next time the server will start it, it will pick up the new values from the boot.properties and once the same had been accepted, they will be encrypted again.

Recovering the administrator password

If you accidentally lost your administrator password don’t despair. Make sure the Administration server is stopped and that you have set the domain environment:

C:\wls1211_dev\user_projects\domains\base_domain\bin>setDomainEnv.cmd

Now execute the following command (mind to include the “.” at the end of it) which sets a new password for the user “wlsadmin”:

C:\WLS121~1\user_projects\domains\base_domain>java weblogic.security.utils.AdminAccount wlsadmin newAdminPassword.

The above command will create a file called DefaultAuthenticatorInit.ldift in the current directory. Now make a backup copy of the original file DefaultAuthenticatorInit.ldift which is in the security folder of your domain:

C:\WLS121~1\user_projects\domains\base_domain\security>copy DefaultAuthenticatorInit.ldift DefaultAuthenticatorInit.ldift.backup

        1 file(s) copied.

Next, edit the boot.properties located at DOMAIN_HOME\servers\AdminServer\security and give the values used for user/password. The original values should be an encrypted string; however just enter the values as plain text as in the following example:

username=newAdminPassword

password=wlsadmin

Copy the recently created DefaultAuthenticatorInit.ldift to DOMAIN_HOME\security

C:\WLS121~1\user_projects\domains\base_domain\security>copy C:\wls1211_dev\user_projects\domains\base_domain\DefaultAuthenticatorInit.ldift .

Finally, delete the file named DefaultAuthenticatormyrealmInit.initialized located in DOMAIN_HOME\servers\AdminServer\data\ldap

C:\WLS121~1\user_projects\domains\base_domain\servers\AdminServer\data\ldap>delete DefaultAuthenticatormyrealmInit.initialized

Now restart the server using startWeblogic.cmd/startWeblogic.sh from DOMAIN_HOME

Posted on

How to restrict access to Oracle Weblogic

oracle weblogic tutorials howto example wls java ee

Restricting access to WebLogic Server

In order to restrict access to WebLogic server to a set of machines, you can use Network Connection Filters which are used to add an additional layer of security allowing you to deny access at the network level.

Network Connection Filters are a type of firewall in that they can be configured to filter on protocols, IP addresses, and DNS node names. For example, you can deny any non-SSL connections originating outside of your corporate network. This would ensure that all access from systems on the Internet would be secure.

You can configure Connection filters, by selecting the top-level domain from the Admin Console and then choosing the Security| Filter tab. In order to add a Connection filter you have to specify a Connection filter class and the Connection Filter rules.

WebLogic ships out of the box with a default Connection Filter class named weblogic.security.net.ConnectionFilterImpl that examines one or more connection filter rules defined in the Administration Console. Alternatively, you can create your own custom connection filter that evaluates the basis that incoming connections are accepted by the server.

The following Connection Filter rules can be used to deny http and https protocol access from www.acme.com to the local server. 

oracle weblogic tutorials howto example wls java ee

The connection filter rules are written using a firewall-like syntax (check here for more details about constructing filter rules: http://docs.oracle.com/cd/E24329_01/web.1211/e24485/con_filtr.htm)

Posted on

Configuring the Secured Socket Layer (SSL) on Oracle Weblogic

oracle weblogic tutorials howto example wls java ee

Secure Sockets Layer (SSL) provides secure connections by allowing two applications connecting over a network connection to authenticate the other’s identity and by encrypting the data exchanged between the applications. So, while authentication allows a server (and optionally a client) to verify the identity of an user, encryption makes data transmitted over the network intelligible only to the intended recipient.     

SSL can be configured one-way or two-way:

  • one-way SSL: the server is required to present a certificate to the client in order to verify its identity. To successfully negotiate an SSL connection, the client must authenticate the server, but the server will accept a connection from any client.   
  • two-way SSL: the server presents a certificate to the client and the client presents a certificate to the server. WebLogic Server can be configured to require clients to submit valid and trusted certificates before completing the SSL connection.

Configuring SSL on Oracle WLS         

In order to configure SSL, we will use the Java Keytool to generate the certificates required for both the one-way SSL communication and the two-way SSL communication.

A step-by-step guide for creating the certificates using keytool has been included in the Appendix of this book. Therefore, in order to proceed, follow these steps:

  1. Start by creating the required keystores (for one-way SSL) and truststore file (if you need two-way SSL) as indicated in the Appendix.
  2. In order to use the certificates, log into the Admin Console and, for each server that needs to be secured, click on its Keystore tab. By default it points to the Demo Certificates.
  3. Click on the Change button:

oracle weblogic tutorials howto example wls java ee

  1. In the next screen, select as Keystores the option “Custom Identity and Custom Trust” :

oracle weblogic tutorials howto example wls java ee

  1. Click on Save. This will return to the Keystore subtab.
  2. Now enter the details of your KeyStore (and in case of two-way SSL the truststore too ). Specify as Custom KeyStore Type “JKS”, which is the keystore type generated with JDK’s keytool utility.

oracle weblogic tutorials howto example wls java ee

  1. Click on Save. Now move on the Configuration | SSL tab and enter the alias of the Private Key Alias and its password, as shown by the following screen:

oracle weblogic tutorials howto example wls java ee

  1. The last step, which needs also to be repeated in every secured server, is Enabling SSL and setting a Listen Port for your https requests. This can be achieved through the Configuration | General Sub Tab as shown by this picture:

oracle weblogic tutorials howto example wls java ee

Posted on

Securing Oracle Weblogic applications

Configuring Security for Web applications

Configuring security for Oracle WLS Web applications is done in two separate points:

  1. Inside the standard web application configuration file (web.xml) you will define the authorized Roles, the secured URL Pattern and the Authorization method.
  2. Inside the weblogic.xml you will map these roles to actual principals defined in the WebLogic Server security realm.

Let’s define at first in your web.xml how to apply security constraints using BASIC authentication:

<security-constraint>

              <web-resource-collection>

                            <web-resource-name>SecureArea</web-resource-name>

                            <description>Our Secure Area</description>

                            <url-pattern>/*</url-pattern>

              </web-resource-collection>

              <auth-constraint>

                            <description>Constraints for secure area</description>

                            <role-name>admin</role-name>

                            <role-name>poweruser</role-name>

              </auth-constraint>

              <user-data-constraint>

                            <description>SSL is not required</description>

                            <transport-guarantee>NONE</transport-guarantee>

              </user-data-constraint>

</security-constraint>

<login-config>

              <auth-method>              BASIC</auth-method>

              <realm-name>myrealm</realm-name>

</login-config>   

We have restricted access to all Web Context resources so that only users with the role admin and poweruser can access them, but we are not requiring the use of SSL transport for access.

Setting the <transport-guarantee> to CONFIDENTIAL or INTEGRAL would further restrict access to only those users in one of the specified roles who are using SSL to access the page.

If we stopped here, WebLogic Server would try to map these roles to principals (either users or groups) with the same name, as defined in the active security realm’s authentication provider. In most cases, you don’t actually want this, so you need to define the mapping from these roles to actual principals defined in the WebLogic Server security realm.

In order to map these roles to principals in the underlying security realm, you use the <security-role-assignment> element in the weblogic.xml deployment descriptor. In the following example, we are mapping the “admin” role to the “webuser” user and the “poweruser” role to “john”.

<wls:weblogic-web-app>

  <wls:security-role-assignment>

        <wls:role-name>admin</wls:role-name>

        <wls:principal-name>webuser</wls:principal-name>

  </wls:security-role-assignment>

  <wls:security-role-assignment>

        <wls:role-name>poweruser</wls:role-name>

        <wls:principal-name>john</wls:principal-name>

  </wls:security-role-assignment>

</wls:weblogic-web-app>

Configuring Security for EJB applications

Configuring security for EJB applications is similar to Web applications; just it is uses different files.

Inside your Java EE’s ejb-jar.xml deployment descriptor, define your access control policy by using the <security-role> and <method-permission> elements. In the following example, we restrict access to the SecuredEJB’s getData method to users which are granted the admin role:

<assembly-descriptor>

              <security-role>

                            <role-name>admin</role-name>

              </security-role>

              <method-permission>

                            <role-name>admin</role-name>

                            <method>

                                          <ejb-name>SecuredEJB</ejb-name>

                                          <method-name>getData</method-name>

                            </method>

              </method-permission>

</assembly-descriptor>

EJB 3.0 and later also allows for declaration of EJB security constraints through annotations found in the javax.annotations.security package, as in the following example:

@Stateless(name=”SecuredEJB”)

@DeclaredRoles(value={“admin”})

public class SecuredEJB {

  @RolesAllowed(value={“admin”})

  public Data getData() { … } }

Next, configure into weblogic-ejb-jar.xml the actual mapping data. The following example maps the admin role to ejbuser user. Additionally, you can use the <externally-defined> element to force a role to be defined in the role mapping security provider.

<security-role-assignment>

              <role-name>admin</role-name>

              <principal-name>ejbuser</principal-name>

</security-role-assignment>

<security-role-assignment>

              <role-name>ejb-admin</role-name>

              <externally-defined />

</security-role-assignment>

Posted on

Configuring Oracle Weblogic Security Providers

Security providers are modular components that handle specific aspects of security, such as authentication and authorization. Although applications can leverage the services offered by the default WebLogic security providers, the WebLogic Security Service’s flexible infrastructure also allows security vendors to write their own custom security providers which can be used with WebLogic Server.

Before configuring new Security providers, you must be aware that WebLogic Server security includes many unique terms and concepts that you need to understand. The following table describes them shortly:

 

Authentication: this is the process of determining whether someone is, in fact, who it is declared to.

Identity Assertion: an Authentication provider that performs perimeter authentication—a special type of authentication using tokens—is called an Identity Assertion provider.

Authorization: once a user’s identity has been established by an authentication provider, authorization is responsible for determining whether access to resources should be permitted for that user.

Role Mapping: you can assign one or more roles to multiple users and then specify access rights for users who hold particular roles for a given resource.

Adjudication: an Adjudication provider is used to resolves authorization conflicts between multiple Authorization providers. It can do so, by weighing each Authorization provider’s access decision and determining whether to permit access to the requested resource.

Credential Mapping: credential mapping allows WebLogic Server to log into a remote system on behalf of a subject that has already been authenticated.

Keystore: this is a repository of security certificates, either authorization certificates or public key certificates – used for instance in SSL encryption.

Certificate Lookup and Validation (CLV):  you can usecertificate lookup and validation (CLV) providers to perform additional validation on the certificate chain.

Certificate Registry: a certificate registry is a mechanism for adding certificate revocation checking to a security realm. The registry stores (into an embedded LDAP server) a list of valid certificates. Only registered certificates are valid.

Auditing: auditing is a process which is in charge is to collect, store and distribute information about security requests for the purpose of non-repudiation.

Managing Security Providers

You can get the list of available Security Providers by selecting the Providers upper tab (Security realm | Providers). Out of the box, WLS provides a default WebLogic Authentication Provider and an Identity Assertion Provider.

WebLogic Server’s default security providers use an embedded LDAP server to persist all security-related data. Each server stores this data locally, including all of the user, group, role, access control policy, and credential information. You can use the embedded LDAP server for managing users and groups for reasonably small environments (10,000 or fewer users).

Connecting to the embedded LDAP server

Connecting to the embedded LDAP server is quite simple as it just requires an ordinary LDAP browser such as JXPlorer (http://jxplorer.org/).

Before doing that, you need to set a password in order to be able to log to the LDAP server. This can be done by navigating into the Domain | Security | Embedded LDAP screen. Once there, set the Credential (and confirm it) that will be your password for accessing LDAP:

Now restart WLS and launch your LDAP explorer. From there enter the Base DN information, which will be bound to your domain name, and enter as username “Admin” and as password the one we have just entered in the console. The LDAP port is 7001. The LDAP explorer window is depicted in the following picture:

Click Ok. You can now view/export your WLS realm using the standard LDAP’s ldif format.

oracle weblogic tutorials howto example wls java ee

Creating a new provider: Database Authentication provider

In this section, we will show how to create a new Authentication provider which uses the database for storing the user’s credentials.

  1. Open up the Console and select the Security Realm| [Your Realm] |Providers Summary view.
  2. Click on New.
  3. In the next screen you will need to configure some basic settings for your provider. In the Type combo you need to select the type of authentication provider you want to create.

oracle weblogic tutorials howto example wls java ee

WebLogic Server comes with several built-in, configurable authentication providers. These providers primarily include support for external directory servers such as Active Directory, Sun Java System Directory Server, OpenLDAP, and Novell eDirectory, Oracle Internet Directory, and Oracle Virtual Directory LDAP servers.

In this recipe we will show how to use a DBMS provider to store your users and roles, therefore select the SQLAuthenticator as Type and click Ok.

Once created, select your just created provider and enter the Configuration tab and the Common sub-tab:

oracle weblogic tutorials howto example wls java ee

There you specify, via the Control Flag option, how this Authentication provider fits in the overall authentication process, in case you have multiple Authentication providers. The Control Flag option can have the following values:

  • REQUIRED: the authentication provider is required to succeed. If it succeeds or fails, the authentication process continues to proceed through the list of configured providers. If multiple providers are present, at least one needs to be set as REQUIRED.
  • REQUISITE: the authentication provider is required to succeed. If it succeeds, the authentication process continues through the list of configured providers. If it fails, the authentication process immediately fails and returns control to the application.
  • SUFFICIENT: the authentication provider is not required to succeed. If it does succeed, the authentication process succeeds and control is returned immediately to the application. If it fails, the authentication process continues down the list of configured providers.
  • OPTIONAL: the authentication provider is not required to succeed. If it succeeds or fails, the authentication process continues down the list of configured providers.

 

Warning! Because the administration server must authenticate the user using the default authentication provider, a misconfigured provider using one of these strict control flags will prevent the server from starting (for example by setting more than one option to REQUIRED).

Back to our example, we have decided to set the control flag to SUFFICIENT. Click Save and move to the Provider specific sub-tab:

oracle weblogic tutorials howto example wls java ee

We need to fill in the Data Source name which will be used to connect to your database. You can leave all the other options to the default values. Then we need to restart the WebLogic server. After the reboot, we can go the User and Group tab of your default security realm where we can change or add users and roles.

Database schema setup

In order to get working with the Database authentication provider you need to create your schema where users and roles will be stored. A creation script is available at Github on the following address: (https://github.com/fmarchioni/ascookbook/tree/master/OracleWLS) in the SQLAuthenticator_createDB.txt 

Now just add your users using either direct SQL commands as follows:

insert into USERS (U_NAME,U_PASSWORD,U_DESCRIPTION) values(‘system’,’weblogic’,’admin user’);

insert into GROUPS (G_NAME,G_DESCRIPTION) values(‘Administrators’,’Administrators’);

insert into GROUPMEMBERS (G_NAME,G_MEMBER) values(‘Administrators’,’system’);

The only limitation is that passwords are not encrypted so either you can add users via console or via WLST script to store them in encrypted form. The following WLST script can be used to add users:

connect(‘weblogic’,’weblogic123′,’t3://localhost:7001′)

edit()

startEdit(-1,-1,’false’)

serverConfig()

cd(‘/SecurityConfiguration/base_domain/Realms/myrealm/AuthenticationProviders’)

ls()

cd(‘SqlAuthenticator’)

cmo.createUser(‘myuser’,’weblogic123′,’SQLuser’)

edit()

stopEdit(‘y’)

Remember to customize user, password and admin URL in the 1st line. Also replace domain name “base_domain” with your domain name in line 5. Finally change SQL authenticator name in line 6 with your authenticator name.

Posted on

Oracle Weblogic Security

Oracle WLS provides a complete security infrastructure which combines the JVM Security Manager and the standard JAAS authentication and authorization options. The main components of WLS Security service are illustrated by the following picture:

As you can see from the above picture, at the highest level WLS uses a Security API which combines with Java Security API. This security stack allows application developers to specify authorization information that is used when Oracle WebLogic Server acts as a client; it also allows application developers to obtain information about the Subject and Principals used by Oracle WebLogic.

Next stack is the Security Service Provider Interfaces (SSPI) for developing new security services that can be plugged into the Oracle WebLogic Server environment. SSPIs are available for Authentication, Authorization, Auditing, Role Mapping, Certificate Lookup and Validation and Credential Mapping.

The implementation of SSPIs are a set of WebLogic security providers. These security providers are the Oracle implementation of the SSPIs and are available by default in the Oracle WebLogic Server.

 

Configuring a WebLogic Security realm

A Security Realm is a mechanism for protecting all Oracle WebLogic Server resources. Each security realm consists of a set of configured security providers, users, groups, security roles and security policies. You can configure multiple security realms in a domain; however, only one can be the active security realm.

WebLogic Server provides a default security realm named myrealm which has the WebLogic Adjudication, Authentication, Identity Assertion, Authorization, Role Mapping and Credential Mapping providers configured by default.

You can access the security realm screen from the Administration console under the Domain | Security Realms option:

By clicking on the Configuration | General tab, you can configure the general behaviour of the security realm:

The Security Model Default determines how applications are protected by default.

When using the default option (DD Only) WLS only uses the roles and policies defined in the JEE deployment descriptors. Thus, if an EJB or a Web application is not protected by a role or policy in the DD, then it is unprotected and anyone can access it.

The other Security Model options allow to Customize Roles Only (which means that policies are taken from DD but Roles are customized) and Customize Roles and Policies (both Roles and Policies are customized). Finally the Advanced Security model is used mostly for backward compatibility with prior-to-9 releases of the application server. This model uses the roles and policies defined in the deployment descriptors to seed the WebLogic Server security roles and policies; it then uses the WebLogic Console to modify roles and policies from that point onward.

 

Posted on

Managing Oracle Weblogic with WLST

Oracle WebLogic server ships with a set of tools for server administration and management. In the second chapter, we have learnt how to use the browser-based Administration console, which remains the first choice for WLS administrator. In this chapter we will learn about the WebLogic Scripting Tool (WLST) which is a command-line scripting environment that you can use to create, manage and monitor Oracle WebLogic Server domains.

Getting started with Oracle WLST

Oracle WebLogicScripting Tool (WLST) is an advanced management tool, based on the Java scripting interpreter, Jython. In addition to supporting standard Jython features, such as local variables, conditional variables and flow control statements, WLST provides a set of scripting functions (commands) that are specific to WebLogic Server. You can even extend the WLST to suit your needs by following the Jython language syntax.

Jython is an implementation of the Python language in Java. It compiles Python code into Java bytecode and uses the JVM for this purpose. WLST uses Jython to access various objects within the WebLogic Server domain. These objects are called MBeans (Managed beans), that is, Java objects that represent resources to be managed.

WLST modes

WLST can be used in several modes; we can however group them in the following main three categories:

  • Offline: Mostly used to create new domains like the configuration domain wizard
  • Online: Used to perform online administration tasks just like the Administration console
  • Embedded: Invoked directly from Java code

Launching the WLST tool

The WebLogic scripting tool can be located into the $MW_HOME/wlserver/common/bin folder of your distribution. It can be launched using the wlst command as shown here:

Running WLST in offline mode

Oracle recommends using the offline mode to create domain templates, new domains based on existing templates, or extend an existing, inactive domain. It is discouraged to use this mode on a running domain of server since changes can be overwritten by other administration tools like the Web console or the WLST on line shell.

Running WLST in offline mode can be achieved with few little steps: at first set your environment by running the setWLSEnv script (the following example assumes you are running a Windows Machine):

$MW_HOME\wlserver\server\bin>setWLSEnv.cmd

Then you can launch your scripts in offline mode by passing them as argument to WLST:

java weblogic.WLST samplescript.py

Initializing WebLogic Scripting Tool (WLST) …

starting the script …

Alternatively, you can just connect to the WLST by launching the wlst command (as shown in the former picture), and use the execfile command passing as parameter the script to execute:

wls:/(offline)>execfile(‘c:/temp/ samplescript.py’)

starting the script …

Example: creating an Oracle WLS domain using a script:

Here is a sample WLST script which can be used to create a new WLS domain:

 

middleware_home=’ /usr/weblogic/wlserver ‘

# Open a domain template.

readTemplate (middleware_home + ‘/common/templates/domains/wls.jar’)

cd(‘Servers/AdminServer’)

set(‘ListenPort’, 7001 )

set(‘ListenAddress’,’192.168.10.1′)

create(‘AdminServer’,’SSL’)

cd(‘SSL/AdminServer’)

set(‘Enabled’, ‘True’)

set(‘ListenPort’, 7002)

cd(‘/’)

cd(‘Security/base_domain/User/WebLogic’)

cmo.setName(‘WebLogic’)

cmo.setPassword(‘secretPassword123 ‘)

setOption(‘OverwriteDomain’, ‘true’)

setOption(‘ServerStartMode’, ‘prod’)

writeDomain(domaintarget)

closeTemplate()

In this script, we are opening an existing domain template for domain creation, using the readTemplate command. Please note that, once you open a domain template, WLST is placed into the configuration bean hierarchy for that domain template, and the prompt is updated to reflect the current location in the configuration hierarchy.

You can traverse the hierarchical structure of configuration beans using commands such as cd, ls, and pwd in a similar way that you would navigate a file system in a UNIX or Windows command shell.

In this example, we are navigating first to the “Servers/AdminServer” location where we perform some administrative tasks (creation of Administration server); then we are heading for “Security/base_domain/User/WebLogic” bean hierarchy where we set some basic security settings.

If you specify a backslash character (\) in a string (e.g. Windows systems), for example when specifying a file pathname, you should precede the quoted string by “r” to instruct WLST to interpret the string in its raw form and ensure that the backslash is taken literally. This format represents standard Jython syntax.

 

Posted on

Oracle Weblogic Clustering EJBs

Load balancing and failover for EJBs and RMI objects is handled using replica-aware stubs, which can locate instances of the object throughout the cluster. EJBs differ from plain RMI objects in that each EJB can potentially generate two different replica-aware stubs: one for the EJBHome interface and one for the EJBObject interface. This means that EJBs can potentially realize the benefits of load balancing and failover at two levels:

  • When a client looks up an EJB object using the EJBHome stub.
  • When a client makes method calls against the EJB using the EJBObject stub.

The following sections describe clustering support for different types of EJBs.

Clustering Stateless EJBs

Since a stateless bean holds no state on behalf of the client, the stub is free to route any call to any server that hosts the bean. In order to declare a Stateless EJB as clusterable, you need to set to true the element stateless-bean-is-clusterable in your weblogic-ejb-jar.xml:

<stateless-clustering>

   <stateless-bean-is-clusterable>True</stateless-bean-is-clusterable>

   <stateless-bean-load-algorithm>random</stateless-bean-load-algorithm>

</stateless-clustering>

The stub can automatically fail over in the event of a failure. The stub does not automatically treat the bean as idempotent, so it will not recover automatically from all failures. If the bean has been written with idempotent methods (e.g. there is no additional effect if the EJB is called more than once with the same input parameters), this can be noted in the deployment descriptor as follows, and automatic failover will be enabled in all cases.

<stateless-clustering>

    . . . . .

   <stateless-bean-methods-are-idempotent>true</stateless-bean-methods-are-idempotent>

</stateless-clustering>

Clustering Stateful EJBs

Method-level failover for a stateful service requires state replication. WebLogic Server satisfies this requirement by replicating the state of the primary bean instance to a secondary server instance, using a replication scheme similar to that used for HTTP session state.

As you can see from the following weblogic-ejb-jar.xmlsnippet, you can configure the replication schema by setting the replication-type element, much the same way we did for the HTTP counterpart:

<stateful-session-descriptor>

  <stateful-session-clustering>

    <home-is-clusterable>true</home-is-clusterable>

    <home-load-algorithm>random</home-load-algorithm>

    ….

    <!– None for not to replicate –>

    <replication-type>InMemory</replication-type>

  </stateful-session-clustering>

</stateful-session-descriptor>

Should the primary server fail, the client’s EJB stub automatically redirects further requests to the secondary WebLogic Server instance. At this point, the secondary server creates a new EJB instance using the replicated state data and processing continues on the secondary server. After a failover, WebLogic Server chooses a new secondary server to replicate EJB session states

Configuring the default load balancing algorithm

WebLogic Server clusters support multiple algorithms for load balancing clustered EJBs and RMI objects: round-robin, weight-based, random, round-robin-affinity, weight-based-affinity, and random-affinity.

By default, a WebLogic Server cluster will use the round-robin method. You can configure a cluster to use one of the other methods using the Administration Console as follows:

  1. Select Environment | Clusters within the Domain Structure panel of the console.
  2. Select a specific cluster. On the General tab, update any of the fields contained as described by the following picture:

 

You can specify the cluster address using a comma-separated list of hostnames and port numbers.

Remember that any address/port combination in the cluster address must be unique. This means that if you need to run a WebLogic cluster on a single machine, you must ensure all server instances participating in the cluster are assigned a unique port number.

As mentioned in WebLogic documentation, when clients obtain an initial JNDI context by supplying the cluster DNS name (weblogic.jndi.WLInitialContextFactory), it obtains the list of all addresses that are mapped to the DNS name. This list is cached by WebLogic Server instances and new Initial Context requests are fulfilled using addresses in the cached list with a round-robin algorithm. If a server instance in the cached list is unavailable, it is removed from the list. The address list is refreshed from the DNS service only if the server instance is unable to reach any address in its cache.

Using a cached list of addresses avoids certain problems with relying on DNS round-robin alone. For example, DNS round-robin continues using all addresses that have been mapped to the domain name, regardless of whether or not the addresses are reachable. By caching the address list, WebLogic Server can remove addresses that are unreachable so that connection failures aren’t repeated with new Initial Context requests.

Posted on

Configuring Oracle WLS Loadbalancing and High Availability

Load balancing is an essential feature of clustering. WebLogic server has specific load balancing configuration for Web applications. This can be accomplished using a software load balancer or a separate load balancing hardware.

The choice of software load balancer is indeed large and includes Oracle HTTP Server with the mod_wl_ohs module configured, Oracle WebLogic server configured with HttpClusterServlet or the open source Apache Server  mod_weblogic plugin.

For a detailed description of Oracle WebLogic plugins we suggest reading the Oracle documentation available at http://docs.oracle.com/cd/E15523_01/web.1111/e14395/toc.htm

Configuring load balancing with Oracle HTTP Server (mod_wl_ohs)

If you want to install mod_wl_ohs then you need downloading Oracle HTTP Server (http://www.oracle.com/technetwork/middleware/ias/index-091236.html) .

Oracle HTTP Server is based on the proven, open source technology of Apache Web server and includes all base Apache modules and modules developed specifically by Oracle.

Oracle HTTP Server is based on the proven, open source technology of Apache Web server and includes all base Apache modules and modules developed specifically by Oracle.

Mod_wl_ohs is built-in into Oracle HTTP server; you need however to activate it. Here’s a sample configuration file:

LoadModule weblogic_module “${ORACLE_HOME}/ohs/modules/mod_wl_ohs.so”

 

<IfModule mod_weblogic.c>

  WebLogicHost host1.com

  WebLogicPort 7001

  WLLogFile /tmp/mod_wl_ohs.log

  MatchExpression *.jsp

 

  <Location /em>

    SetHandler weblogic-handler

    WebLogicHost host1.com

    WebLogicPort 7001

  </Location>

 

</IfModule>

The main sections of mod_wl_ohs.conf are:

LoadModule: loads the weblogic_module when OHS starts.

IfModule: specifies the host and port of the WLS server or cluster and the MatchExpression for proxying by MIME type.

Location specifies application context root for proxying by path.

If both MIME type and proxying by path are configured, proxying by path takes precedence.

Configuring Load balancing with Apache server (mod_weblogic)

If you don’t want to install Oracle HTTP Server to proxy your cluster requests, an open source alternative is Apache Server’s mod_weblogic plugin. This plugin is not part of the WLS distribution so you have to download it from Oracle’s site at http://www.oracle.com/technetwork/middleware/ias/downloads/wls-plugins-096117.html

This link will download a bundle of plugins, which are in turn packaged into different operating system distributions, as shown by the following picture:

 

 

  1. Unzip the WLSPlugin which matches with your platform and locate the library named mod_wl_20.so from the package. This library needs to be copied into the APACHE_HOME\modules directory of your Apache Web server distribution.
  2. Next step will be editing Apache’s httpd.conf configuration file. Add at first the following line to your APACHE_HOME/conf/httpd.conf file manually:

LoadModule weblogic_module     modules/mod_wl_20.so

  1. Then, include an IfModule block that defines the list of servers/port in the cluster:

<IfModule mod_weblogic.c>

  WebLogicCluster w1s1.com:7001,w1s2.com:7001,w1s3.com:7001

  MatchExpression *.jsp

  MatchExpression *.xyz

</IfModule>

If you need to proxy requests by path, use the Location block and the SetHandler statement. SetHandler specifies the handler for the Apache HTTP Server Plug-in module. For example, the following Location block proxies all requests containing /weblogic in the URL:

<Location /weblogic>

  SetHandler weblogic-handler

  PathTrim /weblogic

</Location>

Choosing between mod_wl_ohs and mod_weblogic

Mod_weblogic and mod_wl_ohs provide almost the same functionalities with few notable differences: mod_wl_ohs  has support for the two-way SSL between OHS and WLS (while Mod_weblogic only supports one-way SSL) and, also, supports IPv6 for communication with WLS.

 

Posted on

Clustering Oracle Weblogic

A WebLogic Server cluster consists of multiple Managed servers running simultaneously the same applications and working together to provide increased scalability and reliability.

There are a variety of options which you can use to configure a cluster:

  • From within the domain installation wizard, (See Chapter 1, “Creating a WebLogic domain”) you have the option to create a domain made up of a set of Managed nodes which are part of a cluster.
  • If you want to defer the creation of your cluster at a later time, a common option for creating it is by means of the Administration console.
  • If you are an experienced user, then you might try the WLST scripting shell to automate the creation of your cluster. (See Chapter 11, “Creating a cluster with WLST”)

In this chapter we will at first learn how to set up a cluster using the Administration Console and the Managed servers that we have created at the beginning of this book. Then we will learn how to achieve Load Balancing and High Availability for your applications.

Create a cluster from the Admin console

Start up the Administration server and (if you want to control servers from the Web console) the Node Manager. If any of the Managed servers of the domain are running, shut them down, using the Control tab of each server.

  1. From the left tree panel expand the Environment option and select Clusters.
  2. From the Cluster Summary page, click on the New button.
  3. In the Create a New Cluster screen, enter the Cluster Name and select a Messaging Mode as depicted by the following picture:

 

As you can see, we have chosen “WLSCluster” as Name and left the default options for Messaging Mode (Unicast) and Unicast Broadcast Channel (blank).

Note: the Multicast fields are disabled if you choose Unicast as messaging mode. In the section named “Configuring clustering transport” we detail some more information about Unicast and Multicast modes.

Click Ok. A message will inform you that the cluster was created successfully.

Configuring the cluster address

So far we have defined just a Name and a Messaging Mode for our cluster. You might wonder how your clients (for example a remote EJB client) can access an application running in a cluster of nodes. The answer is the Cluster Address which is used to construct the host name portion of request URLs. You can explicitly define the cluster address when you configure the cluster; otherwise, WebLogic Server dynamically generates the cluster address for each new request.

Dynamic cluster address

If you have not explicitly defined a cluster address, then when a Managed Server receives a remote request, WebLogic Server generates the cluster address, in the form:

listenaddress1:listenport1,listenaddress2:listenport2;listenaddress3:listenport3

Each listen address:listen port combination in the cluster address, corresponds to the single Managed servers and the network channel that received the request.

Explicitly Defining Cluster Address

You can explicitly define a cluster address for a cluster in a production environment by specifying the cluster address as a DNS name that maps to the IP addresses or host names of each WebLogic Server instance in the cluster. In order to do that, select the Configuration | General sub tab of your Cluster definition:

You can specify the cluster address using a comma-separated list of hostnames and port numbers or (highly suggested) as DNS name that is mapped externally to the addresses of all servers that belong to the WebLogic cluster.

Both of these are valid examples of the cluster address for a WebLogic cluster:

192.168.1.1:7003, 192.168.1.1:7005, 192.168.1.1:7007

DNS1:7001,DNS2:7001

Remember that any address/port combination in the cluster address must be unique. This means that if you need to run a WebLogic cluster on a single machine, you must ensure all server instances participating in the cluster are assigned a unique port number.