Oracle Application Server Wireless Administrator's Guide 10g (9.0.4) Part Number B10188-01 |
|
Oracle Application Server Wireless (Wireless) combines advanced content transformation, device adaptation and network adaptation services with end-user customization, providing provides enterprises, mobile operators, content providers, or wireless ISPs with a platform to create and deploy mobile applications. Wireless incorporates various security mechanisms that enable the deployment of end-to-end secure, unbreakable applications.
To provide a clear understanding of security and its application in the wireless world, this section provides brief descriptions of the principles of security and describes common application deployment models for both the wired and wireless world, explaining their similarities and differences in regards to security. Subsequent sections describe these security principles in more detail, provide available deployment scenarios, and identify any issues that are wireless-specific and present Wireless'solution.
The principles of security are:
This section describes the differences and similarities of security in both wired deployment and wireless deployment.
Figure 10-1 depicts the basic arrangement of deployment in the wired world: a wired device, such as a PC, connects over the network to an application server.
The main security characteristics of the wired deployment scenario are:
Figure 10-2 depicts the deployment scenario for wireless devices. The wireless device, a device limited in both power and bandwidth, stands at one end of the transaction. The wireless device communicates over the air through a wireless network to a gateway component which performs the translation from the wireless network protocol to the wired network protocol so that the device can contact the application server.
The wired side of the wireless network is practically the same as the wired deployment scenario explained in Section 10.1.1.1. However, because of the added components in the transaction flow, the following security considerations arise:
There are two classes of Wireless users: registered users and anonymous users. The registered users are users whose user information is registered with the Oracle Internet Directory (OID). These users can be created, modified, or deleted through the User Manger or the OID DAS tool. Anonymous users are these users that have not been registered with OID. Anonymous users can only access the wireless and voice applications assigned to the Guest group. A registered user can only access the wireless and voice applications assigned to the groups to which that user belongs. For more information on anonymous users and assigning users to groups, see Chapter 4, "Managing Users". For information on assigning applications to user groups, see Section 5.4.
The Wireless Tools, such as the User Manager, are role-specific; Wireless users can only access the tool which corresponds to the role or roles that they have been granted. The User Manager assigns these roles when creating (or updating) a user. A user can have one or several roles, which include System Administrator Application Developer, Foundation Developer, Content Manager, User Administrator, and End User. These roles span all of the Wireless resources, from server management, application development, application publishing, and help desk to subscription to the Wireless applications. For more information on Wireless user roles, see Section 10.2.
The Oracle Application Server Wireless meta data repository does not store any sensitive information. Instead, information such as the user passwords, voice-accessed PINs, and the password to the Oracle Application Server Wireless meta data schema are stored in Oracle OID.
Sensitive resources (such as the Wireless Tools) are protected through access controls and various authentication mechanisms, such as user names and passwords. Service access is also protected the user names and passwords.
Access to the Wireless tools is controlled through user roles, which not only provide access to the tools, but define the capabilities of the Wireless user as well. Table 10-1 describes the user roles, their capabilities and the resources that these roles enable.
In Wireless, a user group is the means by which users can access any voice and wireless application; any application that has been published to a user group is available to all of that group's members. The Content Manager can both create a user group and assign applications to a user group, which is a collection of users. The user manager assigns users to user groups. See Section 5.4 for information on publishing an application to a user group and Section 5.4 for assigning a user to a user group.
Access Control to applications in Oracle Application Server Wireless is provided according to the channel used to connect to the server. For visual HTTP-based channels such as WAP, Oracle Application Server Wireless authenticates users through user names and passwords; for voice-accessed applications, Wireless uses account numbers and PINs; for message-related applications, Wireless checks the user account information (for example, Wireless checks the email headers). For web services related to the messaging infrastructure, Wireless authenticates users through user names and passwords.
Besides user name and passwords, Wireless allows for other authentication mechanisms, depending on the device. However, the application developer is responsible for choosing and integrating the appropriate mechanism for the target device. The authentication mechanisms available in the various channels and how they can be used are as follows:
signtext()
function. Upon receiving a signature request, the WAP device prompts the user to enter his or her local PIN (which authenticates the user only to the WAP device) and then retrieves the user's WPKI private key (stored in a SIM chip in the WAP phone) to sign the challenge. Once the authentication service receives the signed challenge, it is verified with the user's WPKI public key (possibly stored in a user's certificate repository such as the Oracle Wallet Manager) and notifies the requesting application of the result. WMLScript's signtext()
function is available with WAP 2.0.
The Wireless tools and the Customization Portal are protected by the Oracle HTTP Server SSO plugin module (mod_osso). The mod_sso protects all the URL access to the Wireless tools. If any part of the URL access is not authenticated, then the mod_sso redirects the request to SSO for authentication.
To further secure the communication channel between the browser and the Wireless tools, or the wireless gateway (for example, the WAP gateway, or the voice gateway), you can enable SSL on the Oracle HTTP Server. For more information, refer to the documentation for the Oracle HTTP Server on configuring SSL.
In addition, you can also enable the SSL-based secured communication channel between the Wireless Multi-Channel Server and remote application server by installing either Base64 certificate or PKCS#7 formatted certificate at the Wireless Multi-Channel Server. You can install such certificate through the System Manager (accessed through Oracle Enterprise Manager). For information on using the System Manager to configure an SSL certificate, see Section 3.6.1.
Single Sign-On is a feature (one not specific to Wireless) that eliminates the need for repeated authentication (within a period of time) when crossing application boundaries for the same trusted domain. It also provides for centralized user credentials, which avoids the problem of having to remember passwords for different applications, thereby increasing security for the whole system, as passwords do not need to be written down.
Wireless is fully integrated with Oracle Application Server Single Sign-On, which currently supports authentication through user names and passwords over all visual HTTP-based channels and through account number and PIN for voice-based channels.
Oracle Application Server Single Sign-On also integrates with the Oracle Internet Directory (OID), an LDAP server that stores, among other things, valid end-user authentication information such as passwords and digital certificates.
The user information stored in OID is replicated to the Wireless meta data schema when a user logs in, or through asynchronous synchronization from OID to the Wireless schema. Table 10-2 lists the user attributes (stored in OID) that are replicated in Wireless schema.
Applications developed and deployed in Wireless can benefit from Oracle SSO functionality through integration as an Oracle SSO partner. For more information on SSO, refer to the Oracle Application Server Wireless Developer's Guide.
Wireless depends on the security infrastructure to be up both during installation time and runtime. Refer to the Oracle Application Server Administrator's guide for details on the security infrastructure.
Wireless relies on Directory Integration Platform (DIP) server, as one of the mechanisms, to asynchronously replicate the essential modified user information from OID to the Wireless schema. For more information, refer to Oracle Internet Directory Administrator's Guide for details on how to start the DIP server.
By default, the OID server does not enforce unique constraints on account number (that is, the orclWirelessAccountNumber
attribute of orclUserV2
object class). The account number is required for users accessing wireless applications from a regular voice line with the account number and PIN used for the authentication. As part of the Wireless installation, the Wireless configuration assistant enables the policy to enforce a unique constraint on the orclWirelessAccountNumber
attribute of orcluserV2
object class. The OID server must be restarted after the first Wireless installation for this unique constraint policy to take effect. Refer to Oracle Internet Directory Administrator's guide for details on how to restart the OID server.
Wireless connects to the OID as a Wireless application entity after users have been authenticated through SSO. The Wireless application entity is assigned following privileges:
By default, the Wireless application entity does not have the privileges to change the user password. Consequently, out-of-the-box users cannot change their password from theWireless server. However you can enable the functionality to change passwords by assigning the UserSecurityAdmins
privilege to the Wireless application entity. To do this, execute assignUserSecurityAdminsPrivilege.sh (or assignUserSecurityAdminsPrivilege.bat, depending on your operating system) on the machine on which Wireless is installed. The script is available in the ORACLE_HOME/wireless/bin directory.
The syntax for invoking the utility is as follows:
assignUserSecurityAdminsPrivilege.sh oid_super_user_dn user_password
where
oid_super_user_dn
is the Distinguished Name (DN) of the OID super user. The user should have privileges to grant UserSecurityAdmins
privilege to application entities
user_passord
is the password of the OID super user
For example:
assignUserSecurityAdminsPrivilege.sh cn=orcladmin welcome1
This section describes Communication Data Privacy and Non-Repudiation principles of wireless security. In discussing these principles, this section provides alternatives available to application developers when incorporating security in Wireless. In some cases, Wireless does not provide direct support for security on a given channel, leaving the responsibility to the application developer to recognize the security needed for the application and to deploy the appropriate security mechanisms.
Communication Data Privacy is the principle of security that prevents data in transit (on the network) from being partially or completely observed by unintended parties or eavesdroppers. Along with authentication, communication data privacy is one of the most important aspects of wireless application security.
This section focuses on end-to-end data privacy, where no intermediate nodes (or actors) are able to understand the data that passes through them. For example, the wireless carrier's WAP gateway should not be able to understand the sensitive information, even when all the data passes through it. End-to-end data privacy stands in contrast to point-to-point (or leg-based) data privacy, where data is secured between servers and devices but intermediate nodes can see the data in "the clear".
Given the variety of (wireless) networks and protocols, communication data privacy differs among the various communication channels. The following sections describe communication data privacy deployment solutions based on the communication channels:
Internet Protocol (Web) communication is currently used today in the wired world with standardized security through SSL encryption. PCs connect to the application server directly with point-to-point privacy using HTTPS, which is HTTP running over an SSL-secured link (Figure 10-3). Since there are no intermediate nodes performing protocol translations at the security layer (as there are WAP 1.x), data communication is end-to-end private between the browser and the application server.
Because Wireless supports HTTPS connections, PC browser connections are point-to-point secure.
The wireless extension to the PC browser is through the use of HTTP devices that connect to a wireless LAN gateway, as it is in the case of Pocket PCs with wireless LAN card adapter. The connection from the device to the wireless LAN gateway follows the 802.11b standard for wireless communication, which is interoperable with the wired Internet protocol since it uses the Ethernet protocol. Since both protocols (wired and wireless) are interoperable at the security layer, point-to-point secure communication is also carried out through HTTPS from the device to the Application Server (as depicted in Figure 10-4).
Without HTTPS security at the application layer, wireless LANs are insecure even with the use of the Wired Equivalent Privacy (WEP) protocol, a protocol operating at the data link layer designed to protect communication but which has been shown to be insecure. Therefore, wireless networks that depend solely on WEP for privacy are found to be vulnerable to "war-driving", an attack where the eavesdropper 'drives by' with a wireless receiver to break WEP security and decode wireless information.
Security in the Wireless Application Protocol (WAP) is currently specified in the WTLS (Wireless Transport Layer Security) protocol. Similar in design to SSL (TLS), but optimized for bandwidth and power, WTLS provides privacy from the wireless device to the WAP gateway, allowing for server authentication and mutual authentication modes.
WAP has been widely criticized by the security sector on what is commonly called the 'WAP gap', which breaks end-to-end communication data privacy. The WAP device communicates with the WAP gateway through WTLS (the WAP pictured in Figure 10-5) and the WAP gateway, in turn, communicates with the application server using SSL (Internet zone.) Since WTLS is not compatible with SSL because of handshake optimizations, a protocol translation needs to occur at the WAP gateway (the Grey Zone pictured in Figure 10-5): that is, WTLS-encrypted data must be decrypted and be SSL-encrypted. The 'WAP gap' refers to this split second when the data is in the clear at the WAP gateway; this alone breaks end-to-end privacy and is a cause of concern for the banking industry and the most security-conscious.
For WAP 1.x deployments, bridging the WAP gap can be accomplished by redirection to subordinate pull proxy (gateway) with WAP 1.2. If, in addition to the WAP gateway at the carrier side, there is another WAP gateway residing within the same physically secured, trusted domain as the application server (that is, both are owned by the same company), then communication can be redirected to this enterprise gateway and can thus be considered end-to-end private. In this way, the WTLS connection would be established with a gateway located at the site of the application service provider and it would also allow for WTLS class 3 (client and server authentication).
Some gateways, such as the OpenWave's Mobile Gateway server, already support the deployment of proxy gateways at the premises of the content provider. In this model, after the subordinate proxy discovery process, requests will be rerouted to the proxy gateway installed within the secure premises of the provider hosting the Wireless application server. The network operator retains the control of the calls at the cost of sharing the burden of supporting the infrastructure required for end-to-end secure communications.
The disadvantage of this solution is that the company hosting the application server must deploy and maintain its own WAP gateway. User Agent devices, such as Nokia Mobile Browser 3.0, already support this deployment model.
In the next generation of WAP (WAP 2.0), WAP designers will eliminate WAP gap by introducing Internet Protocols. That is, WAP devices which can securely communicate using SSL. In addition, no translation will be necessary at the WAP gateway, thus providing end-to-end privacy. This is a step to ensure that WAP devices are interoperable with the wired Internet.
The Short Message Service (SMS) deployment architecture dictates that messages be routed through a Short Message Service Center (SMSC) from the application server to the wireless device (as depicted in Figure 10-6).
Under SMS, required security for a given deployment scenario depends largely on the business model (for example, carriers versus corporations) of the enterprise deploying the solution. Given these different business models, secure deployment alternatives are as follows:
A more scalable and generic alternative is the use of application layer PKI encryption, which eliminates the need of a pre-existing relationship between end-consumer and the business. Unfortunately, there are currently no SIM card vendors that offer PKI encryption capabilities (only signature capabilities) as there is no standardized way for key generation and certificate provisioning for SMS.
Just as in SMS, end-to-end private email communication depends on the deployment scenario.
Depending on such factors as the capabilities of the email device and the location of the end-user email server in respect to the application server, several alternative solutions exist:
End-to-end data privacy over email can also be enabled with PKI, which would allow for secure email communication between parties that do not have a pre-existing relationship. Email privacy is carried out in the wired world with the use of S\MIME and PGP, a hybrid of symmetric and PKI-based encryption algorithms. Although S\MIME is supported in PC email browsers such as Outlook or Netscape, it is not supported by current Palm email applications and RIM Blackberries.
Voice communication over regular (wired or wireless) phone lines is not end-to-end secure in general. In fact, governments such as that of the United States have taken steps (through laws such as the Digital Telephony Bill or the Digital Wiretap Law) to facilitate the wiretap of phone communication systems.
Despite these non-technical issues, voice line security can be implemented in the data network, thus discouraging eavesdroppers on a digital network. The following secure solutions are available in the voice channel:
Finally, there are phone devices and third-party mechanisms that claim to provide voice encryption technology that protects communication between two ends of the phone conversation. However, the security of these technologies is not well established and some mechanisms have been breached. In addition, these mechanisms are expensive and not scalable, as they require hardware deployment at the client side.
Non-Repudiation refers to the mechanism where accepted transactions cannot be disclaimed and can be openly verified as valid. For example, in the mobile commerce world, payments cannot be denied. Non-repudiation would allow for such transactions to be openly verifiable and undeniable by the parties involved.
Non-repudiation mechanisms are based on digital signatures, which are analogous to regular ink signatures. Among the many digital signature schemes are DSA (Digital Signature Algorithm), Schnorr's signature and RSA signature - DSA being the most widely used, since the U.S. government has used it as the Digital Signature Standard (FIPS 186). In the wireless world, digital signature mechanisms vary from device to device based on the device's capabilities.
Below are the different means of generating digital signatures across several devices. However, the developer must provide code integration for these non-repudiation mechanisms.
signtext()
mechanism (available with WAP 2.0.)
|
![]() Copyright © 2003 Oracle Corporation. All Rights Reserved. |
|