11 Configure Security in Oracle Database Lite

The following sections detail how to manage security in Oracle Database Lite:

Note:

There is additional information about developing for security in the "Security" chapter in the Oracle Database Lite Developer's Guide.

11.1 Security Enhancements

A number of security enhancements have been made, as follows:

  • It is possible to restrict the database privileges for the MOBILEADMIN user, once the application has been published.

  • Passwords for all default accounts can be chosen at install time.

  • Remote HTTP access to the Mobile Client Web-to-Go has been disabled by default.

  • The Windows Service for the Branch Office listener runs under a restricted Windows user. In fact, the Windows services run under a non-priviledged user in the Branch Office configuration.

11.2 Which Password is Which?

In the Oracle Database Lite product, there are several username/password combinations that are used for different security reasons and for separate types of users or administrators. This section describes each of the username/password combinations in order to eliminate confusion.

Figure 11-1 Components That Use Passwords

Password components
password components
Description of "Figure 11-1 Components That Use Passwords"

As shown in Figure 11-1, the passwords for the Mobile client environment are as follows:

  1. When the Mobile Server accesses the Mobile repository, it uses the repository username/password. This defaults to the user MOBILEADMIN and the password is set during install. When the user accesses the user data in the Mobile Server repository, the Mobile Server connects using the Mobile repository username, where the Mobile user name and password are authenticated before access is provided to the user data.

  2. The Mobile Manager is a Web administration UI that provides administrators the ability to modify how the Mobile Server behaves. Only administrators can use this tool; thus, only Mobile Server administrators can log in with their passwords. The initial administration username/password is created during installation. For adding or modifying, use the Mobile Manager to modify these on the Mobile Server.

  3. Within the Mobile Server, there are two types of username/password combinations—both of which are created using the Mobile Manager UI: administrator and Mobile user.

  4. The Mobile user provides its username/password when synchronizing, which Mobile Server uses to verify that this use can access the application data. The Mobile username and password are stored in two places: the Mobile Server repository and the Oracle Lite database associated with this user (the ODB file). Thus, when you modify the Mobile user password, you must perform one of the following:

    • Modify the password on the client using either mSync UI or Client Workspace. Only modify the password using these tools if you are connected to the Mobile Server to ensure that the user password change is propagated to the Mobile repository.

    • Modify the Mobile user password in the Mobile Manager in the User Properties page. If you simply want to invalidate the Mobile user, then you only have to modify the password on this screen; however, if you want to reset the password on both the Mobile Server and the Mobile user, then also send a Reset Password command from the Device Management section in the Mobile Manager to the Mobile client.

  5. Every Oracle Lite database (ODB file) has the SYSTEM user for connecting. Oracle Database Lite uses SYSTEM as the username and then the Mobile user password as the password when connecting during synchronization.

  6. By default, each ODB file is not encrypted. If you want to encrypt the database, perform one of the following:

    • If you are using the Oracle Lite database as part of the Mobile option, where you are syncrhonizing the user data to a back-end server, then set the polite.ini ENCRYPT_DB parameter. Oracle Database Lite will then automatically encrypt the Oracle Lite database with the user password. For details on this parameter, see Section F.3.2.12, "ENCRYPT_DB".

    • If you are using the Oracle Lite database as an embedded database or standalone database—with no synchronization ability—then encrypt the database using the encrypdb utility and provide your own password to use for encrypting the database. See Appendix A.4 "ENCRYPDB" in the Oracle Database Lite Developer's Guide for details.

Figure 11-2 Branch Office Passwords

Branch Office passwords
Branch office password
Description of "Figure 11-2 Branch Office Passwords"

