Go to primary content
Siebel CRM Siebel Security Guide
Siebel Innovation Pack 2017, Rev. A
E24814-01
  Go to Documentation Home
Home
Go To Table Of Contents
Contents
Go To Index
Index

Previous
Previous
 
Next
Next
    View PDF

Types of Encryption

Encryption is a method of encoding data for security purposes. Siebel Business Applications support industry standards for secure Web communications, and for encryption of sensitive data such as passwords. The following topics outline the standards supported:

Communications Encryption

To make sure that information remains private, Siebel Business Applications support the use of the following encryption technologies for communications:

  • TLS encryption for Web client connections. For data security over the Internet, Siebel Business Applications support the use of the Transport Layer Security (TLS) capabilities of supported Web servers to secure transmission of data between the Web browser and the Web server. The use of TLS for Web server and Siebel Web Client communications is transparent to Siebel Business Applications. For information on configuring TLS for Web server communications with the browser, see the vendor documentation.

    Siebel Business Applications can be configured to run completely under HTTPS or simply handle login requests under HTTPS. For more information, see "About the Siebel Web Client and Using HTTPS" and "Implementing Secure Login".

  • Encryption for Siebel component connections (TLS). Siebel administrators can enable encryption for communications between Siebel components. The Siebel communications protocol provides a security and compression mechanism for network communications based on TLS.

    By default, encryption based on TLS uses the AES algorithm with 256-bit encryption keys.

    TLS also supports certificate authentication between the Web server and the Siebel Server, or between Siebel Servers.

  • TLS encryption for connections to directory servers. TLS encryption is supported for connections to certified LDAP directories.

  • TLS encryption for connections to email servers. TLS encryption is supported for connections to email servers using Siebel Communications Server components. TLS encryption is supported for connections to Microsoft Exchange Server 2007 or 2010 email servers. For information, see Siebel Email Administration Guide.

  • Encryption of communications between the Siebel Server and the Siebel database. The encryption technologies available to encrypt communications between the Siebel Server and the database depends on the encryption methods supported by your RDBMS vendor. For information on how to configure communications encryption between the Siebel Server and the Siebel database, contact your third-party RDBMS vendor.

Figure 4-1 shows some of the types of communications encryption available for Siebel Business Applications environment.

Figure 4-1 Communications Encryption in the Siebel Application Environment

Communications encryption in Siebel environments.

The encryption mechanisms illustrated in Figure 4-1 are as follows:

  1. Web client and mobile client connections. TLS is used to secure transmission of data between the Web browser and the Web server.

    Note that a reverse proxy should be placed in front of Siebel Application Interface for the following specific topologies:

    • When Single Sign-On (SSO) is configured with Siebel Application Interface.

      If using a compatible SSO solution such as Oracle Access Manager and Oracle Webgate, then you can use any Web server to provide reverse proxy functionality and also any Siebel compatible SSO Web server plug-in on that Web server, provided the plug-in is supported by the Web server platform.

    • When Siebel Application Interface cannot be deployed or hosted in a DMZ.

      Here, you can configure a reverse proxy in the DMZ for Siebel Application Interface, which is expected to be hosted inside a firewall. You can use any Web server to configure this.

      For more information on reverse proxies in the DMZ, consult your web server vendor documentation.

  2. Siebel Mobile Web Client connections. You can use RSA encryption for Mobile Web Client communications with the Siebel Remote Server.

  3. Email server connections. TLS encryption for connections to email servers is supported.

  4. Siebel component connections. Communications between Siebel components are based on TLS algorithms.

Certificate Requirements for Communications

Siebel installer for Siebel Business Applications enforces HTTPS during installation, as follows:

  • Siebel Web Clients, Siebel Management Console and the Siebel Migration server all communicate with the Siebel Application Interface over HTTPS (as shown in Figure 4-2).

  • All communication between Siebel services (Siebel Application Interface, Siebel Gateway, Siebel Configuration Agent, Siebel Enterprise Cache, and Siebel Constraint Engine) are enforced over HTTPS by Siebel installer (as shown in Figure 4-2).

  • Siebel Application Interface is an external interface accessing Siebel services. All other Siebel services are internal services and they are protected by client certificate based authentication (as shown in Figure 4-2).

  • Any Siebel service-to-service access is over HTTPS with client certificate based authentication (for example, two-way SSL). Client certificates are used for service-to-service authentication (as shown in Figure 4-2).

Figure 4-2 Certificate Requirements for Communications

Certificate requirements for communications.

