On this page:

• Securing Servlets
  • Servlets
    • communication_manager
    • client
    • administrator
    • voicemail
    • recording
  • SSL Keystore
    • Creating A Self Signed SSL Keystore
  • Enabling And Disabling Security Contexts
  • SSL
  • Realm Authentication
  • IP Access
    • Behavior

iSymphony opens several ports for communication with the outside world. These ports include the Web Ports used by the server to provide both the Administration and Client web interfaces, the REST API and Voicemail and Recording Agent file servers. The iSymphony server is broken up into several subsections call servlets. Each servlet can have several layers of security activated on them in order to prevent unauthorized access and man in the middle attacks.

Securing Servlets

Your iSymphony install contains the file /opt/isymphony3/server/conf/security.xml. This file contains the security settings for all servlets in the application.

Servlets

Each servlet in the system has a specific function and enabling security on each one will secure a different piece of the application. Each servlet that can be restricted will have a relative SecurityContext in security.xml

communication_manager

Securing the communication_manager SecurityContext will restrict access to the REST API of the iSymphony Server.

client

Securing the client SecurityContext will restrict access to the iSymphony Client Interface.

administrator

Securing the administrator SecurityContext will restrict access to the iSymphony Administration Interface.

voicemail

Securing the voicemail SecurityContext will restrict access to the Voicemail Agent file server that allows playback of voicemail in the browser.

recording

Securing the recording SecurityContext will restrict access to the Recording Agent file server that allows playback of recordings in the browser.

SSL Keystore

The SSLKeystore tag in security.xml allows you to define the keystore that contains the SSL certificate to use when SSL is enabled on a particular servlet. You must specify the filename of the keystore, keystorePassword, the keyPassword, and the certAlias.

Creating A Self Signed SSL Keystore

1. The following method requires the Oracle JDK.

2. Run the following command to create your SSL keystore. Follow the prompts to finish creating the keystore.

   keytool -keystore <filename> -alias <alias> -genkey -keyalg RSA -validity <number of days cert is valid>

3. Export the generated public key from the keystore by running the following command:

   keytool -export -keystore <keystore file name from step2> -alias <alias> -file <filename>

• Import the public key into the java trust store (cacerts) located in the java home directory:

  keytool -import -alias <alias> -file <file from step 3> -keystore $JAVA_HOME/jre/lib/security/cacerts

  The default password for the cacerts truststore is: "changeit". For more information on the keytool please see the Oracle documentation :
  https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html

Enabling And Disabling Security Contexts

You can enable and disable entire Security Contexts by setting the enabled attribute to true or false in the SecurityContext tag. A disabled Security Context will apply no restrictions to the servlet despite any of the inner settings.

1. SSL

You can enable and disable SSL communication encryption on a specific Security Context by setting the enabled attribute in the SSL tag to true or false.

1. Realm Authentication

You can enable or disable HTTP realm authentication on a specific Security Context by setting the enabled attribute in the RealmAuth tag to true or false. You can add a new HTTP realm authentication user by adding a RealmAuthUser tag to the RealmAuthUsers. You can specify the user's credentials by populating the username and password attributes of the RealmAuthUser tag.

1. IP Access

You can enable IP access on a specific Security Context by setting the enabled attribute on the IPAccess tag to true or false. The IPAccess restriction will allow or deny connections from specific IP addresses based on the contents of the WhiteList and BlackList in the IPAccess tag.

1. Behavior

2. IPs that are specified in the WhiteList will always be allowed to access the system unless the IP is specified in the BlackList as well.
3. IPs that are specified in the BlackList will never be allowed to access the system.
4. If no entries are specified in the WhiteList or BlackList all IPs will have access to the servlet.
5. If entries exist in the WhiteList but not in the BlackList only the IPs specified in the WhiteList will have access to the servlet.