If you have a Branch Office configuration, then the following additional username/password combinations exist:

  1. Branch Office is installed as a Windows server with the username of OracleDatabaseLite with the minimum set of privileges required to execute the Oracle Database Lite software. Only the Branch Office can initialize the synchronzation; the remote clients cannot.

    Normally, when installed, the password for the OracleDatabaseLite user is randomly generated during the setup. You can either pre-configure this password before the Branch Office installation or modify it after the configuration. See Section 3.5.3, "Defining Password for OracleDatabaseLite User for Branch Office on Windows Machine" in the Oracle Database Lite Getting Started Guide.

  2. The remote clients access the Oracle Lite database through Branch Office; thus, the username/password for the remote client is validated by Branch Office.

11.3 Configuring SSL For Mobile Server

Oracle Database Lite supports Secure Socket Layer (SSL) communication between the Mobile Server and Mobile clients. Oracle Database Lite uses the SSL that is embedded within OC4J, which is shipped as part of Mobile Server.

Note:

If you choose to install standalone Mobile Server, the standalone OC4J is installed; otherwise, Mobile Server is installed on top of an existing OracleAS stack. OracleAS also includes OC4J, but the configuration for SSL is more involved. This chapter covers the basic SSL configuration for the standalone Mobile Server. See the Oracle Application Server Containers for J2EE Security Guide for more information on all aspects of configuring SSL for OracleAS.

This chapter assumes that you understand the concepts behind SSL and provides only the steps for using keys and certificates for SSL communication for the standalone Mobile Server.

Note:

These are server-level steps which are typically executed prior to deployment of an application that requires SSL communication.

11.3.1 Creating an SSL Certificate

SSL communicates by validating an SSL certificate between the client and the server. This section describes how to ceate the SSL certificate. However, often when you are first starting with new functionality, you may want to use a temporary certificate just to see how the SSL functionality works.

Oracle Database Lite ships a sample keystore file with a self-signed sample certificate. The password for this sample keystore file is oracle. Use this keystore only for development or testing purposes. Obtain a signature from a recognized certificate authority for all production systems. The test keystore is located in the following directory:

ORACLE_HOME\Mobile\Server\Bin\samplekeystore

To create a keystore file, perform the following steps:

  1. Use the Sun Microsystems Java keytool utility to generate a private key, public key, and an unsigned certificate. Place this information into either a new or existing keystore.

    Note:

    A keystore is a java.security.KeyStore instance that you create and manipulate using the keytool utility, which is provided with the Sun Microsystems JDK. See http://java.sun.com/j2se/1.5.0/docs/tooldocs for more information on the keytool utility.

  2. Obtain a signature for the certificate, using either of the following approaches:

    • Generate your own signature by using keytool to self-sign the certificate. This is appropriate only if your clients trust you as your own certificate authority.

    • Obtain a signature from a recognized certificate authority through the following steps:

    1. Using the certificate from Step 1, use keytool to generate a certificate request, which requests a certificate authority to sign the certificate.

    2. Submit the certificate request to a certificate authority.

    3. Receive the signature from the certificate authority and import it into the keystore using keytool. In the keystore, the signature is matched with the associated certificate.

If you install the Mobile client using setup.exe after you create the self-signed certificate, then a message pops up asking if you want to continue. If you click Yes, then a parameter is added to the polite.ini that tells Oracle Database Lite to not validate the certificate. However, if you install the Mobile client using any other method, you need to set this parameter yourself. Set the SSL_IGNORE_CERT parameter in the polite.ini file to 1.

Each certificate authority has its own process for requesting and receiving signatures. Since this is outside the scope and control of Oracle Database Lite, it is not covered in Oracle Database Lite documentation. However, the SSL section in the Oracle Application Server Containers for J2EE Security Guide has an example of how to generate your own keystore. For other information, go to the Web site of any certificate authority. Each browser lists trusted certificate authorities. Here are the Web addresses for VeriSign, Inc. and Thawte, for example:

http://www.verisign.com/
http://www.thawte.com/

11.3.2 Configuring Mobile Server for SSL

Once you have a certificate, you must configure SSL in the application server that is installed with the Mobile Server. When you installed, you chose to install the Mobile Server either in standalone mode or to use the application server. Both of these environments are discussed below:

11.3.2.1 Configuring SSL for Mobile Server With OracleAS