Certificate requirements for communications are illustrated in Figure 4-2 as follows:

  1. Siebel Application Interface, Siebel Gateway, Siebel Configuration Agent, Siebel Enterprise Cache and Siebel Constraint Engine are hosted in application containers (Apache Tomcat).

    For information on configuring application containers, see Siebel Installation Guide for the operating system you are using. For information on starting and stopping application containers, see Siebel System Administration Guide.

  2. During Siebel installation (of the aforementioned components), the installer prompts you to specify valid keystore and truststore files, as follows:

    • Keystore Name. Specify a file (such as a JKS file) you have generated that will serve as the keystore.

      For example, import the client or server certificate into the keystore using the Java Keytool utility.

    • Truststore Name. Specify a file (such as a JKS file) you have generated that will serve as the truststore.

      For example, import the Certificate Authority (CA) certificate into truststore using the Java Keytool utility.

      Since Siebel internal nodes are configured for client certificate based authentication, make sure that you use the correct client identity in the CN and Subject Alternate Name (SAN) fields. You can create certificates with the exact FQDN or IP address, or with a wildcard in the FQDN. For example, if you replace host.domain.subdomain.com with *.domain.subdomain.com, then this eliminates the need to create separate client certificates for each machine.


      Note:

      It is recommended that you use the certificates provided by the Certificate Authority (CA) rather than self-signed certificates. For production environments, you must create a certificate request and get it signed either by your internal CA (for employee-only environments) or an external CA (for customer, consumer, or partner environments). Self-signed certificates are suitable for development environments, for example, where you can provide instructions to users to import the self-signed certificate, since clients will not trust such a certificate unless it is manually installed into the certificate store.

      For more information, see "About Keystore and Truststore Files".

    • Password. Specify the password for the specified keystore and truststore files.

    • Confirm Password


    Note:

    The use of certificate extensions Extended Key Usage is not permitted for TLS client authentication. As a result, you must ensure that the certificate extension is used properly for both client and server certificates.

Disabling Certificate Based Mutual Authentication

You can disable certificate based authentication and run all components over HTTPS, however, this action is not recommended for security reasons. The following procedure shows you how to disable certificate based authentication.

To disable certificate based authentication 

  1. Set clientAuth="false" in the conf\server.xml file for Siebel Gateway, Siebel Configuration Agent, Siebel Enterprise Cache, and Siebel Constraint Engine to disable certificate based mutual authentication.

    For example, set the HTTPS connector as follows to keep all communication over HTTPS without client certificate authentication:

    <Connector port="xxxx" protocol="org.apache.coyote.http11.Http11NioProtocol"maxThreads="150" SSLEnabled="true" scheme="https" secure="true"SSLVerifyClient="require" SSLEngine="on" SSLVerifyDepth="2"keystoreFile=" xxxx" keystorePass=xxx" " keystoreType="JKS"truststoreFile="xxx " truststorePass="xxx " truststoreType="JKS"clientAuth="false" sslProtocol="TLS" />
    
  2. Restart the application containers for all components: Siebel Application Interface, Siebel Gateway, Siebel Configuration Agent, Siebel Enterprise Cache, and Siebel Constraint Engine. For details, see Siebel System Administration Guide.

  3. Access the UI using the following address: HTTPS://<hostname>:https_port/.

Disabling HTTPS

You can disable certificate based authentication and run all components over HTTP, however, this action is not recommended for security reasons. The following procedure shows you how to disable HTTPS.

