Oracle NMS Configuration Guidelines for Multiple WebLogic Managed Servers

There are multiple reasons why a single Oracle NMS installation (NMS instance) might require more than one WebLogic Managed Server. This appendix is intended to provide an overview of why multiple WebLogic Managed Servers might be desirable and how various NMS end user types can be configured for access to backend NMS Services.

A few of the more common reasons for using multiple WebLogic Managed Servers for a single instance of Oracle NMS are noted below:

1. A desire to segregate NMS control users from NMS non-control users:

a. Control users:

• Allowed to issue outbound control requests to equipment in the field

• May require a privileged network within a physically secured perimeter

b. Non-Control users:

• Not allowed to issue outbound control requests

• Typically operate on a less-privileged subset of the enterprise network – relative to “control” users noted above.

2. Desire to segregate core/primary NMS users from non-core/non-primary NMS users.

a. Core NMS users:

• Typically access NMS inside a control center

• Use NMS as part of their normal/everyday job – experienced users

• May require more privileges to access more complex NMS functionality

• May use a dedicated Directory Service for authentication

b. Non-core NMS users:

• Typically access NMS outside a control center

• More “occasional” – may only access NMS during major events

• Typically require fewer privileges to utilize a subset of full functionality

• Typically utilize Enterprise Directory Service for authentication.

3. Desire to support NMS OMA (mobile) or Flex (browser) clients – in addition to standard (Java) clients.

a. Technically Java, OMA and Flex clients can all be supported via a single WebLogic Managed Server – and this is often done for non-production NMS instances.

b. For production NMS instances - for scalability, security and general ease of support - it is typically preferable to configure separate pairs of supporting WebLogic Managed Servers for each NMS end user type.

• An example of this type of segmentation is shown in Figure 1 below and is the primary focus of this document.

4. Desire to support multiple authentication mechanisms (Directory Servers).

a. A given WebLogic domain can only support one security model. If you have separate Directory Servers that you need/want different classes of users to authenticate with (independently) – you will need multiple WebLogic domains.

b. The use of multiple WebLogic domains to support a single NMS instance can be relevant to any of the configuration/deployment options noted above.

c. Separate WebLogic domains is most practical if/when different NMS user types are completely segmented. The most common way to enforce this segregation is to have mutually exclusive NMS user types for each WebLogic domain (the same user cannot log into both domains with the same user type). If the same exact user and NMS user type can authenticate via different WebLogic domains this mode can be difficult to manage .

Figure 1 - NMS Client Access Overview

Note the NMS (backend) System Services tier will always run on the same server - not across multiple servers. This backend tier will either be hosted on a single Symmetrical Multiprocessing (SMP) Unix server such as a single node (at any point in time) of a cluster made up of two or more SMP Unix servers. This tier supports all NMS Services and Gateway related processes shown at the bottom of Figure 1.

The WebLogic tier just above the NMS System Services tier in Figure 1 can run on the same server as NMS System Services or on one or more separate Unix servers. For production NMS instances it is most common for the WebLogic tier to run on separate servers relative to NMS Services.

At least one WebLogic domain is used to authenticate all NMS end users that interface to NMS Services via one or more WebLogic “cesejb” Managed Servers.

In Figure 1, we have three “cesejb” Managed Servers just above the NMS System Services tier (one for NMS Java users, one for NMS Flex users and one for NMS OMA users). These Managed Servers can all be in one WebLogic domain or in separate domains.

By default all WebLogic Managed Servers are in the same WebLogic domain – but as noted above there are other configurations to consider. If multiple WebLogic domains are deployed – the domains must have unique names.

NMS OMA and NMS Flex users have similar authentication options and should be considered equivalent in the discussion below.

NMS Java End User Authentication

NMS Java end users always authenticate via the WebLogic domain hosting the “cesejb” Managed Server (the WebLogic Managed Server supporting the cesejb deployment). NMS Java end users can be “segmented” (as noted above) to authenticate via different WebLogic domains - but in all cases they will authenticate via a WebLogic domain hosting some version of a “cesejb” Managed Server that supports the cesejb deployment.

NMS OMA/Flex End User Authentication

NMS OMA/Flex users have a choice on where they authenticate.

1. OMA/Flex end users can pass authentication requests from their supporting nms-ws OMA/Flex Managed Server down to their supporting cesejb Managed Server for authentication.

a. Can be configured with both the nms-ws OMA/Flex Managed Server and its supporting cesejb Managed Server in the same or different WebLogic domains.

b. Typically deployed with nms-ws and cesebj Managed Servers in a single WebLogic domain.

2. OMA/Flex users can authenticate on their supporting nms-ws OMA/Flex Managed Server.

a. Requires the nms-ws OMA/Flex Managed Server to be in a separate WebLogic domain relative to its supporting cesejb Managed Server.

• The WebLogic domain name for the nms-ws OMA/Flex Managed Server must be different then the WebLogic domain name for the cesejb Managed Server.

b. Requires WebLogic domain “trust” be configured between the two WebLogic domains. This implies a user authenticated via the WebLogic domain supporting the nms-ws OMA/Flex Managed Server is considered authenticated by the WebLogic domain supporting the cesejb Managed Server.

• This “trust” is time limited – often the duration of a typical end user shift.

• Once “trust” expires the end-user will need to re-authenticate.

Figure 2 – NMS Flex/OMA Architectural Deployment Overview