For production systems, you install OracleAS before you install the Mobile Server. You must configure SSL on both the application server and the Mobile Server, as follows:

  1. Configure SSL in the application server using the administration GUI. The directions on how to configure SSL when using OracleAS as your middle-tier is in the SSL or HTTPS chapter in the Oracle Application Server Containers for J2EE Security Guide.

  2. Configure SSL in the Mobile Server by adding SSL=YES in the [WEBTOGO] section of the webtogo.ora file. In the Mobile Manager, migrate to the Administration tab and select Edit Config file. This is the webtogo.ora file.

  3. After all configuration is complete, restart the application server to initialize the changes.

11.3.2.2 Configuring SSL for Standalone Mobile Server

With the standalone Mobile Server, the standalone version of the OC4J application server is installed with the Mobile Server. To configure SSL for this environment, you modify the Mobile Server webtogo.ora file and certain XML elements within the OC4J XML configuration files, as follows:

  1. Configure SSL in the Mobile Server by adding SSL=YES in the [WEBTOGO] section of the webtogo.ora file. In the Mobile Manager, migrate to the Administration tab and select Edit Config file. This is the webtogo.ora file.

  2. If you do not have a secure-web-site.xml file, then copy and rename the default-web-site.xml to ORACLE_HOME\mobile_oc4j\j2ee\mobileserver\config\secure-web-site.xml.

  3. Edit the secure-web-site.xml file with the following elements:

    1. Add secure="true" to the <web-site> element, as follows:

      <web-site port="443" display-name="Oracle Application Server Containers for J2EE Web Site" secure="true">

    2. Add the following new line inside the <web-site> element to define the keystore and the password:

      <ssl-config keystore="YourKeystore" keystore-password="YourPassword" />

      where YourKeystore is the path and name of the keystore and YourPassword is the keystore password. The path for the keystore can either be a full path or a path that is relative to ORACLE_HOME\j2ee\mobileserver\config. In addition, you can hide the password through password indirection. This is discussed fully in the Oracle Application Server Containers for J2EE Security Guide. For example, with a keystore of "../../keystore" and password of "oracle", the configuration is as follows:

      <!-- Enable SSL --><ssl-config keystore="..\..\..\..\mobile\server\bin\samplekeystore"                      keystore-password="oracle"/>

    3. Change the <web-site> element port number to use an available port. The reason you must change the port is because you copied this file from default-web-site.xml, which uses the port that is currently configured. Thus, choose a port that can be used for SSL communication; for example, the default for SSL ports is 443.

    4. Save the changes to secure-web-site.xml.

  4. Edit the server.xml file to point to the secure-web-site.xml file.

    1. Uncomment or add the following line in the file server.xml so that the secure-web-site.xml file is added to the OC4J initialization.

      <web-site path="./secure-web-site.xml" />

    2. Save the changes to the server.xml file.

  5. Stop and re-start OC4J to include the secure-web-site.xml file modifications.

  6. Test the SSL port by accessing the Mobile Server in a browser on the SSL port. For example, https://<yourserver>:443/webtogo.

    If you are using the test keystore file or your own self-signed certificate, you will be asked to accept the certificate, since the SSL certificate used is not signed by an accepted certificate authority. When completed, Mobile Server listens for SSL requests on the port configured in the secure-web-site.xml file and listens for non-SSL requests on the port configured in the default-web-site.xml file. You can disable either SSL requests or non-SSL requests, by commenting out the appropriate *web-site.xml in the server.xml configuration file.

    <web-site path="./secure-web-site.xml" /> - comment out this to remove SSL
<default-site path="./default-web-site.xml" /> - comment out this to remove non-SSL

11.3.3 Enabling SSL Authentication for Web-to-Go Clients

For most Mobile clients, the SSL libraries used are the Microsoft SSL libraries. In this case, the SSL handshake occurs seamlessly. However, Web-to-Go clients use Oracle SSL libraries, which assumes that the SSL certificate is installed on the Mobile client.

