This chapter describes the specific security mechanisms provided by Oracle Communications Enhanced Communications Application Server (OCECAS).
OCECAS is built upon the framework of Oracle Fusion Middleware WebLogic Server and Oracle Communications Converged Application Server. Session Design Center GUI users are authenticated against credentials stored in the WebLogic server, or against an external LDAP provider. Session Design Center and the REST API it uses must be deployed using SSL. OCECAS configuration settings prompt you for a user name and password, using the basic authentication method. JavaScript resources are not protected.
Web browsers connect to OCECAS over an HTTP port or on HTTP with a TLS (SSL) port. You can use TLS connections to secure communications to these interfaces:
Session Design Center UI interface (to browser)
Session Design Center REST API interface (to browser)
UDR REST API interfaces (to provisioning system)
SIP interface (to IMS)
Diameter Ro/Rf and Sh interfaces (to charging engines and HSS)
NoSQL interface (to NoSQL repository)
Using TLS, all network communication between the web browser and the server is encrypted, which means that sensitive information is never in clear text.
As a minimum authentication requirement, the server is required to present a digital certificate to the web browser client to prove its identity.
You enable TLS (SSL) by using the Administration Console.
This section describes recommended deployment configurations for OCECAS.
Deploy OCECAS and the UDR components it contains entirely on a private network, typically as part of an IMS Network. Do not allow direct access to any of these servers.
Event Data Records (EDRs) are saved in files on the Management server. Only the user created for installing OCECAS has access to the EDR files. See ”Using EDRs for Testing and Troubleshooting” in Evolved Communications Application Server System Administrator's Guide for more information.
You can provision subscribers in a NoSQL database created as part of the UDR domain, using a RESTful API. Secure the RESTful API using basic authentication over TLS; secure NoSQL by configuring kvStore with TLS and authentication enabled.
Use the Administration Console to maintain and secure all configuration for OCECAS.
The OCECAS deployment pipeline defines a change-management architecture that isolates session state between runtime domains. Changes on, and actions toward a runtime domain cannot affect the other domains in the pipeline.
The Session Design Center GUI is a web-based management application for multiple OCECAS domains. The application is deployed in the Management System domain. Configure this server to use SSL TLS.
You secure access to Session Design Center using a WebLogic security realm and a dedicated group. Only users with membership of the group are authorised to access the UI. The security realm can use a local LDAP directory, an external LDAP directory, or another security provider such as Oracle Identity Manager. Once configured, shut down the AdminServer to prevent unauthorized access.
See Oracle Fusion Middleware Securing a Production Environment for Oracle WebLogic Server for further details.
Where required, enable application logging to diagnose problems with the Session Design Center GUI control flows. By default, only messages at the INFO level are output to log files. No sensitive information is logged at the INFO level. Oracle strongly recommends that you do not use DEBUG level on a production environment.
The Session Design Center is accessible to service designers. This part of the management server is typically accessible on a corporate network to allow service engineers access to the management application. Manage access to the management application locally using the WebLogic local LDAP security realm, or integrate it with a third-party security provider.
Once all applications are installed and configured, Oracle recommends that you shut down all Administration Servers to prevent unauthorized access.
This section explains security considerations for the software underlying OCECAS.
See these documents for information about securing the Linux operating system that OCECAS runs on:
Guide to the Secure Configuration of Red Hat Enterprise Linux 5, available from the National Security Agency website here:
https://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf
Hardening Tips for the Red Hat Enterprise Linux 5, available from the National Security Agency website here:
https://www.nsa.gov/ia/_files/factsheets/rhel5-pamphlet-i731.pdf
You can integrate Session Design Center GUI with an external security provider, allowing a single sign-on approach to accessing the web-based application.
The Session Design Center GUI application is deployed to a mgmt1 server within WebLogic by default. mgmt1 is the default name for the managed server running the Session Design Center UI and REST APIs in the management domain. Configure this server so that only SSL access is allowed, chiefly to prevent passwords being submitted in plain text on login.
After you have installed all of the OCECAS domains, disable basic authorization with the command listed in "Disabling Basic Authentication" in Evolved Communication Application Server Installation Guide.
In addition to disabling basic authentication, this script creates an EvolvedCommunicationUsers WebLogic group. Any users created in the WebLogic security realm must be added to this group in order to access the application. See Oracle Fusion Middleware Securing Resources Using Roles and Policies for Oracle WebLogic Server for more information.
The default Session Design Center GUI implementation does not provide a secure configuration for JDBC connections to the database. To secure these connections requires you to configure secure client connections to the database.
See Oracle Database Security Guide for more information about securing client connections to the database.
Oracle Coherence is used internally within OCECAS and its nodes. Coherence security includes securing both cluster members and extends clients. You enable security as required, based on your application or cluster implementation, and the security concerns and tolerances of your organization. For a brief discussion of each security feature, see Oracle Coherence Security Guide.
Configure firewalls to restrict access internally. Oracle recommends that you disable port 7001 on the managed servers and use port 7002 instead. You can enable 7002 during domain installation. You remove the non-SSL port by using the Administration Console (Environment, then Servers, then AdminServer).
Table 3-1 lists the default ports, their names, and security considerations. Also see Table 3-2 for a list of the NoSQL ports that you must manage.
Table 3-1 OCECAS Default Ports
| Domain | Value | Description | Security Considerations |
|---|---|---|---|
|
All |
5556 |
NodeManager Port |
Make this port accessible to the machine running the AdminServer for the Node Manager domain. |
|
All |
7001 |
Insecure Administration Server HTTP port |
Disable this port by using the Administration Console and use the SSL port (7002) instead. |
|
All |
7002 |
Secure Administration Server HTTPS port (admin/http/t3) |
Make this port accessible to administrators during domain installation. Use instead of the insecure port (7001). |
|
All |
8088 |
Coherence port |
Make each port accessible to all other managed servers within the domain. |
|
Management |
1521 |
Oracle Database port |
Make this port accessible to the managed servers in the runtime domains. |
|
Management |
6002 |
OCECAS Management Server |
Make this port accessible to:
|
|
Runtime |
5060 |
The SIP port |
Allow access to the IMS network from this port. |
|
Runtime |
5061 |
The SIPS port |
Allow access to the IMS network from this port. |
|
UDR |
6052 |
UDR Server HTTPS port |
Make this port accessible to the system that provisions subscribers. |
See Oracle Database Security Guide for details.
OCECAS supports secure authenticated access to a NoSQL database, and Oracle recommends that you use this option. To configure secure authentication:
Install and configure NoSQL securely. See Oracle NoSQL Database Security Guide for details.
Use the Administration Console to configure credentials to access the runtime and UDR domains for accessing NoSQL. Both the runtime application and the UDR REST API retrieve these credentials.
Use these mapping details:
protocol=NOSQL
remoteHost=localhost
remotePort=5000
path= (not used)
local user = local_username (for example, OCCAS)
method=connect
remote user = NoSQL_username
remote password = NoSQL_password
Configure SSL for NoSQL by specifying the location of the Java truststore in the setUserOverrides.sh file. The truststore contains the public certificate that validates the NoSQL server. You edit this file in the managed servers of every runtime and UDR domain. See "SSL Model" in Oracle NoSQL Database Security Guide for more information.
Manage the NoSQL ports listed in Table 3-2 to secure OCECAS runtime domains that include NoSQL databases.
Table 3-2 NoSQL Management Ports
| Port No | Description | Security Considerations |
|---|---|---|
|
5000 |
NoSQL Data Store Port |
Make this port accessible to the managed servers in the runtime domains, and to the managed servers. |
|
5010-5020 |
NoSQL replication ports |
Replication Nodes use this range of ports to communicate among themselves. Each machine hosting a NoSQL store must have access to the other NoSQL store instances using this port range. See Oracle NoSQL Database Administrator's Guide for more information. |
|
5110-5120 |
NoSQL service ports |
Administrative servers running on a storage node use this range of ports to communicate with managed services. |
Where possible, use SIPS for all SIP communication. Your P-CSCF authenticates SIP traffic against information stored in the HSS. Requests forwarded to OCECAS contain the P-Asserted-Identity header which OCECAS honors. For more information, see ”Overview of SIP Servlet Identity Assertion Mechanisms” in Oracle Communications Converged Application Server Security Guide.
Other ways of improving security for OCECAS include securing SIP and handling challenges from the IMS Core.
OCECAS offers secure SIP (SIPS) connections, using TLS to secure signalling. OCECAS also uses two-way SSL to verify the digital certificate supplied by the client. Ensure that a SIPS transport (SSL) has been configured in order to use client-certificate authentication. For more information about configuring SSL, see Oracle Database Advanced Security Administrator's Guide.
Weblogic Server includes functions that map credentials for managing remote user names and passwords securely. It also has functions for retrieving those remote user names and passwords. After the remote SNMP trap manager changes the passwords, the credential mappings can be reconfigured by using the Administration Console.
To secure SNMP, complete these tasks:
OCECAS supports the SNMPv3 authentication and privacy features. For a secure installation, enable both using the Administration Console:
Open the Administration Console for a runtime domain.
See Evolved Communications Application Server System Administrator's Guide for details.
From the Domain Structure, click Security Realms.
The Summary of Security Realms page appears.
Select a security realm.
The Settings for RealmName page appears.
Click the Credential Mappings tab, and then click the Default subtab.
Click New.
The Create a New Security Credential Mapping page appears.
Create a credential mapping for storing the authentication pass-phrase, by specifying the following:
Protocol. For example SNMP.
Remote Host. Enter the SNMP management system remote host IP address.
Remote Port. Enter the SNMP management system remote port.
Path. The path to the SNMP credential store on the SNMP management system.
Method. Enter the authentication method, for example auth.
Click Next.
Specify the following:
Local User. Enter the name of the WebLogic Server user for this credential mapping.
Remote User. Enter the name of the remote user to which the local user maps.
Remote Host. Enter the SNMP management system remote host IP address.
Remote Password. The authentication pass phrase (provided by the SNMP Management System).
Click Finish.
To create a credential mapping for storing the privacy pass-phrase, repeat the steps above with the substitutions shown here:
Method - priv
Remote password - The privacy pass phrase provided by the SNMP management system.
Note the Resource Identifier of each mapping created by WebLogic, for example:
Auth: type=<remote>, protocol=SNMP, remoteHost=snmphost, remotePort=162, method=auth Priv: type=<remote>, protocol=SNMP, remoteHost=snmphost, remotePort=162, method=priv
On the management domain that triggers SNMP traps:
Open the Administration Console.
See Evolved Communications Application Server System Administrator's Guide for details.
Navigate to Evolved Communications, then Alarm, then Advanced.
Configure the settings as follows:
Security Level: AUTH_PRIV
Security Username: The username to access the SNMP management system.
Authorization Resource ID: copy the Resource Identifier for method auth created by WebLogic in "Creating SNMP Credential Mapping on Runtime Domains".
Privacy Resource ID: Enter the Resource Identifier for method auth created by WebLogic in "Creating SNMP Credential Mapping on Runtime Domains".
To grant AlarmMX permission to invoke operations provided by the DefaultCredientialMapperMBean:
Log in to the Administration Console for the management domain.
See Evolved Communications Application Server System Administrator's Guide for details.
Navigate to Security Realms, and then click realm_name.
Enable Use Authorization Providers to Protect JMX Access.
Activate the change.
Restart the Administration Server.
Navigate to Roles and Policies, then Realm Policies, and then JMX Policy Editor.
Ensure that GLOBAL SCOPE is selected.
Click Next.
Expand weblogic.security.providers.credentials.
Click DefaultCredentialMapperMBean.
Click Next.
Click Lookup Operations: Permission to Invoke Expand Node Lookup Operations: Permission to Invoke.
Click Create Policy.
Create a policy for the weblogic user.
See Oracle Communications Converged Application Server System Administrator's Guide for more information.
SNMP trap details and the management host & port are configured by using the Administration Console. Navigate to Evolved Communications Configuration, then Alarm to make changes.
The Session Design Center GUI uses JMS Modules. The JMS Modules for EDR generation are secured by default. However, the JMS Module for scfCompiler uses a JDBC Connection to the database, which is not secure by default.
See Oracle Fusion Middleware Securing a Production Environment for Oracle WebLogic Server and Oracle Database Security Guide for more information about securing database clients.
OCECAS uses basic authentication to secure the Session Design Center GUI and its associated REST interface. Credentials are passed in clear-text. Therefore, configure the server to support only secured access, HTTP over SSL.
OCECAS provides basic authentication by default. Basic authentication uses HTTP headers to transmit the user name and password to OCECAS. Basic authentication is not recommended for production systems unless you can ensure that all connections between clients and the WebLogic SIP server instance are secure.
With basic authentication, a client requests access to a protected resource. The web server displays a login screen that requests the user name and password. The client then submits the user name and password to the server. The server validates the credentials and, if successful, returns the requested resource.
HTTP basic authentication is not secure. Basic authentication sends user names and passwords over the Internet as text that is uu-encoded (UNIX-to-UNIX encoded) but not encrypted. This form of authentication, which uses base64 encoding, can expose your user names and passwords unless all connections are over SSL. If someone can intercept the transmission, the user name and password information can be easily decoded.