To disable HTTPS 

  1. Set clientAuth="false" in the following properties files:

    • applicationinterface.properties

    • gateway.properties

    • configagent.properties

    • cache and constraint engine properties file, if they are part of run time.

  2. Set the <transport-guarantee> value to NONE instead of CONFIDENTIAL.

    You must do this in the web.xml file for Siebel Application Interface, Siebel Agent, Siebel Configuration Agent, and any other component that is part of run time.

    <security-constraint><web-resource-collection><web-resource-name>securedapp</web-resource-name><url-pattern>/*</url-pattern></web-resource-collection><user-data-constraint><transport-guarantee>NONE</transport-guarantee></user-data-constraint></security-constraint>
    
  3. Set the server parameters SecureLogin and SecureBrowser to False for the Object Manager.

  4. Update the CGHostURI value in the applicationinterface.properties file with the http port.

    This step is required in case bootstrapping of Siebel Application Interface and Siebel Gateway is carried out over the HTTPS port by Siebel Management Console.

  5. Restart the application containers for all components: Siebel Application Interface, Siebel Gateway, Siebel Configuration Agent, and any other components that are part of run time. For details, see Siebel System Administration Guide.

  6. Access the UI using the following address: HTTP://<hostname>:http_port/.

About Keystore and Truststore Files

The keystore and truststore files are JKS files containing certificates. These files are necessary for the application container to be able to use secure two-way communications when connecting with other Siebel modules, as occurs during Siebel Management Console configuration and in normal operation. Note the following about generating the keystore and truststore files:

  • The keystore and truststore files must contain the server certificate chain and an imported CA certificate.

  • Generate your files so that the keystore file references both the private key and the public key, while the truststore file references the public key only.

  • Specify the password that was previously configured to open the certificate files.

  • Use the same password for the keystore and truststore files.


    Note:

    It is recommended that you create all keystores with the same password as the one entered in the installer. The ability to have different passwords for the truststore and keystore is not currently supported by the installer. However if different passwords are required, then you can modify the keystore password by editing the server.xml file and all the relevant properties files in the webapps directory.

  • Use the fully qualified domain names rather than IP addresses.


    Note:

    If you use IP address instead of FQDN, then certificates must be created with both FQDN and IP address as two separate SAN entries and in such cases, the Siebel Server fails. As a result, it is recommended that you use the FQDN rather than IP address.

If you do not configure the keystore and truststore files correctly, then you will not be able to configure the Siebel Business Applications, as described in "Configuring Security Adapters Using the Siebel Management Console", Appendix A, "Configuration Parameters Related to Authentication" and Siebel Installation Guide for the operating system you are using.

Modifying Keystore and Truststore Files

In cases where it is necessary to modify the keystore and truststore file details, complete the steps in the following procedure.

To modify keystore and truststore files 

  1. Go to the location where the keystore and truststore files are stored.

    This location is specific to Siebel Application Interface, Siebel Agent, Siebel Configuration Agent, or any other component.

  2. Use the Java Keytool commands to edit the keystore and truststore file details as required.

    It is recommended that you keep the same keystore and truststore names and passwords to avoid editing the corresponding properties and server.xml files. However, in the event where you change the keystore and truststore names and passwords, then do the following to change the details in the properties and server.xml files:

    1. Encrypt the password using the encryptstring.jar utility

      $<javahome>\bin>java -jar $<siebelhome>\siebel\classes\original\encryptstring.jar <<plaintext>><web-resource-collection>
      
    2. Go to the properties file and update the KeyStorePassword and TrustStorePassword with the encrypted value.

    3. Go to the server.xml file (located under ..\conf) and update the truststorepass and keystorepass with the encrypted value.

    4. To change the password, update the truststorepass and keystorepass in the conf\server.xml file for Siebel Application Interface, Siebel Gateway, Siebel Configuration Agent, Siebel Enterprise Cache, and Siebel Constraint Engine.

      Update truststorepass and keystorepass under the HTTP connector.

      Update the plain text password here:

      $<javahome>\bin>java -jar <connector port="<https port>" ….  keystorepass="xxx" …. truststorepass="xxx"/>
      
  3. Restart the application containers for all components where you made changes. For details, see Siebel System Administration Guide.


    Note:

    Alternatively, in the event where you installed Siebel Innovation Pack 2017 using the keystore file test.jks but used incorrect domain name or hostname credentials when creating the jks file, then do the following to use the newly created certificate (provided the password is the same) without re-installing Innovation Pack 2017:
    • Copy the new JKS file (with the same password, but with different domain name and hostname) to the siebcerts folder under Siebel Application Interface, Siebel Agent, Siebel Configuration Agent, or any other component.

    • Restart the application containers. For details, see Siebel System Administration Guide.


Data Encryption

To make sure that information remains private, Siebel Business Applications support the use of the following encryption technologies for storing data:

  • AES database encryption. Siebel Business Applications allow customers to encrypt sensitive information stored in the Siebel database (for example, credit card numbers, Social Security numbers, birth dates, and so on) so that it cannot be viewed without access to the Siebel application.

    Customers can configure Siebel Business Applications to encrypt a column's data before it is written to the database and decrypt the same data when it is retrieved. This encryption prevents attempts to view sensitive data directly from the database. Sensitive data can be encrypted by using AES encryption at various key lengths. Encryption can be enabled using Siebel Tools. For more information, see "About Data Encryption".

    Siebel Business Applications also use AES encryption to encrypt passwords stored in the Siebel Gateway registry. The Siebel Gateway registry stores information required by the gateway. For more information about encrypted passwords in the Siebel Gateway registry, see "About Encryption of Siebel Gateway Password Parameters".

  • RSA SHA-1 password hashing. Siebel administrators can enable password hashing for user passwords or for database credentials. Hashing uses a one-way hashing algorithm. The default password hashing method is RSA SHA-1.

    The Siebel administrator password is stored for Siebel Gateway in the Siebel Gateway registry, and is not hashed; passwords in the Siebel Gateway registry are encrypted using AES encryption.

    Password hashing invalidates the password to unauthorized external applications and prevents direct SQL access to the data by anything other than Siebel Business Applications. For more information, see "About Password Hashing".

  • Encryption of the Siebel File System and server disks containing Siebel Business Applications data. It is recommended that you encrypt the Siebel File System and all server disks containing Siebel Business Applications data using third-party products or encryption features provided by your operating system. For information on the encryption technologies available, see the relevant operating system or third-party documentation. For additional information about securing the Siebel File System, see Appendix C, "Siebel Security Hardening".