In order to have the SSL certificate automatically installed on the Web-to-Go Mobile client, perform the following:

  1. Upload the SSL certificate, which you created to the Mobile Server, as follows:

    1. Navigate to the Administration page for your Mobile Server in the Mobile Manager.

    2. Click Server Certificate.

    3. As shown in Figure 11-3, browse to the SSL certificate and click Upload.

      Figure 11-3 Upload SSL Certificate

      SSL certificate upload
      Description of "Figure 11-3 Upload SSL Certificate"

  2. Download the setup.exe for the Web-to-Go Mobile client. The SSL certificate that was uploaded is automatically installed with the Web-to-Go Mobile client.

11.3.4 Troubleshooting Error Messages for an SSL-Enabled Mobile Server

The following errors may occur when using SSL certificates on your Mobile Server:

No available certificate corresponds to the SSL cipher suites which are enabled
Cause: Something is wrong with your certificate.
Action: Examine your certificates and check that at least one of them supports the SSL cipher suite you are using.
IllegalArgumentException: Mixing secure and non-secure sites on the same ip + port
Cause: You cannot configure SSL and non-SSL Web sites to listen on the same port and IP address.
Action: Check to see that different ports are assigned within secure-web-site.xml and either default-web-site.xml or http-web-site.xml files.

11.3.5 Client-Side Configuration for Secure Socket Layer (SSL)

As the end user, you can configure the Mobile client for OC4J or Web-to-Go to establish an SSL connection between the Mobile client and the Mobile Server.

The following sections describe how to enable SSL for your Mobile client:

11.3.5.1 Communication between the Mobile Client and the Mobile Server

Based on whether or not you download the Mobile client for OC4J or Web-to-Go from the Mobile Server running in SSL, you can choose to configure communication between the Mobile client for OC4J or Web-to-Go and the Mobile Server. The following sections provide a description of configuring communication between the Mobile client and the Mobile Server.

11.3.5.1.1 Mobile Client Download from a Mobile Server which is Running in SSL Mode

The Mobile client for OC4J or Web-to-Go which is downloaded from the following URL is automatically configured for SSL and does not require manual configuration on the part of the end user. This download enables the Mobile client to communicate with the Mobile Server in SSL mode.

https://<mobile_server>:<port>/setup

11.3.5.1.2 Mobile Client Download from a Mobile Server which is not Running in SSL Mode

If you have downloaded the Mobile client for OC4J or Web-to-Go from a Mobile Server, which is not running in SSL mode, modify the SERVER_URL parameter in the webtogo.ora file as follows.

SERVER_URL=https://<mobile_server>:<port>/webtogo/setup

Note:

in the location bar, you must type https, to specify and indicate the SSL Mode, and not http.

11.3.5.2 Connection between the Browser and the Mobile Client for OC4J or Web-to-Go

While trying to connect to the Mobile client for OC4J or Web-to-Go in SSL mode, you will not be able to connect to the Mobile client, even if the following conditions exist.

  1. The Mobile Server is running in SSL mode, as a module of Oracle9iAS.

  2. The Mobile client for OC4J or Web-to-Go is also running in SSL mode.

To connect to the Mobile client for OC4J or Web-to-Go using a browser, you must specify HTTP and not HTTPS in the client URL, although the communication between the client and the server is through the HTTPS protocol.

For example, http://<client_machine>/webtogo

11.3.5.3 Support for Non-SSL Mobile Clients

Mobile Servers running in SSL mode possess the ability to synchronize with any Mobile client which is running in SSL or non-SSL mode. But, in the case of the Mobile client for OC4J or Web-to-Go, the client also runs in SSL mode to synchronize with the Mobile Server, which is running in SSL mode.

As SSL is not supported on many Mobile clients, the Mobile Server, which, is running in SSL mode, still supports Mobile clients that are running in non-SSL mode.

Note:

