Secure Mobile Web Service Applications: The BlackBerry Enterprise Solution
Web services vis-à-vis traditional architectures
The rationale for using Web services vis-à-vis traditional architectures for mobile clients is based on flexibility. With the latter architecture, you generally need to have a different kind of server for each category of client—thick client application, thin Web application, or another server application. However, with the former architecture, a single Web service server can service not only any of the previously listed clients but also to mobile clients.
In addition, Web services are the most efficient technology for mobilizing enterprise applications. In large part, that's because Web services use a standard XML messaging model and predefined schema that allow application integration using a generic proxy service. MDS implements this model by providing compact messages that flow down to the device where the application, described in XML, is loaded and executed.
Optimizing Web services for the mobile client
This optimization of Web services is a result of factors such as:
- Making your Web service wireless friendly
- Transmit no superfluous data over the air—MDS does a good deal of this for you automatically. For example, if the Web service returns 100 data components, but if your application only uses two or three, MDS detects that and only returns those data components that you are actually using in your application. The more you reduce the amount of data sent over the air, the longer your battery is going to last and the faster the user experience is going to be.
- Minimize the complexity of data returned by Web service operations that are specializations of their 'wired' peers.
- Proxy Web services may also be employed to act as a wrapper or mediator for an existing Web service.
- The BlackBerry is able to persist and process data locally and access its e-mail, calendar, and address book.
- The BlackBerry queues up its server requests and server responses are similarly held for automatic delivery once the device comes back into coverage.
- Not all popular Web service toolkits comply with the WS-I Basic Profile. MDS Studio and MDS Services support several extensions of WS-I Basic Profile, based on their use in certain toolkits. However, these extensions should not be considered best practices and should be avoided where possible.
Enabling the Power of Push
Server-side applications can securely and pro-actively push content to handheld applications that have been designed to listen for such incoming data. So, a developer can implement push technology around a Web service.
Traditional wiredWeb services are based on the request/response paradigm; notification-based Web services are not yet widely available.
However, some Web services do provide a notification service. After a client registers an interest in the Web service's topic, the Web service sends a notification to the client whenever an event occurs related to that topic. For example, a sales representative might want to be notified whenever a 'phone call is received by his or her head office from a specific set of customers.
The subscription specifies the types of events ('phone calls from certain customers); the notification is a message sent whenever one of those events occurs. The software that records the calls is the event source.
To extend the interoperability of service-oriented architecture into the realm of asynchronous communication, an efficient Web service Eventing framework is required. The clearest direction for standardization in this area is WS-Eventing.
Mobile Data System has embraced WS-Eventing as a means to describe service subscription through WSDL. At design time, MDS Studio looks for patterns in the WSDL to detect notifications. MDS Studio then creates subscription and notification messages to expose the subscription paradigm to the application.
Both MDS Studio and MDS Services rely on the WS-EVENTING standard in the following ways:
- MDS Studio looks for patterns in the WSDL to detect notifications.
- MDS Studio creates subscription and notification messages to reveal the subscription paradigm to the application in a simplified way.
- MDS Services constructs subscription and un-subscription Simple Object Access Protocol (SOAP)-based messages on the WS-EVENTING specification.
- MDS Services has requirements for subscription management and for the information that is required on the notification.
Bottom line: You can take a synchronous Web service and make it asynchronous so that it works well within the wireless (mobile) model.
For a discussion of the security—encryption, authentication, and much more—that protects the information held in the itinerant handheld device and the backend server, Figure 4 renders a modified view of the overall system shown in Figure 1.
Figure 4: Security: end-to-end encryption and authentication
End-to-End Wireless Encryption
The BlackBerry Enterprise Solution offers two transport encryption options, the Advanced Encryption Standard (AES) and Triple Data Encryption Standard (Triple DES) encryption, for all data transmitted between the BlackBerry Enterprise Server and the BlackBerry handheld device. See the topmost horizontal arrow in Figure 4.
AES is part of the U.S. National Institute of Standards (NIST) Federal Information Processing Standards Publication 140 (FIPS 140-2) developed for U.S. government nonmilitary agencies and contractors. BlackBerry devices are FIPS 140-2 certified. References 12 and 13 contain details of the BlackBerry FIPS 140-2 Security Policy.
Private encryption keys are generated in a secure, two-way authenticated environment and are assigned to each BlackBerry device user. Each secret key is stored only in the user's secure Microsoft Exchange, IBM Lotus Domino, or Novell GroupWise mailbox and on their BlackBerry device, and can be regenerated wirelessly by the user.
Data sent to the BlackBerry device is encrypted by the BlackBerry Enterprise Server using the private key retrieved from the user's mailbox. The encrypted information travels securely across the network to the device where it is decrypted with the key stored there.
Data remains encrypted in transit and is never decrypted outside of the corporate firewall.
This self-contained encryption scheme is at least the equal of that found in a Virtual Private Network (VPN),
Note: For those BlackBerry users who need to connect to a VPN, RIM offers the Model 7270 that has a VPN client.
HTTPS for Secure Data Access
MDS acts as a secure gateway between the wireless network and corporate intranets and the Internet. This service also [optionally] enables HTTPS connections to application servers for end-to-end encryption. This option is typically exercised to protect financial or health records.
BlackBerry devices support HTTPS communication in one of two modes, depending on corporate security requirements:
- Proxy Mode: An SSL/TLS connection is created between the BlackBerry Enterprise Server and the application server on behalf of the BlackBerry device. Data from the application server is then AES or Triple DES encrypted and sent over the wireless network to the BlackBerry device. See the second from top horizontal arrow in Figure 4.
- End-to-End Mode: Encrypts data over SSL/TLS for the entire connection between the BlackBerry device and the application server, making End-to-End Mode connections most appropriate for applications where only the transaction end-points are trusted. See the third from top horizontal arrow in Figure 4.
Page 2 of 4