Welcome!

Industrial IoT Authors: Elizabeth White, Ed Featherston, Stackify Blog, Yeshim Deniz, SmartBear Blog

Related Topics: Industrial IoT

Industrial IoT: Article

Securing and Authenticating SOAP-Based Web Services

Securing and Authenticating SOAP-Based Web Services

If you are implementing a multiuser system, your system will probably have certain attributes. It may be implemented in a distributed fashion and it may have some sort of security model. In its most basic form, such a system can be represented by a straight line on a piece of paper: below the line is the information, content, data (call it what you will); and above the line are the various individuals, groups, and roles that need to work with what is below the line.

We connect clients above the line to the data below it by exposing services that provide access through the line. These services describe the operations that may be performed upon the data. The security model implemented within the service layer determines who may perform those operations and upon which particular bits of data. To the extent that these services are the only way to access the data, our line is now a secure perimeter.

To complete the picture, the services need to be able to identify the clients. Using SOAP to implement these services gives us a number of options, each with its advantages and disadvantages, and each in various stages of development. Basic Authentication and SSL

Apache SOAP 2.1 introduced basic authentication and HTTPS support. The SOAPHTTPConnection object includes two methods, setUserName() and setPassword(), and its send() method uses them to construct an "Authorization" header for the HTTP POST. With this header, the SOAP client will be authenticated against the HTTP daemon receiving the request and, assuming success, the request will be passed off to the SOAP endpoint. Of course, without HTTPS support, the credentials - though base-64 encoded - would be sent in the clear, so be sure to use SSL when using this technique.

Basic authentication is pretty much just that. The weaknesses are well known and, for the most part, come down to the ease with which passwords are compromised, which can be as simple as someone looking over someone else's shoulder.

SOAP Digital Signature
The IBM alphaWorks Web Services Toolkit (WSTK) version 2.3, and Apache AXIS (not yet in first, full release as of this writing) include support for SOAP Digital Signature. (More information can be found at www.w3.org/TR/SOAP-dsig/.) In short, it enables you to digitally sign the body of a SOAP envelope and include the signature information in the envelope header. In order to understand exactly what this does for you, you need to understand, at the highest possible level, what public key cryptography (PKC) does for you.

PKC uses a two-part key system: one part is kept secret and known only to the key owner, and the other part is public and known to everyone. The relationship between the keys is such that it isn't possible (for all practical purposes) to derive one key from the other. Using your public key, people can create encrypted messages that only you can decode.

The second benefit is digital signature. Using your private key, you can sign a block of data - in the case of SOAP digital signatures, the SOAP envelope body. While signing a message does not encrypt it, it does guarantee its integrity. Using your public key, anyone with the signature and an intact copy of the signed message can verify that you signed that message. If either the message or the signature is altered, signature verification will fail. Digital signatures can be used for authentication if the authenticator challenges a client who then signs the challenge and returns it. If the challenge is unique each time (a nonce), the authentication process can't be replayed.

PKC wonks will cringe at the brevity of this explanation, but since numerous books have been written on the topic, we can only recommend that interested readers seek one out. On the other hand, this is sufficient information to determine that SOAP digital signatures, while useful, are not, nor are they intended to be, an authentication mechanism as such. Quoting from the W3C note mentioned earlier:

For example, digital signatures alone do not provide message authentication. One can record a signed message and resend it (replay attack). To prevent this type of attack, digital signatures must be combined with an appropriate means to ensure the uniqueness of the message, such as nonces or time stamps. One way to add this information is to place an extra <http://www.w3.org/2000/09/xmldsig#Object> element that is a child of <http://www.w3.org/2000/09/xmldsig#Signature>.

So, to use SOAP digital signatures as an authenticating mechanism, you must do a bit of work, but it can be done. It's a bit harder than it sounds, since time stamps tend to introduce timing windows, and a nonce-based scheme would make the service request more conversational than you would like. Without modification, SOAP digital signatures will tell you who signed the message, but not who is delivering the message. There is, however, another authentication mechanism based on certificates at our disposal that we have yet to consider.

SSL with Digital Certificate Authentication
Step 1: An SSL Example
We've already taken a brief look at the authentication support in Apache SOAP 2.1, including the SSL support. If you look at SSLUtils.java, you will find this bit of canonical code:

SSLSocketFactory factory = (SSLSocketFactory)SSLSocketFactory.getDefault();
SSLSocket sslSocket = (SSLSocket)factory.createSocket(host, port);
sslSocket.startHandshake(); return sslSocket;
It's the SSL handshake part that's interesting: it allows the server and client to authenticate each other (typically using PKC), and to negotiate an encryption algorithm and cryptographic keys before the application protocol transmits or receives its first byte of data. Things can go wrong, such as the client and server not having any cipher suites in common, or either the client or server not being able to encrypt at the strength required by the other.

Peer authentication may also be made part of the process - most of us have run into a secure site, the name of which does not agree with its certificate, resulting in a warning from the browser that the site should not be trusted. Both sides of the connection may be subject to peer authentication, and it's this stage that gives us our opening: during this stage, credentials in the form of digital certificates are exchanged.

What is a certificate? As everybody can generate a key pair, there needs to be a process by which a key pair is tied to an identity. This gives rise to the concept of the Certification Authority (CA), which is an external service that verifies your identity and digitally signs your public key. A certificate, in its most basic form, then consists of your key pair, some information about you, such as your name, along with the digital signature of a CA.

For this to work it's critically important that both parties in the authentication process "trust" the CA that signed the certificates that are being exchanged. You trust a CA by putting a copy of the certificate of the CA - minus its private key - into a designated location called the truststore. The decision as to whether a particular certificate passed along during the SSL handshake process should be trusted or not is then made by comparing the certificate of the CA that signed it with the list of trusted CA certificates in the truststore.

Let's start with a simple service request over SSL and see what happens. To do this, you will need a copy of Apache SOAP (we used 2.1) and the Java Secure Socket Extension. (We used version 1.0.2, http://java.sun.com/products/jsse/. It has since been included in JDK 1.4, but it hadn't been fully released at the time of this writing.) Finally, your HTTP server/servlet container combination must support SSL, and later we will require SSL with client authentication through certificates.

Most servers support certificate-based authentication. Apache supports it via a third-party product, Covalent SSL. IIS natively supports static certificate mapping to NT accounts, while in a Windows 2000 environment certificates are managed via Active Directory.

We used Allaire JRun 3 under IIS 5. Enabling the use of SSL with JRun applications under IIS isn't obvious, but it is documented in the Allaire/Macromedia knowledge base. In short, you have to secure the JRun DLL. Looking at the management console for IIS, you will find the JRun DLL in the scripts directory. Right-click over the DLL, select Properties, click on the File Security tab, and find the Secure Communications area (see Figure 1). Once you have installed a certificate on the Web server, clicking on the Edit button will enable you to turn on SSL. Later, we will use the same dialog to turn on client certificate authentication.

If, like us, you have generated your own server certificate using the Windows 2000 Certificate Server, you'll need to tell the client that it can trust the CA that issued that certificate. In our case, that authority was the Windows 2000 Certificate Server, and we simply export a base-64 encoded version of the authority's certificate and add it to the JDK's "cacerts" keystore - the truststore and the default repository for trusted CAs. Assuming the exported certificate was named "server.cer", the following JDK keytool command would add the key to the truststore with the alias "TestCA":

\jdk\bin\keytool -import -file server.cer -keystore \jdk\lib\security\cacerts -storepass changeit -alias TestCA
Answering "yes" to the query to trust the certificate will cause the JDK to "trust" your server.

Now let's see if everything is installed correctly. Compiling the code in Listings 1 and 2, deploying the service, and running the client should yield predictable results. Once you have placed the TestService class file in the SOAP WEB-INF\classes directory (or somewhere else the servlet will find it), you may deploy the service with the following command:

\jdk\bin\java -Djava.protocol.handler.pkgs= com.sun.net.ssl.internal.www.protocol org.apache.soap.server.ServiceManagerClient https://localhost/soap/servlet/rpcrouter deploy TestService.xml
TestService.xml should contain the following:
<isd:service xmlns:isd="http://xml.apache.org/xml-soap/deployment" id="urn:TestService">
<isd:provider type="java" scope="Session" methods="testMethod">
<isd:java class="TestService" static="false"/>
</isd:provider>
<isd:faultListener>
org.apache.soap.server.DOMFaultListener </isd:faultListener>
</isd:service>
The command to run it should look something like this:
\jdk\bin\java -Djava.protocol.handler.pkgs= com.sun.net.ssl.internal.www.protocol -Djavax.net.debug=all TestMain string
Including the debug option causes the various stages of the SSL handshake to be printed out nicely.