Inside the Oracle Application Server, the Mobile Server runs on both SSL and non-SSL ports, to support SSL and non-SSL clients. The application server must be configured to run on both SSL and non-SSL ports, as a default function.

11.4 Encrypting the Client Oracle Lite Database

Whether you are using a Mobile client or an embedded application, you can encrypt the database used on the client.

11.5 Using a Firewall Proxy or Reverse Proxy

Normally, the Mobile client synchronizes data inside a firewall on the corporate intranet, where the Mobile Server also resides. However, what if the user wishes to synchronize the Mobile client either from the internet, which is outside the firewall to a Mobile Server that exists inside the firewall? Or what if the Mobile Server exists on the public internet and the Mobile client is inside the firewall on the corporate intranet? Either way, you have to modify your configuration to enable a Mobile client and Mobile Server to communicate through a firewall.

One can think of many scenarios in which case mobile users want to connect to the corporate server, without being directly connected to the corporate intranet. The corporate firewall uses proxy support to allow the mobile user to connect to the server. The following sections describe how to configure the Mobile Server and Mobile client to communicate through a firewall:

11.5.1 Using Reverse Proxy to Communicate from Internet to Intranet

If you are traveling to a customer site and you want to synchronize over the internet to the Mobile Server inside your corporate firewall, use a reverse proxy to communicate. A reverse proxy is used whenever a client outside a corporate network wants to connect to a resource available inside the corporate network, as shown in Figure 11-4. The corporate network is protected by a firewall, which stops the outside world from having direct access with the systems inside the corporate network. However, the reverse proxy enables designated traffic that originates outside the corporate network to reach servers inside the corporate intranet.

Figure 11-4 Mobile Client Communicating With Mobile Server Through Firewall Using Reverse Proxy

Description of Figure 11-4 follows
Description of "Figure 11-4 Mobile Client Communicating With Mobile Server Through Firewall Using Reverse Proxy"

When you configure the reverse proxy, then the Mobile client communicates directly with the reverse proxy, which turns around and communicates with the Mobile Server.

Note:

The authentication on a reverse proxy server is supported only if the Mobile client's username and password are identical to those on the proxy.

In order for this communication to occur seamlessly, do the following:

11.5.1.1 Configure the Apache Web Server as a Reverse Proxy

You need to set up the Apache Web Server software for the reverse proxy, as follows:

  1. First, use Apache 2.0 or later for your proxy.

  2. Configure the proxy server to point to the Mobile Server. See the Apache Web Server documentation for instructions on how to do so.

  3. Set the following parameter in the httpd.conf configuration file:

    BrowserMatch MSIE AuthDigestEnableQueryStringHack=On

  4. When you use reverse proxy authentication, you must upper-case the username of the proxy digest.

  5. If you are using authentication, then configure the Reverse Proxy with the username/passwords for all Mobile clients that will access this reverse proxy for synchronization.

    When the msync is launched, the username/password is sent automatically to the reverse proxy for authentication; thus, if the reverse proxy is not configured with the username/password, then the connection is refused.

11.5.1.2 Set Up Mobile Server for Mobile Client Download

If you know that the Mobile client is going to be accessing the Mobile Server through a reverse proxy, then you need to configure Mobile Server with the proxy server URL. This ensures that when the setup.exe is downloaded by the client, that the client is automatically configured with the reverse proxy URL, instead of the Mobile Server URL.

So, before you download setup.exe to the Mobile client, perform the following on the Mobile Server:

  1. If your server is a Windows XP machine, you must have the Service Pack 2 installed.

  2. Configure the Mobile Server to accept communication from the reverse proxy.

    Configure the reverse_proxy parameter in the webtogo.ora configuration file on the Mobile Server, as follows:

    [WEBTOGO]
REVERSE_PROXY=http://<reverse_proxy_hostname>:<port_number>/webtogo

11.5.1.3 Download Reverse Proxy Mobile Client

