Industry analysts (Gartner—SOBA Apps show their potential.—SPA-20-7295) predict that over 80% of the business applications sold between 2005 and 2008 will be based on the principles of Service-Oriented Architecture (SOA). SOA expresses a business-driven approach to software architecture that defines the business as a set of linked business tasks or services. These self-contained, reusable software modules with well-defined interfaces are independent of the applications and computing platforms on which they run.
The most prevalent implementation of SOA, Web services, is having a significant effect on Enterprise Applications as we know them today. Web services enable incompatible and disparate software systems to interoperate. Web services enable applications to share data and invoke the capabilities of other applications regardless of how the applications were built, the operating system or platform the applications run on, or the devices that access the applications. Packaged application vendors such as SAP, Oracle, Salesforce.com, and the like have now introduced Web service architecture into their own offerings in the hope that enabling a service-based approach to applications will lower barriers to entry for customers.
Historically, IT investments in software development projects were commonly made in silos. Today, Web services provide organizations with a standard mechanism for enabling intra-company communication between heterogeneous internal systems. For example, by using Web services, a customer relationship management (CRM) system can extract customer order information from a financial or enterprise resource planning (ERP) application. Such loose coupling helps preserve the future by allowing parts to change at their own pace without the risks linked to costly migrations using monolithic approaches.
A brief overview of Web services is given in Appendix A and a more detailed discussion is available in Reference 5.
This article is about the development, deployment, and administration of secure Web services mobile clients. Additional topics will include the rationale for using Web services vis-à-vis traditional architectures for mobile clients and how mobile applications need to function when the user transitions in and out of the area covered by the service provider’s signal.
Web services are naturally a high-bandwidth solution; that is, they’re built with the expectation that they’ll be accessed over a wired network. But, when you access a Web service over a low-bandwidth wireless (mobile) network, the user experience can be seriously diminished. To compound the matter, roaming, handheld devices that transfer data over public networks are vulnerable to a seemingly limitless number of security compromises. I’ll focus on how one vendor—Research In Motion, Limited (RIM)—addresses these issues with its BlackBerry platform.
My selection of RIM is based on a number of factors: particularly its pioneering work with push technology—critical to optimizing the user experience—and mobile security—BlackBerry was the first mobile solution to be FIPS certified (FIPS is a United States federal standard that specifies security requirements for cryptography modules). See Appendix B for further details.
Web services (server-side) applications available from major software vendors are shown in Figure 1 at the far right. But, many Web services applications are home grown. For these, IDEs such as Microsoft’s Visual Studio and Oracle’s SOA Suite make development of custom Web services about as easy as the development of any other kind of back-end application.
For building Web service clients that run on their handheld devices, BlackBerry has recently introduced a RAD environment named Mobile Data Service (MDS) Studio. This visual tool and the handheld device are depicted at the top right and far left, respectively, in Figure 1.
BlackBerry Enterprise Server (BES) with MDS Services, located behind the firewall, is shown in the center of Figure 1. Among its many functions, BES serves as the gateway between the wired network on the right and wireless network on the left of this figure.
MDS Services also handles the interaction between the MDS applications running on the handheld device and back-end enterprise applications and systems.
The whole system allows the handheld device to connect securely into a server-side Web service over standard HTTP using the SOAP protocol.
Figure 1: System for development, deployment, and administration
MDS Studio enables you to integrate enterprise Web services with BlackBerry devices using a graphical methodology. This tool enables you to design the screen, data elements, and application messages visually using a component-based drag-and-drop approach. Wizards and editors further enable you to connect graphical components.
Once you have a Web service defined—either internal to your organization or external—you point MDS Studio to the WSDL of the Web Service and MDS can largely build the app for you. To illustrate, I created and ran the rather simple example shown in Figure 2 in just a few minutes, after first importing the WDSL file from a Web service application that I had previously created in Microsoft Visual Studio.
MDS Studio automatically created three basic components types:
- User interface components
- Used to lay out the application user interface
- UI components can be grouped into screens and frames
- UI components can be linked to data components and/or message components to create application workflow/logic
- Data components
- Used to store persistent and non-persistent application data on the device
- Data components can be linked to messages components and UI components
- Message components
- Used to send/receive application data between the client application on the device and the back-end system
- Message components can be linked to UI and data components
The developer can build a client application in its entirety (screens, data, messages, and application logic) without starting with the WSDL definition from a pre-existing Web service. The MDS Studio Service Pack has a WSDL generator that takes the output of the Studio application and either maps it back to an existing Web service WSDL definition or uses it to generate the WSDL itself. He or she can then import it into a tool like Visual Studio .NET, Axis, or Lotus Domino to generate mappings, components and stubs based on the WSDL or create the Web Service if it doesn’t already exist.
When the design of an MDS Application is complete, MDS Studio automatically generates an Extensible Markup Language (XML) metadata representation of the client application.
From MDS Studio, you can publish your app directly into an application repository. Anything that’s been published to that repository can be proactively pushed out as an app to the device by the administrator (using the BlackBerry Manager shown at the lower right in Figure 1) or the user of the handheld can search the repository for applications they want to install.
MDS Studio enables you to build apps that have integration with native BlackBerry functions. For example, once a user looks up a telephone number (always current on the handheld device because any changes to the data are automatically pushed out to the handheld from the backend server), he or she can click on the ‘phone number and have the ‘phone dial launched automatically. That’s part of the beauty of this converged voice-data device.
And, to cite another example, the user can look up a job ticket that resides in a backend job ticketing application and, once he or she clicks on that job, the MDS Studio-built app can add that job to the user’s calendar.
And, to help protect a published application from tampering, MDS facilitates your signing of an application bundle with a digital certificate described by an alias. You can use either a trusted certificate authority (CA) or a generated (self-signed) certificate. MDS Studio generates and signs applications with certificates that are compliant with the Public-Key Infrastructure (X.509) standard. See Reference 9. Note: The MDS Services system administrator might set IT policy options that require users to sign applications using trusted CA certificates only.
Figure 2: BlackBerry MDS Studio (based on Eclipse)
The MDS Runtime, which runs on the handheld device’s operating system, is the container-based execution environment for MDS applications. The MDS Runtime contains a control center application that enables users to search for and manage MDS applications and view application information. The MDS Runtime is designed to provide the underlying services that are used by MDS applications, including the user interface, data storage, and client-server communication services. It manages the on-device application lifecycle, including deployment, execution, and upgrade.
Figure 3: Individual services in BlackBerry Enterprise Server
MDS and other BES services
For this part of the discussion, a simplified version of Figure 1 is drawn in Figure 3 to illustrate the individual services in BlackBerry Enterprise Server.
MDS Services are designed to provide connectivity between MDS applications on the devices and enterprise data. MDS is a secure conduit that exists between all BlackBerry handheld units and their home BES. Data is sent from MDS to the BES, which sends it to the handheld units. Returning data is sent to the BES and then on to MDS. You also can think of the MDS as an HTTP and TCP/IP proxy with special features. (See Connection and other services in the following table.)
These special MDS features make it possible for developers easily to push content out to the BlackBerry handheld devices. Push refers to the capability of a BlackBerry user to receive content pushed out to their device automatically. Administrators with the required authorization can limit which groups of users can receive push data.
Making use of this conduit allows you to extend your intranet services to your BlackBerry users, virtually no matter where in the world they are. They can be connected to your intranet even as they cross from one cell to another or one carrier to another—these transitions are seamless to the user.
MDS runs as a standalone Windows service, but your BES communicates with it extensively as part of its normal operation. In fact, the data sent between the MDS and the BlackBerry must go through the BES, because it is the BES that communicates directly with the RIM Network Operating Center (NOC).
Each cellular carrier that supports the RIM BlackBerry sets up a secure Virtual Private Network (VPN) connection between the carrier’s data center and the RIM NOC. When a BlackBerry handheld unit is turned on, or when it comes into wireless coverage, it identifies itself to the NOC. At that point, the NOC knows how to communicate with it. More specifically, the NOC knows which cellular carrier the handheld unit is on, and, therefore, which VPN connection to use to communicate with the handheld device.
The following table provides an outline of the other BES services.
|Enables a system administrator to connect the MDS Services to the Mobile Data Service feature of the Enterprise Server. The Connection Service is designed to accept and respond to push requests from server-side push applications when the application server is behind the corporate firewall. This service is designed to provide a link to standard servers on the corporate intranet or Internet by using standard Internet protocol, such as HTTP or TCP/IP, and encrypt content using the same encryption standard that is used to encrypt BlackBerry messages and other BlackBerry data.
|Application Integration Service
|Supports Web services and other standard mechanisms for integrating wireless applications with existing enterprise applications and systems. This service is designed to manage the transmission of application data messages between BlackBerry MDS Applications and data sources.
|Controls which BlackBerry MDS Applications users can download to their BlackBerry devices, supports application discovery from a BlackBerry device, and manages wireless transmission on BlackBerry devices.
|Data Optimization Service
|Converts existing server-side content and data to enable wireless transmission and use on BlackBerry devices.
|Administrative and Management Service
|Centralizes the application lifecycle management, including centralized push installation, upgrade, and removal of applications from BlackBerry devices.
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
Shown in Figure 1, the MDS Runtime (residing on the BlackBerry device) and MDS Services (residing on the BlackBerry Enterprise Server behind the firewall) provide the optimization for easy mobilization of Web services for the BlackBerry. “Easy” here means that you can create wireless-friendly apps without a thorough knowledge of Java development, the BlackBerry device, and in many cases Web services. MDS does a lot of the low-level work for you. Because it can do this, it dramatically reduces the development cycle and the cost of creating these applications.
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.
- Recognizing that your device will go ‘out of coverage.’ When this happens,
- 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.
- Compliance with WS-I (Web Services Interoperability Organization) standards
- 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.
Two-Factor Authentication (Optional)
MDS supports a variety of corporate authentication schemes:
- HTTP Basic
In addition, MDS supports two-factor authentication from RSA Security, Inc. for those organizations invested in their technology. As indicated by the red characters in Figure 4, MDS integrates with RSA Authentication Manager to support RSA SecurID authentication for an extra layer of authorization when accessing content served by MDS.
Two-factor authentication technology can provide a safe and more secure alternative to the use of passwords. The user combines something he or she knows, a PIN, with something he or she has, a token code from an RSA SecurID token. With this system, it is impossible for someone to impersonate another unless he or she has access to both the PIN and the authenticator.
By combining the use of an authentication algorithm, the time of day, and a uniquely assigned seed record, an RSA SecurID token automatically generates and displays a pseudo-random token code. When combined with the PIN, the token code becomes the user’s pass code that allows access to the protected resource. This process is outlined in Figure 5.
When a user navigates to a site or application requiring authorization, they are prompted for their Username and—in lieu of a password—the Token Passcode that’s shown in Figure 6. You can use either a software or a hardware token (See Figure 7 for the latter). However, in addition to the fact that using a software token eliminates the need to carry around the small, easy-to-lose-or-forget hardware token, the software token has another major advantage:
Up to ten seed records can be associated with a single token, each with a different name to associate itself with any one of ten different sites. When bringing up the token, you scroll down the list of named seeds and pick one. This is particularly helpful when you want to use two-factor authentication for connecting to multiple, for example partner, sites.
When a user attempts to access a protected system, a special software agent—called an RSA Authentication Agent—initiates an Authentication Manager authentication session instead of a basic password session. The Authentication Agent transmits the information to the RSA Authentication Manager software, which approves access when the information is validated. The user is granted access appropriate to his or her authorization level, which is noted by the RSA Authentication Manager software in its log file.
Figure 5: Time-synchronous two-factor authentication with RSA SecureID
Figure 6: BlackBerry with RSA SecureID software token
If the BES Administrator sets the Application Control Policy’s Disposition property to Required (using the BlackBerry Handheld Configuration Tool), users are not able to uninstall the SecurID application from their handheld devices. To enable users to uninstall the application themselves, the BES Administrator must set the value for the Application Control Policy’s Disposition property to Optional.
Figure 7: Hardware tokens
Native LDAP support and QuickAdmin, a Web-based help desk utility, make the security administrator’s job easier. LDAP support enables the RSA Authentication Manager software to take advantage of the user and group information in the directory. Automated LDAP to RSA Authentication Manager import and synchronization utilities let administrators bring the data from the directory into the RSA Authentication Manager program and keep the data synchronized. RSA Authentication Manager software supports leading directories such as Microsoft Active Directory, Sun ONE LDAP Directory, and Novell eDirectory.
The system also features evasion of attack logic that automatically detects attempted intrusions or use of stolen tokens. This prevents unwelcome network attacks by tracking user authentication between replicated servers and blocks redundant requests in order to prevent replay attacks against servers or agents.
Strong IT Policy Enforcement and Management for Handheld Devices
To secure information stored on BlackBerry devices, password authentication can be made mandatory through the customizable IT policies of the BlackBerry Enterprise Server. By default, password authentication is limited to ten attempts, after which the device’s memory is erased.
Local encryption of all data (messages, address book entries, calendar entries, memos, and tasks) also can be enforced via IT policy. And, with the Password Keeper, password entries can be securely stored on the device (for example, banking passwords, PINs, and so forth) using AES encryption technology.
Additionally, system administrators can create and send wireless commands to remotely change BlackBerry device passwords, and lock or delete information from lost or stolen BlackBerry devices.
Permit-Only Trusted Connections
The BlackBerry Enterprise Server does not store any e-mail or data. To increase protection from unauthorized parties, there is no staging area between the server and the BlackBerry device where data is decrypted.
To further enhance the security of the solution, the BlackBerry Enterprise Server is designed to allow only authenticated, outbound-initiated connections through port 3101 of the firewall. Unauthorized commands cannot be executed on the system because no inbound traffic is permitted from sources other than the BlackBerry device. Only data that can be decrypted with a valid encryption key are permitted between the server and the wireless network. All data and application traffic, including browser, MDS Studio, and Java application data messages, use the same data encryption technologies that are used by the BlackBerry Enterprise Server.
The conflation of mobile technology (which is getting faster and more nearly ubiquitous) and Web services (which is entering the mainstream and becoming more standardized) in an increasingly security-conscious world is supported by some very good software and hardware. That from Research In Motion and RSA Security is not the only choice out there. But, the technologies and products from these two pioneers should serve as a standard by which the technologies and products from other vendors may be measured or judged when you peruse alternative solutions. Although neither Research In Motion nor RSA Security is resting on its laurels, neither is its competition.
Appendix A: Web Services
Web services are self-contained software components that are published, located, and invoked over the Internet or an intranet, using standard protocols and interfaces. For example, the Web services architecture allows an application at one company to query a service at another company to determine the current price of a particular product. Although this is currently possible without using Web services, it requires modification of each company’s applications so that each service can find and talk to each other. By using standard enabling technologies, an application or service can be made available over the network without regard to platform, language, location, or implementation of the service.
In Figure 8, the Service Broker helps Service Providers and Service Requesters find each other. The UDDI (Universal Discovery, Description, and Integration)-based registry is where a Web service is discovered. UDDI’s approach to discovery is to have a registry of services distributed across the Web. In that distributed registry, businesses and services are described in a common XML format. The structured data in those XML documents is easily searched, analyzed, and manipulated. Currently, there exist a number of global registries that allow businesses to find each other across enterprise boundaries. WSDL (Web Services Description Language) is an XML-based language for describing the interface of Web services. The service requester can use WSDL to find a compliant service and the service provider uses WSDL to describe the service it is providing.
Figure 8: Relationships among service requester, provider, and broker
Advantages of Web services
- Web services provide interoperability between various software applications running on disparate platforms/operating systems.
- Web services use open standards and protocols. Protocols and data formats are text-based where possible, making it easy for developers to comprehend.
- By utilizing HTTP, Web services can work through many common firewall security measures without requiring changes to the firewall filtering rules. Other forms of RPC may more often be blocked.
- Web services allow software and services from different companies and locations to be combined easily to provide an integrated service.
- Web services allow the reuse of services and components within an infrastructure.
- Web services are loosely coupled, thereby facilitating a distributed approach to application integration.
Disadvantages of Web services
- Web services standards features such as transactions are currently nonexistent or still in their infancy compared to more mature distributed computing open standards such as CORBA. This is likely to be a temporary disadvantage as most vendors have committed to the OASIS standards to implement the Quality of Service aspects of their products.
- Web services may suffer from poor performance compared to other distributed computing approaches such as RMI, CORBA, or DCOM. This is a common trade-off when choosing text-based formats. XML explicitly does not count among its design goals either conciseness of encoding or efficiency of parsing. This could change with the XML Infoset standard, which describes XML-based languages in terms of abstractions (elements, attributes, and logical nesting). The traditional angle-bracket representation is now seen as an ASCII (or Unicode) serialization of XML, not XML itself. In this model, binary serialization is an equally valid alternative. Binary representations such as SOA MTOM promise to improve the wire efficiency of XML messaging.
Appendix B: FIPS 140-2
RIM’s FIPS validation program focuses on the software components that provide the core cryptographic operations required for BlackBerry functionality. In the case of BlackBerry devices, the “BlackBerry Cryptographic Kernel” was validated, and in the case of the BlackBerry Enterprise Server, the “BlackBerry Enterprise Server Cryptographic Kernel” was validated. This ensures two things: that data sent between the BlackBerry Enterprise Server and a device (in other words, over-the-air) and any data stored on the device are encrypted.
BlackBerry has several FIPS 140-2 validation certificates that span several versions of both Cryptographic Kernels, including all currently released versions with BlackBerry handheld software and BlackBerry Enterprise Server 4.1. References 12 and 13 contains details of the BlackBerry FIPS 140-2 Security Policy.
Appendix C: The BlackBerry Manager
The BlackBerry Manager is the administration console through which administrators manage the BlackBerry Enterprise Server. For example, they can enforce corporate policies by specifying acceptable use for the handheld, on a per user or per group basis and everything is done over-the-air. Further discussion of the administration console is beyond the scope of this article, but you can see the “tip of the iceberg” in Figure 9.
Figure 9: BES administration console
- Johnston, C., Evers, R. Professional BlackBerry, Wrox (2005)
- Mabe, D. BlackBerry Hacks, O’Reilly Media (2006)
- Foust, B. Mobile Guide to BlackBerry, Que (2005)
- Simmons, C. How to Do Everything with Your Blackberry, 2nd Ed., McGraw-Hill/Osborne (2004)
- Newcomer, E. Understanding Web Services: XML, WSDL, SOAP, and UDDI, Addison-Wesley (2002)
- Knudsen, J., Li, S. Beginning J2ME: From Novice to Professional, 3rd Ed., Apress (2005)
- Koletzke, P. et al Oracle JDeveloper 10g Handbook, McGraw-Hill/Osborne (2004)
- Johansson, J., Riley, S. Protect Your Windows Network, Addison-Wesley (2005)
- Adams, C., Lloyd, S. Understanding PKI, 2nd Ed., Addison-Wesley (2003)
- Erbschloe, M. Physical Security for IT, Elsevier (2004)
- Poole, I., Cellular Communications Explained, Elsevier (2006)
About the Author
Marcia Gulesian has served as Software Developer, Project Manager, CTO, and CIO over an eighteen-year career. She is author of well more than 100 feature articles on Information Technology, its economics, and its management. You can e-mail Marcia at email@example.com.
© 2006 Marcia Gulesian