If you then alter the security on the JRun DLL to require client certificates and run the example again, you should receive an exception and will possibly see the page sent by IIS rejecting the attempt to connect.

If you would like to know more about the nuts and bolts of SSL, the JSSE Guide has an excellent description of how SSL works and what happens during the handshake.

Step 2: Generating a Key
Next create a keystore and a key with which you can experiment. First, generate a key for your client to use in authentication. Something like the following should do the trick and generate a new keystore named "TestClientStore" with a key pair called "TestClientCert":

\jdk\bin\keytool -genkey -keyalg rsa -keystore
TestClientStore -storepass TestStorePass -alias
TestClientCert -keypass TestKeyPass
You will be asked to provide information that identifies you. At this point, TestClientCert is a "self-signed" certificate; in other words, nobody other than you has verified who you claim to be. Thus, to generate a request for your CA to validate your identity and to sign your key (called a PKCS#10 request), type:
\jdk\bin\keytool -certreq -alias TestClientCert -file CertRequest.p10 -keypass TestKeyPass -keystore TestClientStore -storepass TestStorePass
When visiting the Windows 2000 Certificate Authority Web page to request a certificate, you will want to make an "advanced" request for a client certificate, then, "Submit a certificate request using a base-64 encoded PKCS #10 file or a renewal request using a base-64 encoded PKCS #7 file." Submit the file, "CertRequest.p10", download the "CA certification path" to a file called "client.p7b" and run the following to replace your self-signed certificate with the certificate signed by your trusted CA:
\jdk\bin\keytool -import -file client.p7b -keystore TestClientStore -storepass TestStorePass -alias TestClientCert -keypass TestKeyPass
The keystore now contains a key that can be used by your client to authenticate itself. To avoid the complications of Active Directory, you can use static client-certificate mapping on the Web server. To do this, you must export a copy of your public key to a file with the following:
\jdk\bin\keytool -export -keystore TestClientStore -storepass TestStorePass -alias TestClientCert -file client.cer -rfc
The final step in this public key odyssey is to map the key you just exported to a user account. Revisit the secure communications setup for the JRun DLL, enable client-certificate mapping, and then edit the account mappings. Add a mapping, then choose the client certificate you just exported and map it to an account to which you know the password. If you followed the example, the server will trust the client certificate without you telling it to do so explicitly, as the CA that signed it was the same CA that signed the server certificate earlier on.

That was a great deal of cookbook work, so here is a brief account, in more abstract terms, of what you just did:

  • Added your certificate authority's public key to cacerts keystore of trusted CAs in order to "trust" your CA
  • Created a new keystore; keystores are used by Java to hold public and private keys for encryption/decryption and digital signature operations
  • Generated a personal public/private key pair
  • Generated a request for that key to be signed by your CA
  • Had your CA sign that key so the user of the key would be trusted by anyone who trusts the CA
  • Imported the CA response into the keystore
  • Exported the signed public key
  • Mapped the public key to an NT account in IIS

    A similar series of steps would be followed for authenticating any combination of Web servers, servlet containers, and self-run or commercial certificate authorities.

    Note that you may be able to simplify things a little bit in certain situations:

  • If you are using the services of a commercial CA, the first step may not be necessary, as the cacerts keystore is installed with a set of vendor certificates that are trusted by default. Also note that nothing prevents you from bypassing the cacerts keystore altogether and storing all your public and private keys in one keystore. (See the comment in the TrustManager initialization routine in Listing 2.)
  • If you already have a signed certificate available, for example one managed by Netscape Navigator or Internet Explorer, you don't need to generate an extra one. Simply export that certificate along with its private key to a PKCS#12 file to disk, and have that file act as your keystore. This works because JSSE has basic support for keystores of type pkcs12.
Finally, when running in a Windows 2000 environment, you can dynamically map client requests to Active Directory user accounts. The only hurdle to overcome in this scenario is that the PKCS#10 requests need to have additional parameters meaningful only to Active Directory and the Windows authentication subsystem - something beyond the scope of this article.

Step 3: Adding Certificate Authentication to SOAP
Next you must modify SSLUtils.java to use your key during socket creation. The goal here is to create an SSLSocketFactory that will create sockets that will use your key for authentication during the handshake process. This involves a bit more canonical code that, like SSLUtils.java, can be found in the JSSE samples. To compile and test the changes, you'll need to unpack the SOAP JAR and sources.

Be sure to remove the SOAP JAR from your CLASSPATH and anywhere else you might find it, such as the lib\ext directory of the JDK or JRE you're using, while simultaneously making sure the servlet container can still find it. The modified org.apache.soap.util.net.SSLUtils is in Listing 3. Place it in the correct directory and recompile. Also, uncomment the lines in TestMain.java designated for Step 3.

If all is well, and you broke the example by requiring client certificates as suggested at the end of Step 1, the example should start working again.

How? Well, looking at the enableCerts() method that has been added to SSLUtils, you can see how the SSLSocketFactory is set up. The first step gets an instance of an SSLContext that implements the TLS protocol (Transport Layer Security - more info at ftp://ftp.isi.edu/in-notes/rfc2246.txt).

Next, the code gets a KeyManagerFactory and a keystore. The keystore instance is used to load the keystore created in Step 2. Then, to make explicit what's happening, the code gets an instance of the default TrustManager pointing to the default CA trust keystore cacerts. Note, though, that the default trust manager provides only very basic X.509-based certification path validity checking; it does not, for instance, check for certificates that have been revoked.

Then the KeyManagerFactory is initialized with the keystore, passing along the passphrase to use with the keys in the keystore. That's right - when using the default KeyManagerFactory, all keys in a given keystore that will be used for authentication must use the same passphrase. The code then initializes the SSLContext with the KeyManagers derived from the KeyManagerFactory and the TrustManager from above, and then gets an SSLSocketFactory from the context.

It seems like a lot of magic words, but in the end, you've added certificate-based authentication with about 10 lines of code. If the client, using a socket created by this factory, is challenged to authenticate during the handshake, the SSLSocketFactory will request an appropriate key from the KeyManagers to complete that portion of the handshake. Appropriate in this context means any certificate on the client that has been signed by a CA trusted by the server; if more than one client certificate fits the bill, the default KeyManager will simply pick the first one available.

This will provide you with perimeter security. For finer control, you'll need to get the client's identity back to the services. To do this, we refer you to Mark Moore's article in the premier issue of Web Services Journal: "Sending Out-of-Band Messages to SOAP-Based Web Services." The technique described extends the SOAP RPCRouterServlet servlet to add information to an InheritableThreadLocal, making it accessible to the service. In this case, you would want to include the value of HttpServletRequest.getRemoteUser() to the ServiceContext described in that article.

A Note About Performance
Why is it so slow? Well, there are a number of things going on. First, just cranking up the JVM can take a while. Also, the first time you create a socket, a java.security.SecureRandom object must be generated. That takes time, but it's only once. One way to avoid that is to generate one ahead of time, and supply it as the third argument to the SSLContext.init() method. The nature of this example does not allow that particular optimization.

Finally, HTTPS is simply going to be slower than an HTTP connection - establishing a connection takes time, as does encrypting the ongoing traffic. If you believe connection setup represents a significant impact on the performance of your system, you may want to investigate getting rid of the overhead of setting up a connection for every request by implementing HTTP "keep-alive". Since SOAP sends an HTTP version of "1.0", you would need to send a header in the form "Connection: keep-alive".

Assuming your Web server supports HTTP 1.1 (where keep-alive is implicit) or the keep-alive header with HTTP 1.0, you will be able to get a persisted connection to the server and reuse the socket that has already been set up. The hard part is altering HTTPUtils to take advantage of this persisted connection. If HTTPUtils used a java.net.HttpURLConnection, you might have gotten this for free, though this incurs other challenges - the handling of the HTTP error code 500, which is used by SOAP, being one of them.

As it is, HTTPUtils opens and closes a fresh socket every time and implements the POST as custom code, making the implementation of keep-alive not as straightforward as you might hope.

Terra Firma
You will certainly find opportunities to extend this basic example to suit your own requirements, but this should provide you with the grounding you need to get started. In addition to keep-alive, which has already been discussed, obvious enhancements would also include making the key alias and passphrase connection-based, perhaps using the existing setUserName() and setPassword(), and adding a setAuthenticationType().
We hope your interest is piqued to learn more about public key cryptography and its use in building secure systems. The subject area is deep and your planning will benefit from an understanding of the tools at your disposal. Though not yet mature, the technology is there to build robust and secure SOAP-based Web services.

The views and opinions are those of the authors and do not necessarily represent the views and opinions of KPMG LLP.

More Stories By Mark Moore

Mark Moore is currently an independent consultant. Previously, he was
Chief Architect for KPMG International's Global Knowledge Exchange,
deploying knowledge sharing capabilities to 80,000 KPMG employees in more
than 40 countries. He has been designing and developing web-based knowledge
management and collaborative solutions for the last six years.

More Stories By Adrian Turtschi

Adrian Turtschi is a software architect with KPMG's Global Knowledge Exchange in Boston. He is
interested in questions of interoperability and cross-platform development. He is currently working
on an authentication and authorization scheme for KPMG International.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


@ThingsExpo Stories
BnkToTheFuture.com is the largest online investment platform for investing in FinTech, Bitcoin and Blockchain companies. We believe the future of finance looks very different from the past and we aim to invest and provide trading opportunities for qualifying investors that want to build a portfolio in the sector in compliance with international financial regulations.
A strange thing is happening along the way to the Internet of Things, namely far too many devices to work with and manage. It has become clear that we'll need much higher efficiency user experiences that can allow us to more easily and scalably work with the thousands of devices that will soon be in each of our lives. Enter the conversational interface revolution, combining bots we can literally talk with, gesture to, and even direct with our thoughts, with embedded artificial intelligence, whic...
Imagine if you will, a retail floor so densely packed with sensors that they can pick up the movements of insects scurrying across a store aisle. Or a component of a piece of factory equipment so well-instrumented that its digital twin provides resolution down to the micrometer.
In his keynote at 18th Cloud Expo, Andrew Keys, Co-Founder of ConsenSys Enterprise, provided an overview of the evolution of the Internet and the Database and the future of their combination – the Blockchain. Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settle...
Product connectivity goes hand and hand these days with increased use of personal data. New IoT devices are becoming more personalized than ever before. In his session at 22nd Cloud Expo | DXWorld Expo, Nicolas Fierro, CEO of MIMIR Blockchain Solutions, will discuss how in order to protect your data and privacy, IoT applications need to embrace Blockchain technology for a new level of product security never before seen - or needed.
Leading companies, from the Global Fortune 500 to the smallest companies, are adopting hybrid cloud as the path to business advantage. Hybrid cloud depends on cloud services and on-premises infrastructure working in unison. Successful implementations require new levels of data mobility, enabled by an automated and seamless flow across on-premises and cloud resources. In his general session at 21st Cloud Expo, Greg Tevis, an IBM Storage Software Technical Strategist and Customer Solution Architec...
Nordstrom is transforming the way that they do business and the cloud is the key to enabling speed and hyper personalized customer experiences. In his session at 21st Cloud Expo, Ken Schow, VP of Engineering at Nordstrom, discussed some of the key learnings and common pitfalls of large enterprises moving to the cloud. This includes strategies around choosing a cloud provider(s), architecture, and lessons learned. In addition, he covered some of the best practices for structured team migration an...
No hype cycles or predictions of a gazillion things here. IoT is here. You get it. You know your business and have great ideas for a business transformation strategy. What comes next? Time to make it happen. In his session at @ThingsExpo, Jay Mason, an Associate Partner of Analytics, IoT & Cybersecurity at M&S Consulting, presented a step-by-step plan to develop your technology implementation strategy. He also discussed the evaluation of communication standards and IoT messaging protocols, data...
Coca-Cola’s Google powered digital signage system lays the groundwork for a more valuable connection between Coke and its customers. Digital signs pair software with high-resolution displays so that a message can be changed instantly based on what the operator wants to communicate or sell. In their Day 3 Keynote at 21st Cloud Expo, Greg Chambers, Global Group Director, Digital Innovation, Coca-Cola, and Vidya Nagarajan, a Senior Product Manager at Google, discussed how from store operations and ...
In his session at 21st Cloud Expo, Raju Shreewastava, founder of Big Data Trunk, provided a fun and simple way to introduce Machine Leaning to anyone and everyone. He solved a machine learning problem and demonstrated an easy way to be able to do machine learning without even coding. Raju Shreewastava is the founder of Big Data Trunk (www.BigDataTrunk.com), a Big Data Training and consulting firm with offices in the United States. He previously led the data warehouse/business intelligence and B...
"IBM is really all in on blockchain. We take a look at sort of the history of blockchain ledger technologies. It started out with bitcoin, Ethereum, and IBM evaluated these particular blockchain technologies and found they were anonymous and permissionless and that many companies were looking for permissioned blockchain," stated René Bostic, Technical VP of the IBM Cloud Unit in North America, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Conventi...
When shopping for a new data processing platform for IoT solutions, many development teams want to be able to test-drive options before making a choice. Yet when evaluating an IoT solution, it’s simply not feasible to do so at scale with physical devices. Building a sensor simulator is the next best choice; however, generating a realistic simulation at very high TPS with ease of configurability is a formidable challenge. When dealing with multiple application or transport protocols, you would be...
Smart cities have the potential to change our lives at so many levels for citizens: less pollution, reduced parking obstacles, better health, education and more energy savings. Real-time data streaming and the Internet of Things (IoT) possess the power to turn this vision into a reality. However, most organizations today are building their data infrastructure to focus solely on addressing immediate business needs vs. a platform capable of quickly adapting emerging technologies to address future ...
We are given a desktop platform with Java 8 or Java 9 installed and seek to find a way to deploy high-performance Java applications that use Java 3D and/or Jogl without having to run an installer. We are subject to the constraint that the applications be signed and deployed so that they can be run in a trusted environment (i.e., outside of the sandbox). Further, we seek to do this in a way that does not depend on bundling a JRE with our applications, as this makes downloads and installations rat...
Widespread fragmentation is stalling the growth of the IIoT and making it difficult for partners to work together. The number of software platforms, apps, hardware and connectivity standards is creating paralysis among businesses that are afraid of being locked into a solution. EdgeX Foundry is unifying the community around a common IoT edge framework and an ecosystem of interoperable components.
DX World EXPO, LLC, a Lighthouse Point, Florida-based startup trade show producer and the creator of "DXWorldEXPO® - Digital Transformation Conference & Expo" has announced its executive management team. The team is headed by Levent Selamoglu, who has been named CEO. "Now is the time for a truly global DX event, to bring together the leading minds from the technology world in a conversation about Digital Transformation," he said in making the announcement.
In this strange new world where more and more power is drawn from business technology, companies are effectively straddling two paths on the road to innovation and transformation into digital enterprises. The first path is the heritage trail – with “legacy” technology forming the background. Here, extant technologies are transformed by core IT teams to provide more API-driven approaches. Legacy systems can restrict companies that are transitioning into digital enterprises. To truly become a lead...
Digital Transformation (DX) is not a "one-size-fits all" strategy. Each organization needs to develop its own unique, long-term DX plan. It must do so by realizing that we now live in a data-driven age, and that technologies such as Cloud Computing, Big Data, the IoT, Cognitive Computing, and Blockchain are only tools. In her general session at 21st Cloud Expo, Rebecca Wanta explained how the strategy must focus on DX and include a commitment from top management to create great IT jobs, monitor ...
"Cloud Academy is an enterprise training platform for the cloud, specifically public clouds. We offer guided learning experiences on AWS, Azure, Google Cloud and all the surrounding methodologies and technologies that you need to know and your teams need to know in order to leverage the full benefits of the cloud," explained Alex Brower, VP of Marketing at Cloud Academy, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clar...
The IoT Will Grow: In what might be the most obvious prediction of the decade, the IoT will continue to expand next year, with more and more devices coming online every single day. What isn’t so obvious about this prediction: where that growth will occur. The retail, healthcare, and industrial/supply chain industries will likely see the greatest growth. Forrester Research has predicted the IoT will become “the backbone” of customer value as it continues to grow. It is no surprise that retail is ...