After you have updated the Mobile Server with the proper reverse proxy configuration, perform the following on the client:

  1. Configure the Mobile client to communicate with the reverse proxy in one of the two following methods:

    • If you configured the Mobile Server as described in Section 11.5.1.2, "Set Up Mobile Server for Mobile Client Download", then you can download the Mobile client software directly from the setup UI. The configuration automatically points to the reverse proxy when you perform the installation of the Mobile client.

    • However, if you installed the Mobile client software from within the corporate intranet or you have a client already installed on a machine, then you must modify its configuration. Modify the polite.ini configuration file for your Mobile client. Change or add the SERVER_URL parameter in the NETWORK section of the polite.ini configuration file to point to the host/port of the reverse proxy server, as follows:

      SERVER_URL=HTTP://<reverse_proxy_host>:<port>/webtogo

      If you use the msync.exe to synchronize, then enter the hostname of the reverse proxy in the Server box.

      Note:

      If you are planning on using the Mobile client both inside and outside of the corporate internet, you may want to have two SERVER_URL definitions—one for the internal corporate Mobile Server address and one for the reverse proxy address. Then, comment the one that you are not using and uncomment the one that you are using.

  2. Perform post-installation steps for the Mobile client:

    If the Mobile client is a Windows client—such as Windows XP/2000 and WinCE devices—then Oracle Database Lite uses the WININET API for SSL over HTTP.

    The following are known issues when using SSL over HTTP:

    • The HTTP connection may slow down if you have the Auto Detect Proxy enabled in the Internet Explorer. In addition, it may also slow down if you do not have a proxy server in your network. In this case, uncheck the Automatically detect proxy option in the Internet Explorer.

    • For Windows 2000 clients, mSync may hang if you do not have all of the Microsoft patches applied.

    • If your Mobile Server or Reverse Proxy does not have a valid SSL certificate, then the Oracle Database Lite clients may stop working. This is critical if there are errors in Certificate chaining. See Section 11.5.1.4, "Enable SSL When Using a Reverse Proxy" for details.

11.5.1.4 Enable SSL When Using a Reverse Proxy

Normally, when you have a browser and you specify HTTPS for the connection between the browser and a reverse proxy, then the browser prompts for a username/password for authentication. However, with msync, a browser is not displayed. Instead, msync sends on the username/password for the user to the reverse proxy. Thus, you must have your environment configured correctly or the connection fails.

The following describes several scenarios that you may have between the Mobile client and the reverse proxy:

11.5.1.4.1 Using SSL Authentication

When you are using a reverse proxy firewall, SSL client authentication is not supported. You can only turn on server-side HTTPS authentication.

11.5.1.4.2 Using SSL Between Mobile Client and Reverse Proxy

As Figure 11-5 demonstrates, you may want to encrypt your data and authenticate using SSL when using a reverse proxy.

Figure 11-5 Mobile Client Communicating Over SSL Through Firewall Using Reverse Proxy

Description of Figure 11-5 follows
Description of "Figure 11-5 Mobile Client Communicating Over SSL Through Firewall Using Reverse Proxy"

In this case, you must install the SSL certificate on the firewall for the SSL handshake between the Mobile client and the firewall. However, for the Web-to-Go client, you must upload the same certificate on the Mobile Server as described in step 4 in Section 11.3.3, "Enabling SSL Authentication for Web-to-Go Clients".

If you are using a certificate that is not signed by a trusted authority or if you want to disable SSL authentication, see Section 11.5.1.4.4, "Using Certificates That Are Not Signed By Trusted Authority".

11.5.1.4.3 Using SSL Between Firewall and Mobile Server

As Figure 11-6 demonstrates, you may want to encrypt your data and authenticate using SSL when using a reverse proxy for all communication between the Mobile client and the Mobile Server. In this case, you would configure SSL between the Mobile client and the firewall; as well as configure SSL between the firewall and the Mobile Server.

Figure 11-6 Mobile Client Communicating Over SSL Through Firewall Using Reverse Proxy

Description of Figure 11-6 follows
Description of "Figure 11-6 Mobile Client Communicating Over SSL Through Firewall Using Reverse Proxy"

