| Oracle® Database Lite Administration and Deployment Guide Release 10.3 Part Number E12089-02 |
|
|
View PDF |
| Oracle® Database Lite Administration and Deployment Guide Release 10.3 Part Number E12089-02 |
|
|
View PDF |
The following sections detail how to manage security in Oracle Database Lite:
Section 11.4, "Configuring for Secure Socket Layer (SSL) Communication"
Section 11.5, "Providing Your Own Authentication Mechanism for Oracle Database Lite"
Section 11.7, "Providing SSL Client Authentication with a Common Access Card"
Note:
There is additional information about developing for security in Chapter 8, "Customizing Oracle Database Lite Security" 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.
Note:
For details on how to modify the repository password, see Section 11.2.1, "Modifying Repository Password".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 the Mobile Server repository and for Oracle Lite Mobile clients, in 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:
Note:
See Section 4.3.1.2.1, "Define Username and Password" for conventions for creating the username or password.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.
On Oracle Lite Mobile clients, 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, on Oracle Lite Mobile clients, each ODB file is not encrypted. If you want to encrypt the database, see Section 5.10, "Encrypting the Oracle Lite Database".
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.
As described in number 1 in Section 11.2, "Which Password is Which?", the repository has its own username/password combination. By default, the Mobile Server schema is MOBILEADMIN. However, if, during installation, you chose another name, replace mobileadmin by your own schema name in the steps described in this section.
If you want to modify the password for your repository schema, perform the following:
Connect to your Oracle database where the Mobile Server repository was installed.
Change the password on the database with the ALTER command. The following command modifies the repository password to TEST:
alter user mobileadmin identified by TEST;
Backup the webtogo.ora file on the Mobile Server:
cp $OL/mobile/server/bin/webtogo.ora $OL/mobile/server/bin/webtogo.ora_backup
Set the admin_user and admin_password parameters in the webtogo.ora file to NULL since the password changed, as follows:
ADMIN_USER= ADMIN_PASSWORD=
We need to set these two parameters to a NULL value as the password change.
Restart the Mobile Server
Go to the following URL: http://mobileserver_hostname:Port/webtogo/startup
Log into thte Mobile Server using the new repository password. For our example, this password is TEST.
Click SAVE to save the Oracle Mobile Server Repository Username and Password.
Note:
This enables the auto start feature of the Mobile Server.Check that the admin_user and admin_password parameters in the webtogo.ora file have new values, as follows:
ADMIN_USER=ySTIx5WLKLRb+cuRojIuWg== ADMIN_PASSWORD=tLuQlClPTlJ2powDoW7S9w==
The introduction of handheld devices within the corporate environment can pose a security threat to an organization. Devices are now used to store not only company contacts; but, with external cards, may store up to 60 gigabytes of information or more. Devices also provide a mobile point of entry into the organizational network that is located outside the network security perimeter. It is essential to secure this data if a device is lost or compromised.
Securing a device involves a layered approach. You must secure not only access to the device, but data stored on the device and communications across the network. Most aspects of security for a mobile device must be incorporated before Oracle Database Lite is even involved within the security infrastructure.
Security needs to start with the device itself. Authentication on the device must be implemented through pin or password authentication, biometric readers, secure digital media for storage, and even how the device is stored, transported, and accounted for.
Once access is gained to the device, further security needs to be implemented within the mobile application to prevent the application from being able to retrieve invalid data. Technologies, such as the Microsoft.Net Compact Framework, incorporate API calls that may be used to encrypt and decrypt any data that will be stored or retrieved from the device.
Oracle Database Lite provides several security features that may be utilized to help in securing data. These features aid in protecting information during both synchronization, and once access to a device has been obtained. The two most important aspects of security provided by Oracle Database Lite for the mobile infrastructure are the following:
Use Secure Socket Layer (SSL) to protect the transmission of data during the synchronization process. For full details, see Section 11.4, "Configuring for Secure Socket Layer (SSL) Communication".
Use one of the Oracle Database Lite encryption options to protect the actual database files. See Section 5.10, "Encrypting the Oracle Lite Database" for full details.
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.4.3, "Using Packaging Wizard For SSL-Enabled Mobile Server"
Section 11.4.4, "Enabling SSL Authentication for Web-to-Go Clients"
Section 11.4.5, "Troubleshooting Error Messages for an SSL-Enabled Mobile Server"
Section 11.4.6, "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 either set the SSL disable parameter yourself or add the certificate in the trusted certificate list. These options are listed below:
To disable the SSL check, set the SSL disable parameter: Set the DISABLE_SSL_CHECK parameter to true in the polite.ini file to 1 after the [NETWORK] section, as follows:
[NETWORK] DISABLE_SSL_CHECK=true
To allow this certificate to be validated, add or install the new certificate in the trusted certificate list. After completion, the certificate will be trusted.
Open your browser and point it at the following site:
https://<server>/webtogo/setup
Security alert displays.
Click View Certificate.
Click Install Certificate.
Click Next-> Next-> Finish.
When you next perform the synchronization, the synchronization is successful. This adds the Oracle Database Lite in the trusted root certification authority.
Note:
If this is for testing only, then remove this certificate after testing is completed.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.4.2.1, "Configuring SSL for Mobile Server With OracleAS"
Section 11.4.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.
Note:
If you have both SSL and non-SSL clients wanting to access the Mobile Server, you must configure it to be both SSL and non-SSL enabled. Refer to the OracleAS documentation for directions on how to enable both SSL and non-SSL communication.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
Note:
If you want to access the Mobile Server from both SSL and non-SSL enabled clients, leave both configuration lines in the file.If you enable the Mobile Server to be SSL-Enabled, then you have to change the configuration on the host where the Packaging Wizard is located in order for it to successfully communicate with the Mobile Server.
In order for Packaging Wizard to be SSL-Enabled, set the SSL parameter to TRUE in the webtogo.ora file located on the host where the MDK is installed, as follows:
[WEBTOGO] SSL=TRUE
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.4.6.1, "Communication between the Mobile Client and the Mobile Server"
Section 11.4.6.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.4.6.1.1, "Mobile Client Download from a Mobile Server which is Running in SSL Mode"
Section 11.4.6.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
You may have a non-SSL Mobile client that you want to interact with your SSL enabled Mobile Server. For the case when you have both SSL and non-SSL Mobile clients interacting with a Mobile Server, the Mobile Server must be configured in both SSL and non-SSL mode. See Section 11.4.2, "Configuring Mobile Server for SSL" for details.
You can provide an external authenticator for the Mobile Server to authenticate users with passwords as well as their access privileges to applications. For example, in an enterprise environment, you may have your user data, such as employee information, stored in a LDAP-based directory service. The Mobile Server can retrieve the user information from the LDAP directory—or from any custom User Management System—if configured with your own implementation of an external authenticator. The Mobile Server links the external user information to the Mobile Server repository.
For full details, see Section 8.1, "Providing Your Own Authentication Mechanism for Authenticating Users for the Mobile Server" 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.6.1, "Using a Reverse Proxy to Communicate from Internet to Intranet"
Section 11.6.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.6.1.1, "Configure the Apache Web Server as a Reverse Proxy"
Section 11.6.1.2, "Set Up Mobile Server for Mobile Client Download"
Section 11.6.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.6.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.6.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.6.1.4.2, "Using SSL Between Mobile Client and Reverse Proxy"
Section 11.6.1.4.3, "Using SSL Between Firewall and Mobile Server"
Section 11.6.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.4.4, "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.6.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.4.4, "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.4.4, "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 Manager 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.6.1.5.1, "Configure Mobile Device Listening Port"
Section 11.6.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.6.2.1, "Proxy Configuration for Web-to-Go Clients"
Section 11.6.2.2, "Proxy Configuration for All Other Clients"
Section 11.6.2.3, "Proxy Configuration for the Device Manager Agent"
Section 11.6.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.
Oracle Database Lite supports client authentication over SSL-based connections between an Oracle Lite Mobile client and the Mobile Server. The client authentication is based on X.509 certificates that can be stored in a Common Access Card (CAC).
Note:
Smart cards or common access cards are not supported to authenticate a SQLite Mobile client.The following sections describe how to enable client authentication in Oracle Database Lite for Common Access Cards:
Section 11.7.3, "Oracle Database Lite Supports Common Access Cards"
Section 11.7.4, "Supported Platforms for the Common Access Card"
Section 11.7.6, "Configuration for Client Authentication Using the Common Access Card"
Secure Sockets Layer (SSL) is a security protocol that enables secure and authenticated data transfer over a network between a server and a client. During the connection setup, the server is always authenticated using a public key certificate. The client connects to the server only after establishing its identity based on the certificate.
The server may also choose to authenticate the client by asking for a client certificate. With client authentication enabled, the server requests a certificate from the client to verify that the client is who it claims to be. The certificate that the client sends must be an X.509 certificate and signed by a Certifying Authority (CA) that is trusted by the server. The server allows the connection if the client's certificate can be trusted.
SSL Client authentication requires that all users have their own X.509 certificate. There are several methods for users to store and manage certificates. One method is to store the certificates on a Common Access Card.
A Smartcard is a pocket-sized card with embedded integrated circuits that store and process data. A Common Access Card (CAC) is a Smartcard with additional software that enables you to securely store and manage security certificates and keys on the card, which are used for authentication. The data on the CAC is secured by a password or pin number. When the user connects to a server or system that requires authentication, the user is prompted for the password. The certificates and keys residing on the card are used to authenticate the user.
The CAC is used to authenticate users for access to computers and facilities. The CAC also enables encrypting and cryptographically signing email, uses PKI authentication tools, and establishes identity credentials. The certificates are stored in X.509 format on the CAC, and can be accessed by software running on a host machine through a card reader.
For example, the following describes what happens if a user browses a Web site that requires the client side certificate:
Open a browser and navigate to the Web site. The browser prompts for the pin number of the CAC.
After the user provides the correct pin, a CAC session is created. This enables all applications running on the machine to access the card and read the necessary certificates and keys. In case there is more than one certificate on the card that the server will accept, then the user is prompted to select which certificate to use.
By default, the CAC session expires after a configurable amount of time, after which the user must provide the pin number again.
For Oracle Database Lite, the CAC is used to authenticate the client to the Mobile Server when requested before synchronization or any other type of communication between the client and the Mobile Server.
Oracle Database Lite supports client authentication over SSL connections using client side certificates and keys residing on the CAC. Oracle Database Lite supports the ActivIdentity card. When the user supplies the CAC, the user also enters a pin number to retrieve the certificate and corresponding private key from the CAC. If the pin number is correct, data on the card can be accessed for a configurable period of time, known as the idle timeout that is set in the CAC software.
Note:
To set the idle timeout for the authenticated sessions, use the User Console in the ActivIdentity software. The idle timeout defaults to 15 minutes.When the pin number is verified, then access to the certificates and keys on the card is provided either to only the process that prompted the user to enter the pin number or to all of the user's processes running on the machine. For all components of the Mobile client to work properly, the authentication must be shared among processes. See Section 11.7.6.2.1, "Sharing Authentication Acceptance Across Processes" for details.
The client authentication feature enabled for Oracle Database Lite uses the CAC, which is supported only on the Windows platform. The following Mobile clients can use a CAC for client authentication:
Mobile Client for Win32
Mobile Client for WEB for Win32
Mobile Client for WEB OC4J for Win32
Note:
At this point, client authentication is not supported on Windows CE, Windows Mobile or any UNIX platforms.If the Mobile Server is running in SSL client authentication mode, then only Internet Explorer 6.0 or higher is supported for connecting to the server.
The components that must use the CAC when client authentication is requested are those that communicate with the Mobile Server. These are as follows:
Mobile Client for WEB
Mobile Client for OC4J
Mobile Client for Win32 (msync) and Mobile Client for Win32 API
Oracle Database Lite Device Manager Agent
Automatic Sync agent
Packaging Wizard on Windows platform
The following components and scenarios are not supported:
MDW: Since MDW does not support SSL/HTTPS, it cannot provide client authentication over SSL.
Branch Office: Branch Office executes as an unprivileged service; thus, cannot support client authentication. Branch Office cannot access certificates residing on the common access card.
Branch Office runs as a service under a different operating system user account than the logged in user. This user account does not have access to the console and, as a result, the CAC software cannot prompt the user to enter the PIN required to access the CAC card.
A Mobile Server that is configured for client authentication will only interact with Mobile clients that are enabled for client authentication. Enabling Client authentication on the Mobile Server is optional. Thus, if you do not turn it on, both clients with and without CAC can communicate with the Mobile Server without having to present a certificate.
Using client authentication on the Mobile Server requires the following patches:
If you are using Oracle Database Lite installed on OracleAS, then apply the OC4J Patch 5218685 to OracleAS.
If you are using Mobile Server Standalone, then the patch is already included in the downloaded binary.
You must install the software provided by the Common Access Card vendor to access the data on the card on each Mobile client. This is required in order to access keys and certificates on the CAC. Refer to the vendor documentation on how to install this software.
The following sections describe how to configure for client authentication:
Section 11.7.6.1, "Configuration of the Mobile Server to Request Client Authentication"
Section 11.7.6.2, "Configuration of the Mobile Client to Use a CAC"
Section 11.7.6.3, "Configuration for Reverse Proxy and Load Balancer"
To configure the Mobile Server to request client authentication, perform the following:
Configure for SSL on the Mobile Server as described in Section 11.4, "Configuring for Secure Socket Layer (SSL) Communication".
Enable client authentication in the Mobile Server. There are separate instructions for Standalone Mobile Server and Mobile Server using OracleAS. These are described separately, as follows:
Standalone Mobile Server: To enable client authentication for Standalone Mobile Server, perform the following:
For Standalone Mobile Server, add the needs-client-auth parameter in the ssl-config element in the secure-web-site.xml file in the ORACLE_HOME\mobile_oc4j\j2ee\mobileserver\config directory to enable client authentication over SSL.
Add the needs-client-auth attribute/value pair as follows:
needs-client-auth=”true”
The following is an example of setting the needs-client-auth attribute in the ssl-config XML element:
<ssl-config keystore="../../../../mobile/server/bin/samplekeystore" keystore-password="oracle" needs-client-auth="true"/>
Mobile Server on OracleAS: To enable Client Authentication for Mobile Server on OracleAS 10.1.2 or 10.1.3, perform the following:
Stop Oracle AS, as follows:
cd ORACLE_HOME/opmn/bin ./opmnctl stopall
Configure OracleAS to execute in SSL Mode using the SSLConfigTool utility. Refer to the OracleAS documentation for more information.
Enable Client Authentication by modifying the ORACLE_HOME/Apache/Apache/conf/ssl.conf file to add the following line:
SSLVerifyClient require
Install the certificate on the Mobile Server. Add the certificate of the CA who signed the user certificates in the CAC to the server wallet. The wallet location is the value of “SSLWallet” attribute in the ORACLE_HOME/Apache/Apache/conf/ssl.conf file. Use the Oracle Wallet Manager to create a new wallet or modify an existing wallet.
Install the certificate on the Mobile Server.
For the SSL connection to be established, the Mobile Server must have the certificate of the signing authority (CA), which signed the certificates present in the CACs. Import the CA certificate in the same keystore that you have used for storing the server certificate, as described in Section 11.4, "Configuring for Secure Socket Layer (SSL) Communication".
The following is an example of how to import the certificate using the keytool executable:
keytool.exe –keystore <samplekeystore> -storepass <oracle> -import –alias clientCACert –file <CACert.crt>
Modify the pkcs11.cfg file on the Mobile Server before you install the client with the correct path to the CAC library on the client. The PKCS11 configuration file defaults with the following entry:
library = C:\WINDOWS\system32\acpkcs11.dll
Note:
Verify that this entry refers to the correct PKCS11 library provided by the CAC vendor on the client.Depending on your installation mode, the pkcs11.cfg file is located in one of the following directories:
When using Standalone:
<ORACLE_HOME>/mobile_oc4j/j2ee/mobileserver/
applications/mobileserver/setup/common/webtogo
When using OracleAS:
<ORACLE_HOME>/j2ee/mobileserver/
applications/mobileserver/setup/common/webtogo
With other common files:
<ORACLE_HOME>/mobile/server/admin/
repository/setup/common/webtogo
If using OracleAS, then start OracleAS, as follows:
cd ORACLE_HOME/opmn/bin ./opmnctl startall
Restart the Mobile Server to reinitialize with the new modifications.
If you have configured Mobile Server to request client authentication, as described in Section 11.7.6.1, "Configuration of the Mobile Server to Request Client Authentication", then any setup.exe downloaded for a new Mobile client automatically installs a Mobile client enabled for handling certificates and keys from a CAC.
However, if the PKCS11 library location is different on the client than what is specified in the pkcs11.cfg file on the Mobile Server, as described in Section 11.7.6.1, "Configuration of the Mobile Server to Request Client Authentication", then modify the PKCS11 configuration file on the client to point to the correct directory.
The configuration file location is specified with the PKCS11_CONFIG_FILE parameter in the %INSTALL_DIR%\bin\webtogo.ora file. The default configuration file is %INSTALL_DIR%\bin\pkcs11.cfg. Change the library property in the configuration file to refer to the correct library, as follows:
library = <Full path to PKCS11 library>
Client authentication sessions can be shared across processes belonging to the same user. Thus, if one process prompts the user for the pin number to read data from the CAC, a second process can also access the CAC without providing the pin number again--as long as the sesson is not expired.
You can control whether authentication is provided for all processes for the user or not through the Pin Caching Service.
On the ActivIdentity card, perform the following:
Select the Pin Caching Service through the following pull-down: Tools -> Advanced -> Configuration -> PIN Caching Service.
Select NO in the "Allow per process PIN caching" field.
Configuration for the reverse proxy and load balancer are described in Section 11.6, "Using a Firewall Proxy or Reverse Proxy". However, you must configure the reverse proxy and load balancer to require and accept the client certificates and to be able to validate the client's certificates. In addition, the reverse proxy and load balancer must create an SSL connection to the Mobile Server using the client authentication.
The Mobile Server must be configured to accept the client authentication from the reverse proxy or load balancer.
If no CAC session is established yet, then--in most cases--the user is prompted for the CAC pin number to create a CAC session. The cases where the user may not be prompted are for the background processes: the Device Manager agent (dmagent) and the Automatic Synchronization agent (Sync Agent).
The Oracle Database Lite dmagent acts both as an HTTP client when communicating with the Mobile Server and as an HTTP server when receiving DM commands over HTTP. The dmagent supports SSL over HTTP when acting as a client and supports client authenticated SSL connections.
If the background processes—the dmagent and the Sync Agent—start when the CAC session is already available, then the connection succeeds. However, once the CAC session expires, then the following may occur:
If the CAC card is in the card reader, then the background processes prompt for the user pin.
If the CAC card is not in the card reader, then the processes fail silently and a log error is written into cac_log.txt file.
Note:
The SSL certificate or keys should not be stored in the database or any other persistence location on the Mobile client.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 3,"Installation of Oracle Database Lite" in the Oracle Database Lite Getting Started Guide.
|
 Copyright © 1997, 2010, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|