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.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.
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
As shown in Figure 11-1, the passwords for the Mobile client environment are as follows:
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.
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.
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.
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.
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.
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.
If you have a Branch Office configuration, then the following additional username/password combinations exist:
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.
The remote clients access the Oracle Lite database through Branch Office; thus, the username/password for the remote client is validated by Branch Office.
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.
Section 11.3.3, "Enabling SSL Authentication for Web-to-Go Clients"
Section 11.3.4, "Troubleshooting Error Messages for an SSL-Enabled Mobile Server"
Section 11.3.5, "Client-Side Configuration for Secure Socket Layer (SSL)"
Note:
These are server-level steps which are typically executed prior to deployment of an application that requires SSL communication.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:
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 ajava.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.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:
Using the certificate from Step 1, use keytool
to generate a certificate request, which requests a certificate authority to sign the certificate.
Submit the certificate request to a certificate authority.
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/
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:
Section 11.3.2.1, "Configuring SSL for Mobile Server With OracleAS"
Section 11.3.2.2, "Configuring SSL for Standalone Mobile Server"
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:
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.
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.
After all configuration is complete, restart the application server to initialize the changes.
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:
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.
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
.
Edit the secure-web-site.xml
file with the following elements:
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">
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"/>
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.
Save the changes to secure-web-site.xml
.
Edit the server.xml
file to point to the secure-web-site.xml
file.
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" />
Save the changes to the server.xml
file.
Stop and re-start OC4J to include the secure-web-site.xml
file modifications.
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
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:
Upload the SSL certificate, which you created to the Mobile Server, as follows:
Navigate to the Administration page for your Mobile Server in the Mobile Manager.
Click Server Certificate.
As shown in Figure 11-3, browse to the SSL certificate and click Upload.
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.
The following errors may occur when using SSL certificates on your Mobile Server:
secure-web-site.xml
and either default-web-site.xml
or http-web-site.xml
files.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:
Section 11.3.5.1, "Communication between the Mobile Client and the Mobile Server"
Section 11.3.5.2, "Connection between the Browser and the Mobile Client for OC4J or Web-to-Go"
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.
Section 11.3.5.1.1, "Mobile Client Download from a Mobile Server which is Running in SSL Mode"
Section 11.3.5.1.2, "Mobile Client Download from a Mobile Server which is not 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
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 typehttps
, to specify and indicate the SSL Mode, and not http
.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.
The Mobile Server is running in SSL mode, as a module of Oracle9iAS.
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
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.Whether you are using a Mobile client or an embedded application, you can encrypt the database used on the client.
When encrypting the Oracle Lite database used with the Mobile client, modify the POLITE.INI
file to set the ENCRYPT_DB
parameter. See Section F.3.2.12, "ENCRYPT_DB" for more information.
When encrypting the Oracle Lite database that is used with an embedded application—which does not use synchronization—use the encryptdb
executable, as described in Appendix A.4 "ENCRYPDB" in the Oracle Database Lite Developer's Guide.
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:
Section 11.5.1, "Using Reverse Proxy to Communicate from Internet to Intranet"
Section 11.5.2, "Using HTTP Proxy to Communicate From Inside a Firewall"
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
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:
Section 11.5.1.1, "Configure the Apache Web Server as a Reverse Proxy"
Section 11.5.1.2, "Set Up Mobile Server for Mobile Client Download"
Section 11.5.1.5, "Configure Device Management to Work With a Firewall"
You need to set up the Apache Web Server software for the reverse proxy, as follows:
First, use Apache 2.0 or later for your proxy.
Configure the proxy server to point to the Mobile Server. See the Apache Web Server documentation for instructions on how to do so.
Set the following parameter in the httpd.conf
configuration file:
BrowserMatch MSIE AuthDigestEnableQueryStringHack=On
When you use reverse proxy authentication, you must upper-case the username of the proxy digest.
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.
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:
If your server is a Windows XP machine, you must have the Service Pack 2 installed.
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
After you have updated the Mobile Server with the proper reverse proxy configuration, perform the following on the client:
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 twoSERVER_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.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.
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:
Section 11.5.1.4.2, "Using SSL Between Mobile Client and Reverse Proxy"
Section 11.5.1.4.3, "Using SSL Between Firewall and Mobile Server"
Section 11.5.1.4.4, "Using Certificates That Are Not Signed By Trusted Authority"
When you are using a reverse proxy firewall, SSL client authentication is not supported. You can only turn on server-side HTTPS authentication.
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
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".
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
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:
Create a chained SSL certificate that contains both the certificates from the reverse proxy followed by the certificate for the Mobile Server.
Install this certificate on the reverse proxy firewall for the Mobile client handshake.
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".
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.
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:
Section 11.5.1.5.1, "Configure Mobile Device Listening Port"
Section 11.5.1.5.3, "Proxy Configuration for the Mobile Server"
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.
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.
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
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
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.Section 11.5.2.1, "Proxy Configuration for Web-to-Go Clients"
Section 11.5.2.2, "Proxy Configuration for All Other Clients"
Section 11.5.2.3, "Proxy Configuration for the Device Management Agent"
Section 11.5.2.4, "Reverse Proxy Configuration for HTTP PUSH from Mobile Server Not Supported"
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
For all Mobile clients other than the Web-to-Go Mobile clients, perform the following when you synchronize using the msync.exe
tool:
Check the Use Proxy checkbox.
Enter the hostname and port number of the proxy server.
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
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.
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.
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.