In this case, you need to create a chained certificates with the following two certificates:

  • A certificate for the connection between the Mobile client and the reverse proxy firewall.

  • A certificate for the connection between the reverse proxy firewall and the Mobile Server.

Perform the following:

  1. Create a chained SSL certificate that contains both the certificates from the reverse proxy followed by the certificate for the Mobile Server.

  2. Install this certificate on the reverse proxy firewall for the Mobile client handshake.

  3. If you are using a Web-to-Go client, install the chained certificate in the Mobile Server, as described in Section 11.3.3, "Enabling SSL Authentication for Web-to-Go Clients".

In general, install the chained certificate on the firewall for the SSL handshake between the Mobile client and the firewall. However, for the Web-to-Go client, you must upload the same certificate on the Mobile Server as described in step 4 in Section 11.3.3, "Enabling SSL Authentication for Web-to-Go Clients".

11.5.1.4.4 Using Certificates That Are Not Signed By Trusted Authority

You can use certificates that are not signed by a trusted authority on the Mobile Server. A Web-to-Go client will use any certificate for encryption without any configuration modifications. However, for all other clients, if you are using a certificate that is not signed by a trusted authority, such as a self-signed certificate, then set the following parameter in the NETWORK section in the polite.ini (polite.txt) file on the client device:

DISABLE_SSL_CHECK=YES

This parameter enables the client to use the self-signed certificate for SSL encryption, but not to perform SSL authentication.

11.5.1.5 Configure Device Management to Work With a Firewall

We use device management to send commands to devices for updates, initiating synchronization, as well as other commands. Device management uses HTTP as its communication protocol. So, if a firewall is in between the device and the Mobile Server, you must perform some configuration to enable device management communication.

There are two types of device management requests:

  • Device initiated: The device management agent (dmagent), which is included on the Mobile device, registers with the Mobile server at device bootstrap. This is known as HTTP PULL, since the Mobile device polls the Mobile Server for any outstanding commands. The dmagent periodically polls the Mobile server for command requests on the Mobile Server listening port.

  • Mobile Server initiated: This is known as HTTP PUSH, since the Mobile Server sends the commands directly to the Mobile device. You can send commands to one or more devices through the Mobile Manager or Java APIs. However, this is unusual, since most communication/synchronization is initiated from the client. Thus, the proxy must be configured correctly to enable communication initiated from the Mobile Server.

The following describes how to configure your Mobile Server to enable device management requests to a Mobile Server that resides behind a firewall:

11.5.1.5.1 Configure Mobile Device Listening Port

In the Mobile Server initiated scenario, the Mobile device has a listener with which the Mobile Server connects. Thus, the Mobile Server communicates with the dmagent listening port. The dmagent on the Mobile device, by default, listens on port 8521, which is configured in the PUSH_PORT parameter.

For all future client installations, you may modify the PUSH_PORT for all the clients by using Mobile Manager in the Mobile Devices -> Administration -> Configuration Management page. This change affects only the client installations that are performed after the modification.

11.5.1.5.2 Firewall Configuration

Your firewall should be configured so that HTTP traffic is enabled in the following manner:

  • The dmagent on the Mobile device should be able to access the SERVER_PORT on the firewall.

  • The Mobile Server should be able to access the PUSH_PORT of all devices.

11.5.1.5.3 Proxy Configuration for the Mobile Server

If the Mobile Server is behind the firewall, it can only access Mobile devices through a proxy. To configure the proxy server information in the metadata of the HTTP provider, navigate to Mobile Devices -> Administration -> Network Management -> HTTP in the Mobile Manager.

The metadata is any user-defined string that is required by the Java class during initialization. The HTTP provider metadata is a sequence of name-value pairs, where the name and value are separated by and equals sign ('='). Each pair is separated by the ampersand ('&'). This setting is effective when you send commands from a standalone Java program using device management APIs.

The following example adds the PROXY name-value pair with the proxy URL into the metadata after the TIMEOUT name-value pair:

TIMEOUT=30&PROXY=http://proxy.foo.com:8080

11.5.2 Using HTTP Proxy to Communicate From Inside a Firewall

Use the HTTP proxy for clients inside a corporate network that want to connect to a resource on the Internet. As shown in Figure 11-7, the corporate network is protected by a firewall, which blocks direct access from inside the corporate network to the outside world. However, you can configure a proxy server on the firewall to allow designated traffic travel through the firewall.

As demonstrated by Figure 11-7, A mobile user may wish to use a public Internet connection to connect to the corporate network, using one of the many available wireless 802.11 hotspots.

Figure 11-7 Client Accessing Mobile Server on Internet

Description of Figure 11-7 follows
Description of "Figure 11-7 Client Accessing Mobile Server on Internet"

If the Mobile client is located in the corporate intranet and the Mobile Server is located somewhere in the public Internet—where both are separated by a firewall—then the firewall must be configured to let HTTP traffic travel through by means of a proxy server.

To enable communication from the Mobile client to a Mobile Server outside the corporate firewall, perform one of the following:

Note:

You may be able to set up the proxy for communication originated from the client in this scenario; however, we do not support server-initiated device management requests in this scenario.

11.5.2.1 Proxy Configuration for Web-to-Go Clients

For a Web-to-Go Mobile client, add the proxy server settings as follows in the client webtogo.ora file:

[WEBTOGO]
PROXY_SERVER=hostname_proxy_server
PROXY_PORT=port_proxy_server

11.5.2.2 Proxy Configuration for All Other Clients

For all Mobile clients other than the Web-to-Go Mobile clients, perform the following when you synchronize using the msync.exe tool:

  1. Check the Use Proxy checkbox.

  2. Enter the hostname and port number of the proxy server.

11.5.2.3 Proxy Configuration for the Device Management Agent

The Mobile device is behind the firewall and can access the outside world (Mobile Server) only by using a proxy. At the time of client installation, the setup program prompts the user for the proxy information.

If you configured the proxy after the client installation, then you can configure dmagent to use the proxy server by adding HTTP_PROXY parameter under the NETWORK section including both the IP/hostname and port number to the polite.ini file, as follows:

HTTP_PROXY=proxy.foo.com:8080

11.5.2.4 Reverse Proxy Configuration for HTTP PUSH from Mobile Server Not Supported

In this scenario, the Mobile Server could only initiate communication with a Mobile device behind a firewall through a reverse proxy. However, a reverse proxy would have to be configured for each Mobile device behind the firewall. This is too intensive, so we do not support Mobile Server initiated communication, which includes the HTTP PUSH Device Management communication.

11.6 Branch Office Pre-Installation Considerations

When you install the Branch Office Manager on the Windows machine, it creates the OracleDatabaseLite user account with the minimum set of privileges required to execute the Oracle Database Lite software. This prevents Oracle Database Lite Branch Office executing under the SYSTEM account, which has broad privileges within the system and can make the system vulnerable.

Both the 'Oracle Lite Multiuser Service' is created as well as the normal Web-to-Go service executes under the privileges of the OracleDatabaseLite user. The Oracle Lite Multiuser Server enables remote clients to connect to the Oracle Lite database.

Normally, when installed, the password for the OracleDatabaseLite user is randomly generated during the setup. You can either pre-configure this password before the Branch Office installation or modify it after the configuration. See Section 3.5.3, "Defining Password for OracleDatabaseLite User for Branch Office on Windows Machine" in the Oracle Database Lite Getting Started Guide.

11.7 Security Warning for Demo Applications

If you have the demo applications installed in a production environment, they can be used to access areas of Oracle Database Lite that you may want to be secure. The demo applications are provided for you to use when learning how to develop your own application. Thus, when you are finished developing your product, remove the demo applications from the repository. For directions, see Chapter 2 "Installation of Oracle Database Lite" in the Oracle Database Lite Getting Started Guide.